requesting-code-review

<usage_criteria>

• MANDATORY: Before making ANY commit (must review staged/uncommitted changes first), after completing a task/feature, and before merging to main.
• SECURITY GATE: This skill acts as the final firewall. Code MUST be evaluated against security guidelines before it enters history.
• OPTIONAL (still valuable): when stuck on a problem (fresh perspective), before a major refactor (baseline check), or after fixing a complex bug.
• FORBIDDEN: Never skip reviews because a change seems "simple" or "small". </usage_criteria>

<dispatch_workflow> This skill dispatches a parallel review panel: a small set of lane reviewers run concurrently in isolated subagent contexts, each owning a distinct set of dimensions, then you synthesize their reports into one. Parallel + dimension-focused beats a single generalist reviewer — each lane goes deeper, and the lanes cover failure modes a single pass tends to miss. The panel is task-scoped (Step 3): a mandatory Correctness + Security floor ALWAYS runs, and you compose the remaining lanes to fit the change. Execute these steps strictly:

1. GATHER CONTEXT (CRITICAL PRE-COMMIT GATE):

   • For staged changes: Get the diff of the currently staged files using git diff --staged.
   • If the staged diff is empty but the task is complete, check git diff before review so uncommitted work is not accidentally skipped.
   • For intentionally unstaged reviews, state that explicitly in {HEAD_SHA} (for example, "Unstaged Working Tree") and pass the exact git diff output as {CODE_DIFF}.
   • For already committed changes (if specifically requested): Get the exact git SHAs (e.g., BASE_SHA=$(git rev-parse HEAD~1) and HEAD_SHA=$(git rev-parse HEAD)).

2. CHANGE SIZE CHECK (BEFORE DISPATCH): Count lines changed in the diff. If the diff exceeds ~300 lines of meaningful logic changes, STOP and ask the author to split the change. Reviewers cannot give quality feedback on 1000-line diffs; large reviews create rubber-stamping risk. Exception: Complete file deletions and automated refactoring where intent is obvious.

3. SCOPE THE PANEL (choose the lanes to fit THIS change):

   • MANDATORY FLOOR — never skip: Lane 1 Correctness & Security ALWAYS runs (requesting-code-review/reviewer-correctness-security.md). Security is non-negotiable regardless of how "trivial" or "docs-only" the change looks — a tiny change can still commit a secret, weaken auth, or break a contract. Do NOT drop this lane for any task.
   • COMPOSE the remaining 1–3 lanes to fit the change, drawing from the dimension catalog below. Total panel = 2–4 lanes (default 3). For a GENERAL code change, default to Lane 1 PLUS the two standard lanes (3 total: reviewer-design-contracts.md + reviewer-integration-ops.md). For a SPECIALIZED change, replace or add a task-specific lane (author its prompt — see Step 5).
   • Dimension catalog — the starred (*) dimensions are ALWAYS Lane 1's, non-negotiable; the "relevance" filter applies only to the NON-starred ones: assign every non-starred dimension relevant to the diff to exactly one lane (don't drop a relevant one just because it doesn't fit a standard lane): correctness*, security*, auth/credential-token-lifecycle*, conventions/readability, architecture, API/contract stability, backward-compat, integration/impact (graphify), performance, data/persistence & migrations, observability/rollback, testing (adaptive to TDD mode), concurrency/async/state, error-handling/resilience, i18n & accessibility (UI), prompt/LLM-cost (AI features), infra/IaC blast-radius. (* = the floor — always covered by Lane 1.)
     • Note: Lane 1 already inspects the correctness facet of concurrency/async/state and error-handling/resilience (race conditions, error paths). Spinning up a dedicated lane for these on a relevant change is fine — it DEEPENS that facet; the overlap with the floor is intentional, not an "exactly one lane" violation.
   • Example task-specific lanes: schema/DB change → a "Data & Migration Safety" lane; heavy threading/async → a "Concurrency & State" lane; an AI/LLM feature → a "Prompt & Token-Cost" lane; pure UI → a "UX, i18n & Accessibility" lane; infra/Terraform → an "Infra & Blast-Radius" lane.
   • Keep it 2–4 lanes: more fragments attention, fewer loses the cross-check. State the chosen lanes in one line so the user sees the composition (e.g., "Panel: Correctness & Security · Data & Migration Safety · Integration & Ops").