Implement Task

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! Dispatch one implementation agent per step, then — when every step of an implementation phase is done — launch ONE sdd:code-reviewer for that phase, iterate till issues are fixed, then move to the next phase!

Execute task implementation steps with automated quality verification using a single sdd:code-reviewer agent per implementation phase.

User Input

$ARGUMENTS

Vocabulary (read this first — two different things are called "phase")

Command Arguments

Parse the following arguments from $ARGUMENTS:

Argument Definitions

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

# Single quality threshold — there is exactly one, and it is NEVER read from the task file
THRESHOLD = --target-quality value || 4.0

# 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_PHASES = --human-in-the-loop || [] (empty = none, "*" = all implementation phases)
SKIP_REVIEWS = --skip-reviews || false
REFINE_MODE = --refine || false
CONTINUE_MODE = --continue || false
STRICT_MODE = --strict || false

# Special handling for --human-in-the-loop without a phase list
if --human-in-the-loop present without phase identifiers:
    HUMAN_IN_THE_LOOP_PHASES = "*" (all implementation phases)

`THRESHOLD` is the ONLY quality threshold in this workflow. There is no separate standard/critical/lenient value, no comma-separated form, and no threshold anywhere in the task file — the planning agents are forbidden from writing one.

Context Resolution for --continue

When --continue is used, state is resolved by implementation phase, then step:

1. Phase and Step Resolution:

• Read the task file's ### Parallelization Overview step table and ### Phase Overview.
• A step is complete when its row in the step table is marked [DONE].
• An implementation phase is complete when its #### Phase N heading carries either marker: [REVIEWED] (its review ran and passed) or [REVIEWED-SKIPPED] (its steps finished and its review was deliberately suppressed by an earlier --skip-reviews run).
• RESUME_PHASE = the first implementation phase marked neither [REVIEWED] nor [REVIEWED-SKIPPED]. Treating [REVIEWED-SKIPPED] as unfinished would re-run exactly the review the user suppressed.
• RESUME_STEPS = the steps of RESUME_PHASE that are not [DONE], in dependency order.

1. Verify the resumed phase's existing work:

• If RESUME_PHASE already has some [DONE] steps but neither marker, and RESUME_STEPS is empty (all steps done, review never ran):
• If `SKIP_REVIEWS` is true: launch nothing. Mark the phase [REVIEWED-SKIPPED] and resume at the next implementation phase.
• Otherwise: launch the sdd:code-reviewer for RESUME_PHASE (passing the 4 inputs documented in Workflow Phase 2) — Model: MODEL_OVERRIDE if set — otherwise that phase's Reviewer model.
• If the phase PASSES per the Iteration Discretion Rule: mark it [REVIEWED] and resume at the next implementation phase.
• Otherwise: enter the Failure Handling flow for that phase.
• If RESUME_STEPS is non-empty: dispatch those steps first, then review the phase as normal — and SKIP_REVIEWS still suppresses that review, marking the phase [REVIEWED-SKIPPED] instead.

1. 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 steps, then re-verifies from the implementation phase that owns the earliest affected step.

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:

• If both staged AND unstaged: Compare working directory vs staging area (unstaged changes only)
• If only staged OR only unstaged: Compare against last commit
• This ensures refine operates on the most recent work in progress

1. Map Changes to Steps:

• Read the task file's ### Parallelization Overview to get every step name, its implementation phase, and its Sub-Task File path.