charlieviettq Requesting code review
When to use
- Before landing a significant PR or slice
- After completing a plan task that touches shared contracts
- When risk is high (auth, money, data migration, agent tools)
When not to use
- Trivial typo-only changes with no behavior impact
- User explicitly wants speed over review
Prepare review packet
- Scope — what changed and what was intentionally out of scope
- Base — branch name and commit range or PR link
- Risk areas — files or behaviors reviewers should scrutinize
- Verification already run — commands + outcomes (paste evidence)
- Questions — specific uncertainties for the reviewer
Review request template
## Review request
- **Scope:**
- **Base / range:**
- **Risk areas:**
- **Verification run:**
- **Open questions:**
- **Severity scale:** Critical / High / Medium / Low / Nit
Using a reviewer subagent (optional)
Only when user or parent agent explicitly allows subagents:
- Pass the packet above; do not pass unrelated context
- Ask for findings ordered by severity with file:line references
- Parent agent integrates findings; subagent does not merge or push
For deep structural review, gstack/code-quality/review may be used as an optional supplement.
After review
- Triage findings with
receiving-code-review - Re-run verification before claiming addressed
Anti-patterns
- "Please review everything" with no scope
- Starting review before tests pass locally
- Treating nitpicks as blockers without trade-off discussion
Related
receiving-code-review, verify-before-done, doubt-driven-review, github-comment-triage
Patterns inspired by obra/superpowers (MIT).