Implement a task step by step with automated LLM-as-Judge verification at the end of each phase

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 Vocabulary (read this first — two different things are called "phase") Term Meaning Workflow Phase 0 5 The stages of THIS skill (select task, load, execute, DoD, move, report). Implementation phase / Phase N A milestone in the TASK file's Phase Overview . It groups steps, names a Reviewer model , and lists the acceptance criteria due at that milestone. This is the unit of code review. Step One sub task file at .specs/sub tasks/<task name /<NN <step slug .md . This is the unit of implementation dispatch. The step name is that file's basename without .md . 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 the last completed step: resolves the implementation phase in progress, completes its outstanding steps, then reviews that phase — see [Context Resolution for continue ]( context resolution for continue). refine refine false Incremental refinement mode detect changes against git, map them to steps, and re verify from the implementation phase that owns the earliest affected step. human in the loop human in the loop [Phase 1,Phase 3,...] None Implementation phases after whose review to pause for human verification. If no phases specified, pauses after every implementation phase. target quality target quality X.X 4.0 Single target threshold value (out of 5.0) applied to every implementation phase review. max iterations max iterations N 3 Maximum fix→re review cycles per implementation phase. Default is 3 iterations. Set to unlimited for no limit. skip reviews skip reviews false Skip all phase reviews steps proceed without quality gates. model opus\ sonnet\ haiku Unset Model for all sub agents (implementation agents AND sdd:code reviewer ) that overrides every model in the task file; when omitted, step models come from the Parallelization Overview and reviewer models from the Phase Overview. strict strict false Disable the [Iteration Discretion Rule]( iteration discretion rule) a phase is marked PASS ONLY when combined score = THRESHOLD , otherwise iterate until MAX ITERATIONS is reached. Configuration Resolution Parse $ARGUMENTS and resolve configuration as follows: 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. 2. 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]( iteration discretion rule): mark it [REVIEWED] and resume at the next implementation phase. Otherwise: enter the [Failure Handling]( failure handling reason about blast radius your most critical judgement) 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. 3. 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: 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 This ensures refine operates on the most recent work in progress 2. 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. Refine mode is the ONE case where you may read sub task files : they are specification artifacts (like the task file), not implementation outputs, and their Expected Output sections are the only place file paths per step are recorded. Read ONLY the Expected Output and Subtasks sections you need. Build a mapping: {changed file → step name → implementation phase} 3. Determine Affected Scope: Find all steps that have associated changed files REFINE FROM PHASE = the earliest implementation phase containing an affected step All implementation phases from that point onwards need re verification Earlier phases (unaffected) are preserved as is 4. Refine Execution: For each affected implementation phase (in order): Launch ONE sdd:code reviewer agent to verify the phase (including the user's changes), passing the 4 standard inputs — Model : MODEL OVERRIDE if set — otherwise that phase's Reviewer model If the phase PASSES per the [Iteration Discretion Rule]( iteration discretion rule): mark it [REVIEWED] , proceed to the next phase Otherwise: enter the [Failure Handling]( failure handling reason about blast radius your most critical judgement) flow, then re review User's manual fixes are preserved implementation agents should build upon them, not overwrite 5. Example: 6. Multiple Files Changed: 7. Staged vs Unstaged Changes: Human in the Loop Behavior Human verification checkpoints are keyed on implementation phases , never on individual steps. 1. Trigger Conditions: After an orchestrator level PASS on the review of an implementation phase in HUMAN IN THE LOOP PHASES After a fix iteration completes for such a phase (before the next re review) If HUMAN IN THE LOOP PHASES is " " , triggers after every implementation phase 2. At Checkpoint: Display the phase's step results summary Display generated artifacts with paths Display the reviewer's combined score and consolidated issues Ask user: "Review phase output. Continue? [Y/n/feedback]" If user provides feedback, incorporate into the next iteration or phase If user says "n", pause workflow 3. Checkpoint Message Format: Task Selection and Status Management Task Status Folders Task status is managed by folder location: .specs/tasks/todo/ Tasks waiting to be implemented .specs/tasks/in progress/ Tasks currently being worked on .specs/tasks/done/ Completed tasks The task's sub task folder .specs/sub tasks/<task name / never moves while the task file travels between these folders, so the Sub Task File paths recorded in the task file stay valid. Status Transitions When Action Start implementation Move task from todo/ to in progress/ Final verification PASS Move task from in progress/ to done/ Implementation failure (user aborts) Keep in in progress/ CRITICAL: You Are an ORCHESTRATOR ONLY Your role is DISPATCH and AGGREGATE. You do NOT do the work. Properly build context of sub agents! CRITICAL: For each sub agent you dispatch, you MUST provide: For an implementation agent (one per step): Task file path That step's sub task file path — exactly one, taken from the Sub Task File column of the Parallelization Overview Value of ${CLAUDE PLUGIN ROOT} so agents can resolve paths like @${CLAUDE PLUGIN ROOT}/scripts/create scratchpad.sh For the sdd:code reviewer (one per implementation phase): Task file path Phase identifier Artifact path(s) reported by that phase's implementation agents CLAUDE PLUGIN ROOT What You DO Read the task file ONCE (Workflow Phase 1 only) Launch sub agents via Task tool Receive reports from sub agents Mark steps and implementation phases complete after the orchestrator level PASS rule on reviewer output as [DONE] Reason about blast radius when a phase review fails, and choose fix / re review models accordingly Aggregate results and report to user What You NEVER Do Prohibited Action Why What To Do Instead Read implementation outputs Context bloat → command loss Sub agent reports what it created Read sub task files (except refine mapping) The implementation agent reads its own sub task file Pass the path from the Parallelization Overview Read reference files Sub agent's job to understand patterns Include path in sub agent prompt Read artifacts to "check" them Context bloat → forget verifications Launch sdd:code reviewer agent Evaluate code quality yourself Not your job, causes forgetting Launch sdd:code reviewer agent Review a step individually Review is a PHASE level gate Review once, at the end of the phase Skip a phase review "because simple" Every phase review is mandatory unless skip reviews Launch sdd:code reviewer anyway Never add comments/marks/notes about results of review, scratchpads, iterations, etc. to the task file. The task file is a specification artifact, not a log. If task not done, it should be visible from code only! You can write only [DONE] mark ever, or nothing at all! Anti Rationalization Rules If you think: "I should read this file to understand what was created" → STOP. The sub agent's report tells you what was created. Use that information. If

implement-task