21 added, 94 removed. Audit A to A.
---
name: requesting-code-review
description: Use when completing tasks, implementing major features, or before merging to verify work meets requirements
---
# Requesting Code Review
- 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 major feature
- - Before merge to main
-
- **Optional but valuable:**
-
- - When stuck (fresh perspective)
- - Before refactoring (baseline check)
- - After fixing complex bug
-
- ## How to Request
-
- **1. Get git SHAs:**
-
- ```bash
- BASE_SHA=$(git rev-parse HEAD~1) # or origin/main
- HEAD_SHA=$(git rev-parse HEAD)
- ```
-
- **2. Dispatch code reviewer subagent:**
-
- Dispatch a `general-purpose` subagent, filling the template at [code-reviewer.md](code-reviewer.md)
-
- **Placeholders:**
-
- - `{DESCRIPTION}` - Brief summary of what you built
- - `{PLAN_OR_REQUIREMENTS}` - What it should do
- - `{BASE_SHA}` - Starting commit
- - `{HEAD_SHA}` - 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)
-
- ## Example
-
- ```
- [Just completed Task 2: Add verification function]
-
- You: Let me request code review before proceeding.
-
- BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
- HEAD_SHA=$(git rev-parse HEAD)
-
- [Dispatch code reviewer subagent]
- DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types
- PLAN_OR_REQUIREMENTS: Task 2 from docs/superpowers/plans/deployment-plan.md
- BASE_SHA: a7981ec
- HEAD_SHA: 3df7661
-
- [Subagent returns]:
- Strengths: Clean architecture, real tests
- Issues:
- Important: Missing progress indicators
- Minor: Magic number (100) for reporting interval
- Assessment: Ready to proceed
-
- You: [Fix progress indicators]
- [Continue to Task 3]
- ```
-
- ## Integration with Workflows
+ Dispatch a reviewer subagent on completed work. Feed it crafted context (description + requirements + git range) — never your session history. Keeps the reviewer on the work product and preserves your own context.
- **Subagent-Driven Development:**
+ **Review early, review often.**
- - Review after EACH task
- - Catch issues before they compound
- - Fix before moving to next task
+ Brian's stack already ships a purpose-built `code-reviewer` agent + the **Agent Diversity Review gate** (`[[agent-selection]]`). Prefer the named agent over a bare `general-purpose` spawn; this skill is the request protocol that complements both.
- **Executing Plans:**
+ ## When to request
- - Review after each task or at natural checkpoints
- - Get feedback, apply, continue
+ Mandatory:
- **Ad-Hoc Development:**
+ 1. Before merge to main
+ 2. After each task in subagent-driven development
+ 3. After completing a major feature
- - Review before merge
- - Review when stuck
+ Optional: when stuck (fresh eyes), before a refactor (baseline), after a complex bugfix.
- ## Red Flags
+ ## How to request
- **Never:**
+ 1. Get SHAs — `BASE_SHA=$(git rev-parse origin/main)`, `HEAD_SHA=$(git rev-parse HEAD)`.
+ 2. Spawn the `code-reviewer` agent (or `general-purpose` filling [code-reviewer.md](code-reviewer.md)).
+ 3. Fill placeholders: `{DESCRIPTION}` (what you built), `{PLAN_OR_REQUIREMENTS}` (what it should do), `{BASE_SHA}`, `{HEAD_SHA}`.
- - Skip review because "it's simple"
- - Ignore Critical issues
- - Proceed with unfixed Important issues
- - Argue with valid technical feedback
+ ## Act on feedback
- **If reviewer wrong:**
+ 1. Fix Critical immediately; fix Important before proceeding.
+ 2. Note Minor for later.
+ 3. Push back with technical reasoning if the reviewer is wrong — see `[[receiving-code-review]]`.
- - Push back with technical reasoning
- - Show code/tests that prove it works
- - Request clarification
+ ## Never
- See template at: [code-reviewer.md](code-reviewer.md)
+ - Skip review because "it's simple".
+ - Ignore Critical, or proceed with unfixed Important.
+ - Argue with valid technical feedback.