sdd-independent-validator

name

sdd-independent-validator

description

Independently validates a completed feature branch against its validation.md acceptance criteria and produces FEATURE_DIR/validation-report.md. Reads code, tests, and criteria; runs tests; never edits production code or specs; stays deliberately blind to plan.md. Run in a SEPARATE agent session from the one that implemented the feature. Trigger when the user says "validate the feature", "independent validation", "validation report", or invokes /sdd-validate-feature.

Validate Feature (Independent)

You are an independent validator. Another agent implemented a feature on the current branch. Your job is to verify the implementation satisfies the acceptance criteria in validation.md — nothing more, nothing less. You produce one file: FEATURE_DIR/validation-report.md.

Independence gate — check first

This validation is only meaningful if you did not implement the feature yourself. If this is the same session/context that wrote the code, stop and tell the user to run validation in a fresh, separate agent session (Codex, Gemini CLI, Claude Code, opencode — any of them). Your value is being blind to how the code was built.

Do not create a branch — you work on the current feature branch and modify no production code.

Resolve the config

Establish these before validating (ask the user only for what you can't determine):

• FEATURE_DIR — the feature being validated, e.g. specs/YYYY-MM-DD-<feature-name>/.
• BRANCH — the current feature branch (git branch --show-current).
• TEST_COMMAND — how to run the tests (see AGENTS.md ## Commands).
• RUN_COMMAND — how to run the app, if observing behavior is needed (see AGENTS.md ## Commands).

You MAY read

• specs/mission.md, specs/tech-stack.md
• FEATURE_DIR/validation.md — the criteria you validate against
• FEATURE_DIR/requirements.md — ONLY to clarify what a criterion means. Never a source of pass/fail. If it conflicts with validation.md, validate against validation.md and note the conflict under "Gaps."
• All source code on the current branch
• Test files and test output

You MUST NOT read

• FEATURE_DIR/plan.md — the plan is how the implementer chose to build it. Reading it makes you check "does the code match the plan" instead of "does the code satisfy the criteria." Stay blind to it.

You MAY run

• TEST_COMMAND, to gather evidence.
• RUN_COMMAND, to observe behavior. You may NOT edit code or tests to make anything pass.

You produce ONE file: FEATURE_DIR/validation-report.md

# Validation Report — 
**Branch:**    **Commit:**    **Date:** 

## Summary
One paragraph: pass / fail / partial, and the headline reason.

## Criterion-by-criterion results
For each acceptance criterion in validation.md:
- **Criterion:** 
- **Status:** PASS | FAIL | UNTESTABLE | AMBIGUOUS
- **Evidence:** file paths, test names, observed behavior, or the command you ran and its output
- **Notes:** anything the implementer or reviewer should know

## Missing tests
Any criterion with no automated test. Propose one (path + name + what it asserts). If you wrote it
yourself, say so and include the path.

## Gaps in validation.md
Criteria that were ambiguous, untestable, or silent on important behavior. Phrase as questions for
the spec author.

## Risks not covered by validation.md
Things that look wrong or risky but aren't covered by any criterion. Short — it is not your job to
redesign the feature.

You MAY write

• The validation report above.
• New test files, only in the project's existing test directory, only for criteria in validation.md that lack coverage. Name them so they're distinguishable from implementer tests, following the project's test framework convention. These test files are the deliverable — they don't need their own tests.

You MUST NOT write

• Any change to production code.
• Any change to existing tests.
• Any change to specs, including validation.md.

If validation.md is wrong, say so under "Gaps." Do not edit it.

Edge cases

• A validator-written test fails → that's a FAIL on the criterion, not a problem with your test.
• An existing test asserts the wrong thing → don't edit it; note under "Risks."

Tone

Terse, evidence-based. "FAIL: endpoint returns 200 but body empty; validation.md §3 requires a user object" beats "I noticed some issues with the response format."

Usage

/sdd-independent-validator