Review Scope Skill
Purpose
Verify that code changes do exactly what they're supposed to do—no more, no less. This is a pass/fail gate, not a feedback session.
When to Use
- TDD verification phase
- PR review for scope compliance
- Any code review requiring scope validation
Inputs Required
context_files
- Implementation plan or requirements document
- Design document (if available)
- Changed files to review
context_data
commit_details: What this change is supposed to dorequirements: List of REQ-* being addressedconstraints: List of CC-* constraints that must be satisfiedallowed_files: Files that may be modified (scope boundary)
Procedure
1. Establish Scope Boundaries
From the inputs, identify:
- What MUST be done (requirements)
- What MUST NOT be done (constraints)
- What files MAY be changed
- What behavior is expected
2. Review Changes
For each changed file:
- Is this file in the allowed set?
- Do changes address stated requirements?
- Are there changes unrelated to requirements?
- Do changes violate any constraints?
3. Report Result
If all checks pass:
ACCEPT
If any check fails, list violations:
VIOLATIONS:
- <file>:<line> - <description in your own words>
- <file> - <description>
[Optional] THEMES: <pattern worth calling out>
Violation Format
Describe violations naturally with location and clear explanation:
- src/parser.rs:45 - Added logging infrastructure not in commit scope
- src/config.rs - Modified file outside allowed set
If you notice patterns across violations, call them out:
THEMES: Multiple changes extend beyond the stated requirements into error handling refactoring
Minimal Change Bias Check
The implementing agent is biased to make the smallest change possible to achieve its goal. After identifying violations, consider:
Do the violations point to any potential refactoring that would make the code more maintainable? Did the implementor resist a better structural solution in favor of a quick fix?
If yes, note this in a REFACTORING section:
REFACTORING: <description of structural improvement the implementor avoided>
This is not a violation—it's a flag for the orchestrator to consider.
What This Skill Does NOT Do
- Suggest improvements unrelated to violations
- Provide general constructive feedback
- Review code style (use review-style for that)
This is a binary gate: ACCEPT or VIOLATIONS. Refactoring notes are optional flags, not blockers.