requesting-code-review

Topics in the source

• Requesting Code Review
• When to Request Review
• How to Request
• Example
• Common Rationalizations
• Red Flags

Dispatch a code reviewer subagent to catch issues before they cascade. The reviewer gets precisely crafted context for evaluation — never your session's history. Core principle: Review early, review often. Mandatory: After each task in subagent-driven development After completing major feature Before merge to main Optional but valuable: When stuck (fresh perspective) Before refactoring (baseline check) After fixing complex bug 1. Get git SHAs: 2. Dispatch code reviewer subagent: Dispatch a general-purpose subagent, filling the template at code-reviewer.md Placeholders: {DESCRIPTION} - Brief summary of what you built {PLANORREQUIREMENTS} - What it should do {BASESHA} - Starting commit {HEADSHA} - Ending commit 3. Act on feedback: Fix Critical issues immediately Fix Important issues before proceeding Note Minor issues for later Push back if reviewer is wrong (with reasoning) | Excuse | Reality | |--------|---------| | "I'll just review the diff myself instead of dispatching a reviewer" | You're the coordinator — reviewing the diff inline burns the context window you need to keep driving the work. Dispatch a reviewer subagent: the diff and the evaluation live in its context, and only

This is an excerpt. Refer to the complete source and its current requirements.