make-judgement

name	make-judgement
description	Review implemented changes against TASKS.md, produce review.md and fix-tasks.md for any defects found. Accepts a TASKS.md path and progressively loads group sections for validation. Use when the user says "/make-judgement <tasks-path>", "review the implementation", "judge the changes", or after /drive-outcomes completes for complex multi-group changes.

Make Judgement

Reviews the diff produced by /drive-outcomes against the original TASKS.md. Includes runtime outcome verification — actually running the code against declared fixtures to compare output against success criteria. The build system and auto-review have already caught syntax, wiring, and scope errors during implementation. The judge additionally verifies: does the code produce the right output for real data?

Produces review.md (narrative review) and optionally fix-tasks.md (fix instructions in markdown for any defects found).

Trigger

/make-judgement <tasks-path>

Where <tasks-path> is the path to TASKS.md (e.g., notes/plans/<plan-slug>/TASKS.md).

Pre-flight

Read CONTEXT.md Tooling section and extract {test_command} for runtime verification below.

Step 0: Resolve Agent Mapping

The pipeline uses pluggable agents. Determine which agent to use for each role:

1. Check CLI args: If the user's invocation includes --agent-reviewer=<name> or --agent-architect=<name>, use those agents. CLI args override everything.
2. Check AGENT_CONFIG.md: Read AGENT_CONFIG.md from the project root. If it exists, parse **{role}:** <agent-name> lines. Apply for any role not already set by CLI args.
3. Apply defaults: For any role still unset:
   • reviewer defaults to odd-pipeline:strict-code-reviewer
   • architect defaults to odd-pipeline:software-architect
4. Build resolved mapping: Record which agent will be used for each role.

Throughout this skill, whenever a subagent is launched for a role, use the resolved agent name.

Output

• notes/pr-reviews/<plan-slug>/review.md — narrative review
• notes/pr-reviews/<plan-slug>/fix-tasks.md — fix instructions (if defects found; same markdown format as TASKS.md)
• notes/pr-reviews/<plan-slug>/deferred.md — improvements deferred to future phases

Process

Step 1: Setup

# Determine plan slug from tasks path
PLAN_SLUG=$(basename $(dirname <tasks-path>))
mkdir -p notes/pr-reviews/$PLAN_SLUG

Step 2: Gather Diff Data

Agents use git directly — no wrapper script needed:

# Cumulative diff against main (sees net change, ignores commit noise)
git diff main...HEAD

# Stat summary
git diff --stat main...HEAD

Step 3: Read Context

Read the key inputs:

1. Read TASKS.md at <tasks-path> — this gives you the full group list, architecture_notes, and known_pitfalls.
2. Run git diff main...HEAD for the cumulative diff.

Step 4: Runtime Outcome Verification

Run acceptance commands against declared fixtures to verify outcomes match criteria:

cd <PROJECT_ROOT>

# Run complete test suite — catches regressions
{test_command} 2>&1

For each task group with lib-tdd tasks and success criteria:

1. Check if the criteria reference specific fixture files.
2. Verify those fixture files exist at the declared paths.
3. Run the relevant test(s) and capture stdout/stderr.
4. Compare the test output to the expected criteria values from TASKS.md.
5. If tests fail: note in review. If tests pass but use vacuous assertions (is_finite, circular round-trip): flag as PLACEBO regardless.

Step 5: Per-Group Diff Validation

IMPORTANT: Never launch subagents in background mode (run_in_background). Permission requests from background subagents are invisible — they can only be approved via a webhook, which has a 2-minute timeout. Always launch subagents in foreground.

Extract group sections from TASKS.md by finding ## Task Group: headers. For each group, extract the section boundary (from its header to the next ## Task Group: or end of file).

For each group section, launch the reviewer subagent (resolved in Step 0):

Agent: {reviewer} (subagent, discardable context)

Task: Validate the implementation diff against one group's tasks.

Read:

• The cumulative diff (git diff main...HEAD — run this)
• The task group section (markdown) for group {GROUP_ID} from TASKS.md

For each task in this group, check:

1. Were all required files created/modified/deleted as specified?
2. Does each change match the guidance (structs, functions, signatures)?
3. Are there any changes that are NOT in the tasks (scope creep)?
4. Are there any obvious bugs or issues in the diff?
5. For lib-tdd tasks: Verify the test exists in the codebase, the implementation matches the signature, and the expected behavior is satisfied.

Report per-task:

• ✓ Task fully implemented as directed
• ⚠ Task implemented with issues (describe)
• ✗ Task not implemented or mis-implemented (describe)

After each group's subagent completes, append findings to the review draft.

Step 6: Strategic Review

Launch the architect subagent (resolved in Step 0) for strategic review:

Agent: {architect} (subagent, discardable context)

Task: Strategic review of the implementation.

Read:

• git diff main...HEAD (run this)
• TASKS.md at {TASKS_PATH} (architecture_notes and known_pitfalls are sufficient)

Assess:

1. Does the implementation follow the architecture_notes from TASKS.md?
2. Are module/package boundaries respected?
3. Are the existing codebase patterns followed?
4. Are there strategic concerns (performance, maintainability, API design)?
5. For lib-tdd tasks: Does the implementation satisfy expected_behavior? Is the test adequate?

Report: Strategic assessment (pass / issues / fail), specific concerns, items to defer.

Step 7: Synthesize Judgement

Synthesize all reviews into the final outputs:

1. Write review.md:

   # Review: {Phase Title}
   
   **Tasks**: {tasks-path}
   **Reviewed**: {date}
   
   ## Summary
   
   {Overall assessment — passed, needs fixes, or rejected}
   {Outcome verification: N criteria met, M failed, P adjusted}
   
   ## Per-Task Results
   
   ### {TASK-ID}: {description}
   - **Status**: ✓ Passed | ⚠ Minor Issues | ✗ Failed
   - **Runtime outcome verification**: {findings from step 4: did it work against real fixtures?}
   - **Diff validation**: {findings from step 5}
   - **Strategic review**: {findings from step 6}
   
   ## Issues Found
   
   {Numbered list of issues with severity, location, and recommendation}
   
   ## Deferred Items
   
   {Items flagged for future phases, written to deferred.md}
   

2. Write fix-tasks.md (if issues found):

   • Follows the same markdown format as TASKS.md
   • Contains only fix tasks for the defects identified
   • Each fix task references the specific file and defect
   • Consumed by /drive-outcomes <fix-tasks-path>

3. Write deferred.md:

   • Items flagged by strategic review as worth doing but out of scope
   • Candidates for the next /define-outcomes discussion

Step 8: Handoff

Stage the review artifacts:

git add notes/pr-reviews/<plan-slug>/

Report to the user:

"Review complete. See notes/pr-reviews/<plan-slug>/review.md.

{N} issue(s) found, {M} deferred.

Next steps:

• Fix defects: /drive-outcomes notes/pr-reviews/<plan-slug>/fix-tasks.md
• If all passed: merge the feature branch and proceed to the next phase."

Boundaries

Will:

• Validate diff against TASKS.md per-group (progressive load via markdown headers)
• Perform both detailed (code review) and strategic (architecture) review
• Classify issues by severity
• Produce fix-tasks.md for defects (same markdown format as TASKS.md)
• Defer non-critical improvements to future phases
• Read project's CONTEXT.md for test commands

Will not:

• Re-check build errors (already caught during implementation)
• Re-implement any code changes
• Modify the implementation directly
• Use JSON schemas, index files, or wrapper scripts

Will (new behaviors):

• Verify outcomes by running acceptance commands against declared fixtures
• Flag placebo test patterns (is_finite, circular round-trip, unbounded thresholds)
• Compare test output against success criteria values from TASKS.md