--continue

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

1. Detect Changed Project Files:
   First, determine what to compare against based on git state:
   bash

   # 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:
   bash

   # User manually fixed src/validation/validation.service.ts
   # (This file was created in Step 2)
   
   /implement my-task.feature.md --refine
   
   # Detects: src/validation/validation.service.ts modified
   # Maps to: Step 2 (Create ValidationService)
   # Action: Launch judge for Step 2
   #   - If PASS: User's fix is good, proceed to Step 3
   #   - If FAIL: Implementation agent align rest of the code with user changes, without overwriting user's changes
   # Continues: Step 3, Step 4... (re-verify all subsequent steps)

6. Multiple Files Changed:
   bash

   # User edited files from Step 2 AND Step 4
   
   /implement my-task.feature.md --refine
   
   # Detects: Files from Step 2 and Step 4 modified
   # Earliest affected: Step 2
   # Re-verifies: Step 2, Step 3, Step 4, Step 5...
   # (Step 3 re-verified even though no direct changes, because it depends on Step 2)

7. Staged vs Unstaged Changes:
   bash

   # Scenario: User staged some changes, then made more edits
   # Staged: src/validation/validation.service.ts (git add done)
   # Unstaged: src/validation/validators/email.validator.ts (still editing)
   
   /implement my-task.feature.md --refine
   
   # Detects: Both staged AND unstaged changes exist
   # Mode: Compares unstaged only (working dir vs staging)
   # Only email.validator.ts is considered for refine
   # Staged changes are preserved, not re-verified
   
   # --
   
   # Scenario: User only has staged changes (ready to commit)
   # Staged: src/validation/validation.service.ts
   # Unstaged: none
   
   /implement my-task.feature.md --refine
   
   # Detects: Only staged changes
   # Mode: Compares against last commit
   # validation.service.ts changes are verified

1. Trigger Conditions:
   • After implementation + judge verification PASS for a step in

     HUMAN_IN_THE_LOOP_STEPS

   • After implementation + judge + implementation retry (before the next judge retry)
   • If

     HUMAN_IN_THE_LOOP_STEPS

     is

     "*"

     , triggers after every step
2. At Checkpoint:
   • Display current step results summary
   • Display generated artifacts with paths
   • Display judge score and feedback
   • Ask user: "Review step output. Continue? [Y/n/feedback]"
   • If user provides feedback, incorporate into next iteration or step
   • If user says "n", pause workflow
3. Checkpoint Message Format:
   markdown

   ---
   ## 🔍 Human Review Checkpoint - Step X
   
   **Step:** {step title}
   **Step Type:** {standard/critical}
   **Judge Score:** {score}/{threshold for step type} threshold
   **Status:** ✅ PASS / 🔄 ITERATING (attempt {n})
   
   **Artifacts Created/Modified:**
   - {artifact_path_1}
   - {artifact_path_2}
   
   **Judge Feedback:**
   {feedback summary}
   
   **Action Required:** Review the above artifacts and provide feedback or continue.
   
   > Continue? [Y/n/feedback]:
   ---

• .specs/tasks/todo/

  - Tasks waiting to be implemented

• .specs/tasks/in-progress/

  - Tasks currently being worked on

• .specs/tasks/done/

  - Completed tasks

• Task file path
• Step number
• Item number (if applicable)
• Artifact path (if applicable)
• Value of

  ${CLAUDE_PLUGIN_ROOT}

  so agents can resolve paths like

  @${CLAUDE_PLUGIN_ROOT}/scripts/create-scratchpad.sh

• Read the task file ONCE (Phase 1 only)
• Launch sub-agents via Task tool
• Receive reports from sub-agents
• Mark stages complete after judge confirmation
• Aggregate results and report to user

• Use

  THRESHOLD_FOR_STANDARD_COMPONENTS

  (default 4.0) for standard steps!
• Use

  THRESHOLD_FOR_CRITICAL_COMPONENTS

  (default 4.5) for steps marked as critical in task file!
• Default is 3 iterations - stop after 3 fix→verify cycles and proceed to next step (with warning)!
• If

  MAX_ITERATIONS

  is set to

  unlimited

  : Iterate until quality threshold is met (no limit)
• Trigger human-in-the-loop checkpoints ONLY after steps in

  HUMAN_IN_THE_LOOP_STEPS

  (or all steps if

  "*"

  )!
• If

  SKIP_JUDGES

  is true: Skip ALL judge validation - proceed directly to next step after each implementation completes!
• If

  CONTINUE_MODE

  is true: Skip to

  RESUME_FROM_STEP

  - do not re-implement already completed steps!
• If

  REFINE_MODE

  is true: Detect changed project files, map to steps, re-verify from

  REFINE_FROM_STEP

  - preserve user's fixes!

• Use foreground agents only: Do not use background agents. Launch parallel agents when possible. Background agents constantly run in permissions issues and other errors.

• Reject Long Reports: If an agent returns a very long report instead of using the scratchpad as requested, reject the result. This indicates the agent failed to follow the "use scratchpad" instruction.
• Judge Score 5.0 is a Hallucination: If a judge returns a score of 5.0/5.0, treat it as a hallucination or lazy evaluation. Reject it and re-run the judge. Perfect scores are practically impossible in this rigorous framework.
• Reject Missing Scores: If a judge report is missing the numerical score, reject it. This indicates the judge failed to read or follow the rubric instructions.

1. Sequential execution respecting step dependencies
2. Parallel execution where dependencies allow
3. Automated verification using judge agents for critical steps
4. Panel of LLMs (PoLL) for high-stakes artifacts
5. Aggregated voting with position bias mitigation
6. Stage tracking with confirmation after each judge passes

$ARGUMENTS

1. Check in-progress folder first:
   bash

   ls .specs/tasks/in-progress/*.md 2>/dev/null

   • If exactly 1 file → Set

     $TASK_FILE

     to that file,

     $TASK_FOLDER

     to

     in-progress

   • If multiple files → List them and ask user: "Multiple tasks in progress. Which one to continue?"
   • If no files → Continue to step 2
2. Check todo folder:
   bash

   ls .specs/tasks/todo/*.md 2>/dev/null

   • If exactly 1 file → Set

     $TASK_FILE

     to that file,

     $TASK_FOLDER

     to

     todo

   • If multiple files → List them and ask user: "Multiple tasks in todo. Which one to implement?"
   • If no files → Report "No tasks available. Create one with /add-task first." and STOP

$ARGUMENTS

1. Search for the file in order:

   in-progress/

   →

   todo/

   →

   done/

2. Set

   $TASK_FILE

   and

   $TASK_FOLDER

   accordingly
3. If not found, report error and STOP

CONTINUE_MODE

1. Identify Last Completed Step:
   • Parse task file for

     [DONE]

     markers on step titles
   • Find the highest step number marked

     [DONE]

   • Set

     LAST_COMPLETED_STEP

     to that number (or 0 if none)
2. Verify Last Completed Step (if any):
   • If

     LAST_COMPLETED_STEP > 0

     :
     • Launch judge agent to verify the artifacts from that step
     • If judge PASS: Set

       RESUME_FROM_STEP = LAST_COMPLETED_STEP + 1

     • If judge FAIL: Set

       RESUME_FROM_STEP = LAST_COMPLETED_STEP

       (re-implement)
3. Skip to Resume Point:
   • In Phase 2, skip all steps before

     RESUME_FROM_STEP

   • Continue execution from

     RESUME_FROM_STEP

REFINE_MODE

1. Detect Changed Project Files:
   bash

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

   Determine comparison mode:

   if STAGED is not empty AND UNSTAGED is not empty:
       # Both staged and unstaged - use unstaged only
       CHANGED_FILES = git diff --name-only  # working dir vs staging
       COMPARISON_MODE = "unstaged_only"
   elif STAGED is not empty OR UNSTAGED is not empty:
       # Only one type - compare against last commit
       CHANGED_FILES = git diff HEAD --name-only
       COMPARISON_MODE = "vs_last_commit"
   else:
       # No changes
       Report: "No project changes detected. Make edits first, then run --refine."
       Exit

2. Load Task File and Extract Step→File Mapping:
   • Read the task file to get implementation steps
   • For each step, extract the files it creates/modifies from:
     • "Expected Output" sections
     • Subtask descriptions mentioning file paths

     • #### Verification

       artifact paths
   • Build mapping:

     STEP_FILE_MAP = {step_number → [file_paths]}

3. Map Changed Files to Steps:

   AFFECTED_STEPS = []
   for each changed_file:
       for step_number, file_list in STEP_FILE_MAP:
           if changed_file matches any path in file_list:
               AFFECTED_STEPS.append(step_number)

   • If no steps matched: "Changed files don't map to any implementation step. Verify manually."
4. Determine Refine Scope:

   • REFINE_FROM_STEP

     = min(AFFECTED_STEPS) # earliest affected step
   • All steps from

     REFINE_FROM_STEP

     onwards need re-verification
   • Steps before

     REFINE_FROM_STEP

     are preserved as-is
5. Store Changed Files Context:

   • CHANGED_FILES

     = list of changed file paths

   • USER_CHANGES_CONTEXT

     = git diff output for affected files
   • Pass this context to judge and implementation agents
   • Agents should build upon user's fixes, not overwrite them

## Implementation Process

• List all steps with dependencies
• Identify which steps have

  Parallel with:

  annotations
• Classify each step's verification needs from

  #### Verification

  sections:

• Agent Type:

  sdd:developer

• Model: As specified in step or

  opus

  by default
• Description: "Implement Step [N]: [Title]"
• Prompt:

Implement Step [N]: [Step Title]

Task File: $TASK_PATH
Step Number: [N]

Your task:
- Execute ONLY Step [N]: [Step Title]
- Do NOT execute any other steps
- Follow the Expected Output and Success Criteria exactly

When complete, report:
1. What files were created/modified (paths)
2. Confirmation that success criteria are met
3. Any issues encountered

• Agent reports what was created → Use this information
• DO NOT read the created files yourself
• This pattern has NO verification (simple operations)

• Update task file:
  • Mark step title with

    [DONE]

    (e.g.,

    ### Step 1: Setup [DONE]

    )
  • Mark step's subtasks as

    [X]

    complete
• Update todo to

  completed

• Agent Type:

  sdd:developer

• Model: As specified in step or

  opus

  by default
• Description: "Implement Step [N]: [Title]"
• Prompt:

Implement Step [N]: [Step Title]

Task File: $TASK_PATH
Step Number: [N]

Your task:
- Execute ONLY Step [N]: [Step Title]
- Do NOT execute any other steps
- Follow the Expected Output and Success Criteria exactly

When complete, report:
1. What files were created/modified (paths)
2. Confirmation of completion
3. Self-critique summary

• Receive the agent's report
• Note the artifact path(s) from the report
• DO NOT read the artifact yourself

sdd:developer

CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}

Read @${CLAUDE_PLUGIN_ROOT}/prompts/judge.md for evaluation methodology.

Evaluate artifact at: [artifact_path from implementation agent report]

**Chain-of-Thought Requirement:** Justification MUST be provided BEFORE score for each criterion.

Rubric:
[paste rubric table from #### Verification section]

Context:
- Read $TASK_PATH
- Verify Step [N] ONLY: [Step Title]
- Threshold: [from #### Verification section]
- Reference pattern: [if specified in #### Verification section]

You can verify the artifact works - run tests, check imports, validate syntax.

Return: scores per criterion with evidence, overall weighted score, PASS/FAIL, improvements if FAIL.

• Calculate median score per criterion
• Flag high-variance criteria (std > 1.0)
• Pass if median overall ≥ threshold

• Check if step is marked as critical in task file (in

  #### Verification

  section or step metadata)
• If critical: use

  THRESHOLD_FOR_CRITICAL_COMPONENTS

• If standard: use

  THRESHOLD_FOR_STANDARD_COMPONENTS

• Present issues to implementation agent with judge feedback
• Re-implement with judge feedback incorporated (align code with requirements, preserve user's changes if in refine mode)
• Re-verify with judge
• Iterate until PASS - continue fix → verify cycle until quality threshold is met or max iterations reached
• If

  MAX_ITERATIONS

  reached (default 3):
  • Log warning: "Step [N] did not pass after {MAX_ITERATIONS} iterations"
  • Proceed to next step (do not block indefinitely)

• Update task file:
  • Mark step title with

    [DONE]

    (e.g.,

    ### Step 2: Create Service [DONE]

    )
  • Mark step's subtasks as

    [X]

    complete
• Update todo to

  completed

• Record judge scores in tracking

HUMAN_IN_THE_LOOP_STEPS

HUMAN_IN_THE_LOOP_STEPS == "*"

---

• [artifact_path_1]
• [artifact_path_2]

Continue? [Y/n/feedback]:

- If user provides feedback: Store for next step or re-implement current step with feedback
- If user says "n": Pause workflow, report current progress
- If user says "Y" or continues: Proceed to next step

---

• Agent Type:

  sdd:developer

• Model: As specified or

  opus

  by default
• Description: "Implement Step [N], Item: [Name]"
• Prompt:

Implement Step [N], Item: [Item Name]

Task File: $TASK_PATH
Step Number: [N]
Item: [Item Name]

Your task:
- Create ONLY [item_name] from Step [N]
- Do NOT create other items or steps
- Follow the Expected Output and Success Criteria exactly

When complete, report:
1. File path created
2. Confirmation of completion
3. Self-critique summary

• Collect all agent reports
• Note all artifact paths
• DO NOT read any of the created files yourself

sdd:developer

CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}

Read @${CLAUDE_PLUGIN_ROOT}/prompts/judge.md for evaluation methodology.

Evaluate artifact at: [item_path from implementation agent report]

**Chain-of-Thought Requirement:** Justification MUST be provided BEFORE score for each criterion.

Rubric:
[paste rubric from #### Verification section]

Context:
- Read $TASK_PATH
- Verify Step [N]: [Step Title]
- Verify ONLY this Item: [Item Name]
- Threshold: [from #### Verification section]

You can verify the artifact works - run tests, check syntax, confirm dependencies.

Return: scores with evidence, overall score, PASS/FAIL, improvements if FAIL.

• Items passed: X/Y
• Items needing revision: [list with specific issues]

• Check if step is marked as critical in task file (in

  #### Verification

  section or step metadata)
• If critical: use

  THRESHOLD_FOR_CRITICAL_COMPONENTS

• If standard: use

  THRESHOLD_FOR_STANDARD_COMPONENTS

• Present failing items with judge feedback to implementation agent
• Re-implement only failing items with feedback incorporated (preserve user's changes if in refine mode)
• Re-verify failing items with judge
• Iterate until ALL PASS - continue fix → verify cycle until all items meet quality threshold or max iterations reached
• If

  MAX_ITERATIONS

  reached (default 3):
  • Log warning: "Step [N] has {X} items that did not pass after {MAX_ITERATIONS} iterations"
  • Proceed to next step (do not block indefinitely)

• Update task file:
  • Mark step title with

    [DONE]

    (e.g.,

    ### Step 3: Create Items [DONE]

    )
  • Mark step's subtasks as

    [X]

    complete
• Update todo to

  completed

• Record pass rate in tracking

HUMAN_IN_THE_LOOP_STEPS

HUMAN_IN_THE_LOOP_STEPS == "*"

---

• [item_1_path]
• [item_2_path]
• ...

Continue? [Y/n/feedback]:

- If user provides feedback: Store for next step or re-implement items with feedback
- If user says "n": Pause workflow, report current progress
- If user says "Y" or continues: Proceed to next step

---

• Did you launch sdd:developer agents for ALL implementations?
• Did you launch evaluation agents for ALL verifications?
• Did you mark steps complete ONLY after judge PASS?
• Did you avoid reading ANY artifact files yourself?

• Agent Type:

  sdd:developer

• Model:

  opus

• Description: "Verify Definition of Done"
• Prompt:

CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}

Verify all Definition of Done items in the task file.

Task File: $TASK_PATH

Your task:
1. Read the task file and locate the "## Definition of Done (Task Level)" section
2. Go through each checkbox item one by one
3. For each item, verify if it passes by:
   - Running appropriate tests (unit tests, E2E tests)
   - Checking build/compilation status
   - Verifying file existence and correctness
   - Checking code patterns and linting
4. You MUST mark each item in task file that passed verification with `[X]`
5. Return a structured report:
- List ALL Definition of Done items
- Status for each:
   - ✅ PASS - if the item is complete and verified
   - ❌ FAIL - if the item fails verification, with specific reason why
   - ⚠️ BLOCKED - if the item cannot be verified due to a blocker
- Evidence for each status
- Specific issues for any failures
- Overall pass rate

Be thorough - check everything the task requires.

• Receive the verification report
• Note which items PASS and which FAIL
• if judge report that all items PASS, you MUST read end of task file to verify that all DoD items are marked with

  [X]

• Think in steps, output each step result separately!
• Do not skip steps!

• Overall ≥ Threshold

  → PASS ✅

• Overall < Threshold

  → FAIL ❌

1. Flag the criterion
2. Present both evaluators' reasoning
3. Ask user: "Evaluators disagree on [criterion]. Review manually?"
4. If yes: present evidence, get user decision
5. If no: use median (conservative approach)

• Task Status:

  done

  ✅
• All Definition of Done items: X/X PASS (100%)

• ✅ PASS - Score >= threshold for step type
• ⚠️ MAX_ITER - Did not pass but MAX_ITERATIONS reached, proceeded anyway
• ⏭️ SKIPPED - Step skipped (continue/refine mode)

• Total steps: X
• Steps with verification: Y
• Passed on first try: Z
• Required iteration: W
• Total iterations across all steps: V
• Final pass rate: 100%

1. [Issue]: [How it was fixed]
2. [Issue]: [How it was fixed]

• [Criterion] in [Step]: Eval 1 scored X, Eval 2 scored Y

• Task moved from

  in-progress/

  to

  done/

  folder
• All step titles marked

  [DONE]

• All step subtasks marked

  [X]

• All Definition of Done items marked

  [X]

1. [Any follow-up actions]
2. [Suggested improvements]

---

• Refine Mode: true

• src/validation/validation.service.ts (modified)

• src/validation/validation.service.ts → Step 2 (Create ValidationService)

undefined

• src/validation/
• src/validation/tests/

Continue? [Y/n/feedback]: Y

• src/validation/validation.service.ts
• src/validation/tests/validation.service.spec.ts

• All criteria met
• Test coverage comprehensive

Continue? [Y/n/feedback]: The error messages could be more descriptive

undefined

1. Present the failure details to user
2. Ask clarification questions that could help resolve
3. Launch sdd:developer agent again with clarifications

1. Present both perspectives with evidence
2. Ask user to resolve: "Judges disagree. Your decision?"
3. Proceed based on user decision

--refine

1. Report: "No project file changes detected since last commit."
2. Suggest: "Make edits to project files first, then run --refine again."
3. Alternatively: "Run without --refine to re-implement all steps."

--refine

1. Report: "Changed files don't match any implementation step's expected outputs."
2. List the changed files detected
3. Suggest: "Verify manually or run without --refine to re-verify all steps."

• Parsed all flags from

  $ARGUMENTS

  correctly
• Used

  THRESHOLD_FOR_STANDARD_COMPONENTS

  for standard steps
• Used

  THRESHOLD_FOR_CRITICAL_COMPONENTS

  for critical steps
• Iterated until quality threshold met (or

  MAX_ITERATIONS

  reached, default 3)
• Triggered human-in-the-loop checkpoints ONLY for steps in

  HUMAN_IN_THE_LOOP_STEPS

• If

  SKIP_JUDGES

  is true: Skipped ALL judge validation
• If

  CONTINUE_MODE

  is true: Verified last step and resumed correctly
• If

  REFINE_MODE

  is true: Detected changed project files, mapped to steps, re-verified from earliest affected step

• Read ONLY the task file (

  $TASK_PATH

  in

  .specs/tasks/in-progress/

  ) - no other files
• Did NOT read implementation outputs, reference files, or artifacts
• Used sub-agent reports for status - did NOT read files to "check"

• ALL implementations done by

  sdd:developer

  agents via Task tool
• ALL evaluations done by

  sdd:developer

  agents via Task tool
• Did NOT perform any verification yourself
• Did NOT skip any verification steps (unless

  SKIP_JUDGES

  is true)

• Each step marked complete ONLY after judge PASS (or immediately if

  SKIP_JUDGES

  )
• Task file updated after each step completion:
  • Step title marked with

    [DONE]

  • Subtasks marked with

    [X]

• Todo list updated after each step completion

• All steps executed in dependency order
• Parallel steps launched simultaneously (not sequentially)
• Each sdd:developer agent received focused prompt with exact step
• All critical artifacts evaluated by judges (unless

  SKIP_JUDGES

  )
• Panel voting used for high-stakes artifacts
• Chain-of-thought requirement included in all evaluation prompts
• Failed evaluations iterated until quality threshold met
• Final report generated with judge confirmation status
• User informed of any evaluator disagreements

• Displayed checkpoint after each step in

  HUMAN_IN_THE_LOOP_STEPS

• Incorporated user feedback into subsequent iterations/steps
• Paused workflow when user requested

• Definition of Done verification agent launched
• All DoD items verified (PASS/FAIL/BLOCKED status)
• Failing DoD items fixed via sdd:developer agents
• Re-verification performed after fixes
• Task moved from

  in-progress/

  to

  done/

  folder
• All DoD checkboxes marked

  [X]

  in task file
• Final verification report presented to user

1. Level: Verification complexity

   • None

     - Simple operations (mkdir, delete) - skip verification

   • Single Judge

     - Non-critical artifacts - 1 judge, threshold 4.0/5.0

   • Panel of 2 Judges

     - Critical artifacts - 2 judges, median voting, threshold 4.0/5.0 or 4.5/5.0

   • Per-Item Judges

     - Multiple similar items - 1 judge per item, parallel execution
2. Artifact(s): Path(s) to file(s) being verified
   • Example:

     src/decision/decision.service.ts

     ,

     src/decision/tests/decision.service.spec.ts

3. Threshold: Minimum passing score
   • Typically 4.0/5.0 for standard quality
   • Sometimes 4.5/5.0 for critical components
4. Rubric: Weighted criteria table (see format below)
5. Reference Pattern (Optional): Path to example of good implementation
   • Example:

     src/app.service.ts

     for NestJS service patterns

| Criterion | Weight | Description |
|-----------|--------|-------------|
| [Name 1]  | 0.XX   | [What to evaluate] |
| [Name 2]  | 0.XX   | [What to evaluate] |
| ...       | ...    | ...         |

• Weights MUST sum to 1.0
• Each criterion has a clear, measurable description
• Typically 3-6 criteria per rubric

| Criterion | Weight | Description |
|-----------|--------|-------------|
| Type Correctness | 0.35 | Types match specification exactly |
| API Contract Alignment | 0.25 | Aligns with documented API contract |
| Export Structure | 0.20 | Barrel exports correctly expose all types |
| Code Quality | 0.20 | Follows project TypeScript conventions |

• 1 (Poor): Does not meet requirements
  • Missing essential elements
  • Fundamental misunderstanding of requirements
• 2 (Below Average): Multiple issues, partially meets requirements
  • Some correct elements, but significant gaps
  • Would require substantial rework
• 3 (Adequate): Meets basic requirements
  • Functional but minimal
  • Room for improvement in quality or completeness
• 4 (Good): Meets all requirements, few minor issues
  • Solid implementation
  • Minor polish could improve it
• 5 (Excellent): Exceeds requirements
  • Exceptional quality
  • Goes beyond what was asked
  • Could serve as reference implementation

1. After a sdd:developer agent completes implementation
2. Read the step's

   #### Verification

   section in the task file
3. Extract: Level, Artifact paths, Threshold, Rubric, Reference Pattern
4. Launch appropriate judge agent(s) based on Level
5. Provide judges with: Artifact path, Rubric, Threshold, Reference Pattern
6. Aggregate judge results and determine PASS/FAIL
7. If FAIL, launch sdd:developer agent to fix issues and re-verify

undefined