| name | feature-review |
| description | Use when reviewing an implemented feature against its plan document. Triggers after implementation completes, on "review this", or when checking if code matches specification. |
Feature Review
Review an implemented feature against its design plan. Checks simplicity, correctness, and conventions using single or multi-agent approach.
Core Principles
- Plan as source of truth: The plan document defines what should have been built
- Git diff as scope: Review the actual changes made
- Confidence filtering: Only surface issues with >= 80% confidence
- User decides fixes: Present findings and let user choose what to address
Phase 1: Setup
Goal: Identify the plan and confirm there are changes to review
Actions:
- Create todo list with all phases
- If no plan path in $ARGUMENTS, ask: "Which plan document? (e.g., docs/plans/feature-name.md)"
- Confirm the plan file exists
- Run
git diff main...HEAD --stat -- ':!docs/' ':!*.md' to get code-only changes
- If diff empty, ask: review uncommitted (
git diff --stat) or staged (git diff --cached --stat)?
STOP: Do not proceed until plan path is confirmed and changes exist.
Phase 2: Agent Strategy Selection
Goal: Let user choose review approach based on change size
Actions:
-
Assess complexity from the code-only diff stat:
- Small: <100 lines, 1-3 files
- Medium: 100-500 lines, 3-10 files
- Large: >500 lines or >10 files
-
Ask user using AskUserQuestion:
- Question: "How should I review this implementation?"
- Options:
- Single agent - One comprehensive reviewer (lower token usage)
- Multi-agent - Three parallel reviewers (higher token usage)
- Include complexity assessment and recommendation
STOP: Do not proceed until user chooses approach.
Phase 3: Launch Reviewers
Goal: Get reviews covering all focus areas
If user chose "Multi-agent":
- Launch 3 code-reviewer agents in parallel (single message, multiple Task calls)
- Assign each a different focus:
- Agent 1: Simplicity/DRY/Elegance
- Agent 2: Bugs/Functional Correctness
- Agent 3: Project Conventions
- Each agent receives: plan path, focus area, and
git diff --stat output. Include in prompt: the stat output and instruction "Use Read to inspect the changed files listed above. Do NOT run git or bash commands. If touching UI code, invoke the /ui-guide skill."
If user chose "Single agent":
- Launch 1 code-reviewer agent covering ALL focus areas
- Agent receives: plan path,
git diff --stat output, and instruction "Use Read to inspect the changed files listed above. Do NOT run git or bash commands. If touching UI code, invoke the /ui-guide skill."
Phase 4: Consolidate Findings
Goal: Merge results into actionable list
Actions:
- Collect all issues from reviewer(s)
- Deduplicate if multi-agent (same issue found by multiple reviewers)
- Sort by severity: Critical first, then Important
- Group by file for navigation
Phase 5: Present Findings
Goal: Give user clear picture and options
Actions:
- Present summary: issue counts (Critical / Important), files affected
- List each issue with:
- Severity and confidence
- File:line reference
- Description and suggested fix
- Ask user: "How would you like to proceed?"
- Fix all issues now
- Fix critical issues only
- Review issues individually
- Proceed without fixes
STOP: Do not proceed until user chooses action.
Phase 6: Address Issues
Goal: Fix issues based on user choice
Actions:
- If user wants fixes, work through selected issues
- For each fix: read file section → apply fix → mark todo complete
- After all fixes, run
git diff to show changes made
Skip if: User chose "Proceed without fixes"
Phase 7: Summary
Goal: Wrap up the review
Actions:
- Mark all todos complete
- Summarize: issues found vs fixed, files modified, deferred issues
Output Constraints
- Do NOT fix issues without user consent
- Do NOT skip the confidence threshold (>= 80%)
Red Flags - STOP
| Thought | Reality |
|---|
| "I'll fix these obvious issues" | User decides. Present and ask. |
| "This 50% confidence issue is important" | Below threshold. Don't report it. |
| "I'll skip the multi-agent option" | User chooses approach. Ask them. |
| "The plan is wrong, not the code" | Plan is source of truth. Report deviation. |
