requesting-code-reviewlisted

# Requesting code review A review in a fresh context catches what the author's context hides. The reviewer gets precisely crafted inputs, never your session history. ## When - **Required:** after finishing a plan (whole branch), before merge or PR, and after each task in subagent-per-task execution. - **Useful:** when stuck, before a risky refactor, and after a tricky bug fix. ## How 1. **Fix the range:** `BASE=$(git merge-base <base-branch> HEAD)` (or the task's BASE) and `HEAD=$(git rev-parse HEAD)`. Commit or stash first so the review is of a known state. Include untracked files you created. 2. **Fill `reviewer-prompt.md`** with: what was built, the requirements (task file or plan and spec paths, numbered criteria), the range, the verification commands, the plan's Review focus if it has one, and `{SKILL_DIR}` = this skill's absolute directory. 3. **Dispatch:** - **Default:** dispatch the kit's `reviewer` agent (read-only, on the most capable model) with the filled prompt. For large or high-risk diffs (payments, auth, migrations), run 2–3 reviewers in parallel in one message, each with a different focus (correctness, security, tests). Merge their findings and remove duplicates. - **If delegation is unavailable:** do the review yourself in a *separate pass*. Re-read the requirements, then walk the diff file by file with the checklist. Don't rely on your memory of writing it. 4. **Act on the findings** with receiving-code-review: - fix Critical before anything e