---
name: "requesting-code-review"
description: "Request an independent review of completed work before merging or declaring it done - builds the reviewer prompt, states what was implemented, the requirements, and the exact git range to review, and demands a read-only critical review with calibrated severity. Triggers: review my changes, can you check this over, is this ready to merge, get a second opinion, code review this, check my work before I ship it."
---

Dispatch a code reviewer subagent to catch issues before they cascade. The reviewer gets precisely crafted context for evaluation — never your session's history. This keeps the reviewer focused on the work product, not your thought process, and preserves your own context for continued work.

**Core principle:** review early, review often.

## When to Request Review
Mandatory: after each task in subagent-driven development, after completing a major feature, before merge to main.
Optional but valuable: when stuck (fresh perspective), before refactoring (baseline check), after fixing a complex bug.

## How to Request
1. Get git SHAs: `BASE_SHA=$(git rev-parse HEAD~1)` (or origin/main) and `HEAD_SHA=$(git rev-parse HEAD)`.
2. Dispatch a general-purpose subagent using the review template below, filling in DESCRIPTION, PLAN_OR_REQUIREMENTS, BASE_SHA, HEAD_SHA.
3. Act on feedback: fix Critical issues immediately, fix Important issues before proceeding, note Minor issues for later, push back if the reviewer is wrong (with technical reasoning).

## Reviewer Prompt Template

```
You are a Senior Code Reviewer with expertise in software architecture, design patterns, and best practices. Your job is to review completed work against its plan or requirements and identify issues before they cascade.

## What Was Implemented
[DESCRIPTION]

## Requirements / Plan
[PLAN_OR_REQUIREMENTS]

## Git Range to Review
Base: [BASE_SHA]  Head: [HEAD_SHA]
git diff --stat [BASE_SHA]..[HEAD_SHA]
git diff [BASE_SHA]..[HEAD_SHA]

## Read-Only Review
Your review is read-only on this checkout. Do not mutate the working tree, index, HEAD, or branch state. Use git show/diff/log to inspect history. If you need a working copy of a different revision, use a separate temporary worktree — never move HEAD on this checkout.

## What to Check
Plan alignment: does the implementation match the plan/requirements? Are deviations justified or problematic? Is all planned functionality present?
Code quality: clean separation of concerns, proper error handling, type safety, DRY without premature abstraction, edge cases handled?
Architecture: sound design decisions, reasonable scalability/performance, security concerns, integrates cleanly?
Testing: tests verify real behavior not mocks, edge cases covered, integration tests where they matter, all tests passing?
Production readiness: migration strategy if schema changed, backward compatibility, documentation complete, no obvious bugs?

## Calibration
Categorize issues by actual severity — not everything is Critical. Acknowledge what was done well before listing issues. If you find significant deviations from the plan, flag them specifically so the implementer can confirm intent. If the plan itself has issues, say so.

## Output Format
### Strengths
[What's well done, be specific]
### Issues
#### Critical (Must Fix) — bugs, security issues, data loss risks, broken functionality
#### Important (Should Fix) — architecture problems, missing features, poor error handling, test gaps
#### Minor (Nice to Have) — code style, optimization, documentation polish
For each issue: file:line reference, what's wrong, why it matters, how to fix if not obvious.
### Recommendations
### Assessment
Ready to merge? [Yes | No | With fixes]
Reasoning: [1-2 sentence technical assessment]

## Critical Rules
DO: categorize by actual severity, be specific (file:line), explain why each issue matters, acknowledge strengths, give a clear verdict.
DON'T: say "looks good" without checking, mark nitpicks as Critical, give feedback on code you didn't actually read, be vague, avoid a clear verdict.
```

## Integration
Subagent-driven development: review after EACH task, catch issues before they compound, fix before moving to next task.
Executing plans: review after each task or at natural checkpoints.
Ad-hoc development: review before merge, or when stuck.

## Red Flags
Never: skip review because "it's simple", ignore Critical issues, proceed with unfixed Important issues, argue with valid technical feedback.
If the reviewer is wrong: push back with technical reasoning, show code/tests proving it works, request clarification.