| name | review-impl |
| description | Read-only verdict on whether an implementation meets its spec: each acceptance criterion classified, unintended changes flagged, test coverage checked. Writes nothing; returns COMPLETE, INCOMPLETE, or NEEDS FIXES. Use to judge finished work; use drift to record that judgement on the spec, wrapup to close the spec out. |
Review Implementation Against Spec
Compare what was actually implemented against what the spec or task asked for.
Catch deviations, missed requirements, and unintended side effects.
Step 0: Parse arguments
Extract the spec or task file path from the first token. Optionally accept a
commit range (e.g., abc123..HEAD) as the second token.
If no commit range is given, infer it: find the commit that added/modified the
spec's task breakdown or the commit tagged in the task's status change to "Done".
Step 1: Load the requirements
- Read the spec or task file in full. Parse YAML frontmatter to extract
title, status, depends_on, affects, effort.
- Extract acceptance criteria, "What to do" steps, "Tests" requirements, and
"Boundaries" constraints from the body.
- Use the
affects list from frontmatter as the expected set of files that
should be modified by this implementation.
- If reviewing a full spec (non-leaf), read all child spec files in the
subdirectory and aggregate requirements recursively.
Step 2: Load the implementation
- Get the diff for the commit range:
git diff <range> --stat for file list,
then git diff <range> for full changes.
- Get the commit messages:
git log <range> --oneline for the narrative.
- Group changes by file to understand what was touched.
Step 3: Check acceptance criteria
For each acceptance criterion or "What to do" step:
- Search the diff for evidence that it was implemented.
- Classify as: Implemented, Partially implemented, Not implemented, or
Cannot determine.
- For "Partially implemented", explain what's missing.
Report: checklist of criteria with status.
Step 4: Check for unintended changes
Compare files touched in the diff against the affects list from frontmatter
and files listed in the spec body's "What to do" section:
- Flag files modified that aren't in
affects or mentioned in "What to do".
- For each unexpected file, read the diff hunk and assess whether the change is:
- Necessary (e.g., import added by a refactor)
- Cleanup (formatting, dead code removal)
- Scope creep (new behavior not in the spec)
- Regression risk (modifying unrelated logic)
Report: list of unexpected changes with assessment.
Step 5: Check test coverage
For each "Tests" requirement in the spec/task:
- Search for a matching test function in the diff or codebase.
- Verify the test actually tests what the requirement asks for (not just that a
test with a similar name exists).
- Flag requirements with no corresponding test.
- Discover and run the affected repository's documented test command.
Report: test coverage against requirements.
Step 6: Check boundary compliance
For each "Boundaries" constraint ("do NOT change X"):
- Search the diff for changes to the forbidden area.
- Flag violations with the specific diff hunk.
Report: boundary violations, or "Boundaries: respected".
Step 7: Check documentation
If the spec or task mentions documentation updates:
- Verify the relevant doc files were modified in the diff.
- Check that new API routes, env vars, or CLI flags appear in the docs.
- Cross-reference repository instructions and public documentation for
consistency.
Report: documentation gaps, or "Docs: OK".
Step 8: Summary
Present a structured report:
## Implementation Review: <spec/task name>
Commits: N commits, M files changed, +A/-D lines
Commit range: <range>
### Acceptance Criteria
- [x] <criterion> — implemented in <file>
- [ ] <criterion> — NOT implemented
- [~] <criterion> — partial: <what's missing>
### Unintended Changes
- <file>: <assessment>
### Test Coverage
- [x] <requirement> — covered by TestFoo
- [ ] <requirement> — NO TEST
### Boundary Compliance
- OK / <violations>
### Documentation
- OK / <gaps>
### Verdict: COMPLETE / INCOMPLETE / NEEDS FIXES
Do NOT modify any files. This skill is read-only. If issues are found, list
specific remediation steps for the user to act on.
