review

name	review
description	Request and handle code reviews with technical rigor. Use after completing a feature or task, before merging. Covers both requesting reviews and responding to feedback — verify before implementing, push back when wrong, no performative agreement.
argument-hint	[what to review or feedback received]

Code Review

"Review early, review often. Verify before implementing. Technical correctness over social comfort."

Part A: Requesting Review

When to Request

• After completing a task or feature
• Before merging to main
• When stuck (fresh perspective)

How to Request

1. Summarize what was built and why
2. Reference the plan/requirements it fulfills
3. List files changed
4. Highlight areas of concern or uncertainty

What to Include

## What I Built
[Brief summary]

## Requirements Met
- [ ] [Requirement 1] — verified by [test/command]
- [ ] [Requirement 2] — verified by [test/command]

## Files Changed
- `path/to/file`: [what changed]

## Areas of Concern
- [Anything you're unsure about]

Part B: Receiving Feedback

The Response Pattern

1. READ — Complete feedback without reacting
2. UNDERSTAND — Restate requirement in own words (or ask)
3. VERIFY — Check against codebase reality
4. EVALUATE — Technically sound for THIS codebase?
5. RESPOND — Technical acknowledgment or reasoned pushback
6. IMPLEMENT — One item at a time, test each

Forbidden Responses

NEVER:

• "You're absolutely right!" (performative agreement)
• "Great point!" / "Excellent feedback!" (empty validation)
• "Let me implement that now" (before verification)

INSTEAD:

• Restate the technical requirement
• Ask clarifying questions
• Push back with technical reasoning if wrong
• Just start working (actions > words)

Handling Unclear Feedback

If any item is unclear: STOP. Ask for clarification before implementing anything. Partial understanding = wrong implementation.

When to Push Back

Push back when:

• Suggestion breaks existing functionality
• Reviewer lacks full context
• Violates YAGNI (unused feature)
• Technically incorrect for this stack
• Conflicts with prior architectural decisions

Acknowledging Correct Feedback

When feedback IS correct:

• OK: "Fixed. [Brief description]"
• OK: "Good catch — [specific issue]. Fixed in [location]."
• OK: [Just fix it and show in the code]
• BAD: "You're absolutely right!" / "Thanks for catching that!"

State the fix instead of thanking.

YAGNI Check

If reviewer suggests "implementing properly": check if the feature is actually used. If unused, propose removing it (YAGNI).

Anti-Patterns

• Performative agreement — State requirement or just act
• Blind implementation — Verify against codebase first
• Batch without testing — One at a time, test each
• Avoiding pushback — Technical correctness > comfort

Integration

• Use after /tdd or /diagnose to get review before proceeding
• Use /verify to confirm all tests pass before requesting review
• Use /grill to re-align if review reveals misunderstanding