Skip to content
Development
Skill

/implement-task

Implement a task with automated LLM-as-Judge verification per step

From plugin
context-engineering-kit
1.3k134 skills23 agents1 command
Install
$ npx -y skills add NeoLabHQ/context-engineering-kit --skill implement-task --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/implement-task

Context preview

The summary Claude sees to decide when to auto-load this skill.

Implement a task with automated LLM-as-Judge verification per step

SKILL.md

implement-task.SKILL.md
name: implement-task
description: Implement a task with automated LLM-as-Judge verification per step
argument-hint: Task file [--continue] [--refine] [--human-in-the-loop] [--target-quality] [--max-iterations] [--skip-reviews] [--lenient-threshold] [--model opus|sonnet|haiku] [--strict]

Implement Task with Verification

Your job is to implement solution in best quality using task specification and sub-agents. You MUST NOT stop until it is critically necessary or you are done! Avoid asking questions until it is critically necessary! Launch the developer agent, then the `sdd:code-reviewer`, iterate till issues are fixed, then move to next step!

Execute task implementation steps with automated quality verification using `sdd:code-reviewer` agents for critical artifacts.

User Input

$ARGUMENTS

---

Command Arguments

Parse the following arguments from `$ARGUMENTS`:

Argument Definitions

| Argument | Format | Default | Description | |----------|--------|---------|-------------| | `task-file` | Path or filename | Auto-detect | Task file name or path (e.g., `add-validation.feature.md`) | | `--continue` | `--continue` | None | Continue implementation from last completed step. Launches `sdd:code-reviewer` first to verify state, then iterates with the developer agent. | | `--refine` | `--refine` | `false` | Incremental refinement mode - detect changes against git and re-implement only affected steps (from modified step onwards). | | `--human-in-the-loop` | `--human-in-the-loop [step1,step2,...]` | None | Steps after which to pause for human verification. If no steps specified, pauses after every step. | | `--target-quality` | `--target-quality X.X` or `--target-quality X.X,Y.Y` | `4.0` (standard) / `4.5` (critical) | Target threshold value (out of 5.0). Single value sets both. Two comma-separated values set standard,critical. | | `--max-iterations` | `--max-iterations N` | `3` | Maximum fix→verify cycles per step. Default is 3 iterations. Set to `unlimited` for no limit. | | `--skip-reviews` | `--skip-reviews` | `false` | Skip all per-step code-reviewer checks - steps proceed without quality gates. | | `--lenient-threshold` | `--lenient-threshold X.X` | `3.5` | Lenient threshold (out of 5.0) used for steps with verification level explicitly marked lenient by qa-engineer. | | `--model` | `opus\|sonnet\|haiku` | Unset | Model for **all** sub-agents (developer/implementer AND `sdd:code-reviewer`) that **overrides** every model in the task specification file; when omitted, models come from the task file, otherwise each dispatch's default. | | `--strict` | `--strict` | `false` | Disable the [Iteration Discretion Rule](#iteration-discretion-rule) - a step is marked PASS ONLY when `combined_score >= threshold`, otherwise iterate until `MAX_ITERATIONS` is reached. |

Configuration Resolution

Parse `$ARGUMENTS` and resolve configuration as follows:

# Extract task file (first positional argument, optional - auto-detect if not provided)
TASK_FILE = first argument that is a file path or filename

# Parse --target-quality (supports single value or two comma-separated values)
if --target-quality has single value X.X:
    THRESHOLD_FOR_STANDARD_COMPONENTS = X.X
    THRESHOLD_FOR_CRITICAL_COMPONENTS = X.X
elif --target-quality has two values X.X,Y.Y:
    THRESHOLD_FOR_STANDARD_COMPONENTS = X.X
    THRESHOLD_FOR_CRITICAL_COMPONENTS = Y.Y
else:
    THRESHOLD_FOR_STANDARD_COMPONENTS = 4.0  # default
    THRESHOLD_FOR_CRITICAL_COMPONENTS = 4.5  # default

# Initialize other defaults
MODEL_OVERRIDE = --model value (opus|sonnet|haiku) || none  # none = no override; models come from the task file
MAX_ITERATIONS = --max-iterations || 3  # default is 3 iterations
HUMAN_IN_THE_LOOP_STEPS = --human-in-the-loop || [] (empty = none, "*" = all)
SKIP_REVIEWS = --skip-reviews || false
LENIENT_THRESHOLD = --lenient-threshold || 3.5
REFINE_MODE = --refine || false
CONTINUE_MODE = --continue || false
STRICT_MODE = --strict || false

# Special handling for --human-in-the-loop without step list
if --human-in-the-loop present without step numbers:
    HUMAN_IN_THE_LOOP_STEPS = "*" (all steps)

Context Resolution for `--continue`

When `--continue` is used:

1. **Step Resolution:**

  • Parse the task file for `[DONE]` markers on step titles
  • Identify the last incompleted step
  • Launch the `sdd:code-reviewer` agent to verify the last INCOMPLETE step's artifacts (using the step's `#### Verification` specification embedded in the task file)
  • If the step PASSES per the [Iteration Discretion Rule](#iteration-discretion-rule): Mark step as done and resume from the next step
  • Otherwise: Re-implement the step using the reviewer's issues as feedback and iterate until PASS

2. **State Recovery:**

  • Check task file location (`in-progress/`, `todo/`, `done/`)
  • If in `todo/`, move to `in-progress/` before continuing
  • Pre-populate captured values from existing artifacts

Refine Mode Behavior (`--refine`)

When `--refine` is used, it detects changes to **project files** (not the task file) and maps them to implementation steps to determine what needs re-verification.

1. **Detect Changed Project Files:**

First, determine what to compare against based on git state:

   # Check for staged changes
   STAGED=$(git diff --cached --name-only)
   
   # Check for unstaged changes
   UNSTAGED=$(git diff --name-only)

**Comparison logic:**

| Staged | Unstaged | Compare Against | Command | |--------|----------|-----------------|---------| | Yes | Yes | Staged (unstaged only) | `git diff --name-only` | | Yes | No | Last commit | `git diff HEAD --name-only` | | No | Yes | Last commit | `git diff HEAD --name-only` | | No | No | No changes | Exit with message |

  • If **both staged AND unstaged**: Compare working directory vs staging area (unstaged changes only)
  • If **only staged OR only unstaged**: Compare against last commit

-

Read more
Ships withcontext-engineering-kit

A hand-crafted collection of advanced context engineering techniques and patterns with minimal token footprint, focused on improving agent result quality and predictability.

Get the whole plugin