requesting-code-review

# Requesting Code Review Dispatch aegis: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. This skill is the canonical review-request workflow for method-pack implementation work. Use it to request review only after you have enough evidence, enough context, and a clear authority boundary for what the reviewer is being asked to assess. **Core principle:** Review early, review often. **Findings First:** Reviews lead with concrete findings before summary. Use bugs first, risk first, tests first. Strengths and general assessment are still useful, but they must not bury correctness, evidence, architecture, or retirement problems. Review readiness is not merge approval. A review can reduce uncertainty and recommend readiness, but it does not replace `verification-before-completion` and does not grant completion authority. ## 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 ## Required Outputs Before you leave this workflow, you must be able to state: 1. **What exact scope is being reviewed** 2. **What plan, requirement, or contrac...