requesting-code-reviewlisted

# Requesting Code Review Dispatch a code reviewer subagent to catch issues before they cascade. Request fresh context explicitly, then give the reviewer a crafted evaluation package. Do not let a fork default inherit the author's reasoning: that biases the review toward the implementation it should challenge. **Core principle:** Review in proportion to risk, with independence where it changes confidence. - Low-risk work: focused tests plus self-review. One branch review is optional. - Medium-risk work: one independent review at the task, milestone, or branch boundary. - High-risk work: review each risky boundary and perform final independent verification. Auth, billing, security, concurrency, schema or data changes, and external side effects are high risk. Do not stack task and branch reviews unless the risk warrants both. A stalled or uncertain change may be reviewed earlier regardless of tier. ## The Review **Scope the diff correctly.** BASE_SHA is the branch point, `git merge-base <base-branch> HEAD`, or the exact commit you recorded before the work began; HEAD_SHA is the current commit. Never default to `HEAD~1`: it silently drops all but the last commit of a multi-commit task, so the reviewer sees a fraction of the change and approves work it never read. **Package the diff (preferred).** Generate a review package so the diff never enters your own context and the reviewer reads one file instead of re-deriving it. Use the `review-package` helper that ships wit