Sdd Implement

Implement a task with automated LLM-as-Judge verification for critical steps

dalawwa updated 4mo ago
Claude CodeGeneric
View source ↗
---
name: sdd:implement
description: Implement a task with automated LLM-as-Judge verification for critical steps
argument-hint: Task file [options] (e.g., "add-validation.feature.md --continue --human-in-the-loop")
---

# 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 critically neccesary or you are done! Avoid asking questions until it is critically neccesary! Launch implementation agent, judges, iterate till issues are fixed and then move to next step!

Execute task implementation steps with automated quality verification using LLM-as-Judge for critical artifacts.

## User Input

```text
$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 judge first to verify state, then iterates with implementation 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-judges --skip-judges false Skip all judge validation checks - steps proceed without quality gates.

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
MAX_ITERATIONS = --max-iterations || 3  # default is 3 iterations 
HUMAN_IN_THE_LOOP_STEPS = --human-in-the-loop || [] (empty = none, "*" = all)
SKIP_JUDGES = --skip-judges || false
REFINE_MODE = --refine || false
CONTINUE_MODE = --continue || 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 judge to verify the last INCOMPLETE step's artifacts
    • If judge PASS: Mark step as done and resume from the next step
    • If judge FAIL: Re-implement the step 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
    • This ensures refine operates on the most recent work in progress
  2. Map Changes to Implementation Steps:

    • Read the task file to get the list of implementation steps
    • For each changed file, determine which step created/modified it:
      • Check step's "Expected Output" section for file paths
      • Check step's subtasks for file references
      • Check step's artifacts in #### Verification section
    • Build a mapping: {changed_file → step_number}
  3. Determine Affected Steps:

    • Find all steps that have associated changed files
    • The earliest affected step is the starting point
    • All steps from that point onwards need re-verification
    • Earlier steps (unaffected) are preserved as-is
  4. Refine Execution:

    • For each affected step (in order):
      • Launch judge agent to verify the step's artifacts (including user's changes)
      • If judge PASS: Mark step done, proceed to next
      • If judge FAIL: Launch implementation agent with user's changes as context, then re-verify
    • User's manual fixes are preserved - implementation agent should build upon them, not overwrite
  5. Example:

    # User manually fixed src/validation/va
    

Maintain Sdd Implement?

Let people know it's listed here — add the badge (live metrics, light/dark aware) or a plain link to your README or docs.

[Sdd Implement on getagentictools](https://getagentictools.com/loops/dalawwa-implement-task-with-verification?ref=badge)
npx agentictools info loops/dalawwa-implement-task-with-verification

The second line is the CLI lookup for this page — handy in READMEs and docs.