Wrong skill? Pre-commit/push → unified-commit-gate. Reviewing someone else's PR → providing-code-review. Implementing feedback you received → receiving-code-review. Inter-agent file handoff → inter-agent-review-protocol.

Requesting Code Review

Use the repository's review router and native clearance parser before dispatch. Review missing or invalidated classes; preserve an existing clean independent review while its content, coverage, dependencies and guidance remain valid.

Strategy before execution

Before every automated review or test/check pass, resolve a snapshot-bound REUSE, WAIT, RUN_MINIMAL, REVIEW_REQUIRED or STOP decision at its supported execution/dispatch boundary. Reuse valid coverage or join its active producer. Missing/stale decisions refuse; unknown coverage stays conservative. No model calls or recursive checks inside strategy. Status/HEAD changes, clean reviews and score targets alone never justify another expensive pass.

Before presenting completed work

Use the actual target snapshot, including relevant staged/unstaged changes. In superpowers-plus, run tools/review.sh route <paths> and read tools/push-readiness.sh --json or tools/review-preflight.py --staged. Never infer staleness from HEAD alone or parse a guessed sentinel format.

• Valid content-scoped clearance: reuse it, including after tree-identical merges, amends or history-only commits. Do not dispatch another reviewer.
• Missing/invalidated clearance: obtain the required initial or affected-delta review and use the native writer after genuine review judgment.
• Failed/malformed evidence: STOP and diagnose; preserve it rather than deleting the sentinel to force a clean slate.
• Uncommitted relevant changes: review that exact snapshot. Do not stash or commit merely to make the status look clean.

One initial independent review is sufficient when clean and above the required floor. Reopen for material changed scope, an unresolved actionable finding, invalidated evidence or an explicitly justified independent safety lens. Report a low score without new actionable evidence; never chase it by redispatching.

Progress updates may report existing results without launching tests or review. A final completion claim needs valid evidence for the actual presented scope. Keep review evidence in its native artifact; do not force process banners into every human-facing message or treat publication permission as review clearance.

How to Request

1. Gather context

BASE_SHA=$(git merge-base HEAD main)   # or origin/dev, origin/main
HEAD_SHA=$(git rev-parse HEAD)
git diff $BASE_SHA..$HEAD_SHA          # the diff to review

2. Dispatch code-review-battery

Follow the code-review-battery procedure:

1. Triage the diff → select relevant specialist reviewers
2. Dispatch all activated reviewers in parallel via sub-agent-code-reviewer
3. Each reviewer gets: reviewer prompt + full diff + source context (callers, field readers, state types)
4. Aggregate findings → triple-filter → classify Implement/Defer/Reject

3. Act on findings

4. Confirm verdict

Only proceed to presenting work as "ready" when battery verdict is PASS or PASS_WITH_NITS (with nits fixed).

Integration with Workflows

Anti-Patterns

Companion Skills

• code-review-battery: The review engine this skill dispatches
• progressive-code-review-gate: Fires at commit time (uses battery) — handles "ready to commit/push" triggers
• verification-before-completion: Completion gate that requires review evidence
• providing-code-review: Engineering rigor checklist (informs reviewer focus)