Imported from CagesThrottleUs/private-ai-harness (skills/requesting-code-review/SKILL.md). Install upstream with npx skills add CagesThrottleUs/private-ai-harness --skill requesting-code-review. Copyright stays with the author.

Requesting Code Review

Route to the right review agent(s) for what you've built. Reviews are mandatory before merge — the type and depth depend on what changed.

Core principle: Review early, review often. After each task, not just at PR time.

pr-reviewer walks every commit in the range, not just the aggregate diff — if it flags the range as too large to review thoroughly, split the PR before re-requesting review rather than pushing for a faster pass.

Review Latency Norm

Slow review decays the whole team's throughput (Google: review delay reduces productivity super-linearly). Target a first reviewer response within one business day. For AI reviewers this is immediate; the norm binds human reviewers in the loop and any queued re-review after a fix.

Reviewing AI-Authored Code (default assumption in this harness)

Most diffs here are AI-authored, so treat every review as an AI-code review unless told otherwise. Two grounded facts set the posture:

• The 2024 DORA report found AI adoption raises throughput but lowers delivery stability (~7.2% per 25% adoption) — "more code, more breakage." Small batch size is the named mitigation — an AI can emit 1,500 plausible lines in a minute; that is the exact shape the evidence says review misses.
• AI code reads cleanly and passes the happy path while hiding specific defect classes; ~76% of developers report frequent AI hallucinations.

Inspect the assumptions behind the code, not just its surface — inputs, outputs, dependencies, permissions, failure modes. Explicitly check for:

Never skip human review for AI-authored code touching authentication, payments, PII, or security boundaries — route it through security-reviewer regardless of size. AI review tools catch ~42–48% of runtime bugs (vs <20% for static analysis) but do not replace the human gate on high-blast-radius code.

Review Agent Roster

Every row above also carries pr-review-non-negotiables — a global, tool-agnostic gate (backward compat, migration, performance, reuse, testing, security, why/ROI, UX, determinism, over/underengineering, compatibility matrix) layered above whichever agent's own dimensions run. pr-reviewer and full-project-reviewer embed it as their own output section; other agents inherit it as a standing check even where it isn't spelled out per-agent.

When to Use Which

Minimum (every PR)

/review pr

Standard (recommended for all feature PRs)

/review all

Runs pr-reviewer + spec-impl-reviewer + test-quality-reviewer + security-reviewer in parallel.

After each task (during subagent-driven development)

/review pr

Catch issues before they compound. Fix before moving to next task.

Before merge (mandatory)

/review all

All four agents. Aggregated report. No merge if any Critical finding.

Full codebase audit (periodic)

/review full

Not per-PR. Use after significant milestones or before production releases.

Language-expert review (on-demand)

/review lang

Use when: C++/Rust code with complex ownership; performance-critical code; onboarding to a codebase with unusual language patterns; before a release on safety-critical code. Asks for language + standard, then runs 10 dimensions.

Reviewer Dispatch Discipline

When dispatching any reviewer agent:

• Pass artifact as a file path, not pasted content — pasted reviewer reports stay resident in context for the rest of the session
• Do not pre-judge findings — never instruct the reviewer to ignore or not flag a specific issue, and never pre-rate severity ("treat X as Minor at most")
• If the reviewer returns findings: dispatch ONE fix agent with the complete findings list, not one fixer per finding
• Re-dispatch the same reviewer after fixes; repeat until PASS
• Before re-triggering any external reviewer (Talos, CodeRabbit, a queued human), run closing-review-loops — an internal self-review must return clean on the current diff first (strong default; override only with a recorded reason). This is what keeps a fixed round from spawning the next.
• A ⚠️ item from the reviewer is yours to resolve — you hold cross-document context the reviewer lacks; treat confirmed gaps as a failed review
• Pattern check before re-dispatch: does this finding's pattern recur elsewhere in the artifact? Fix every occurrence in the same pass — a finding that resurfaces next cycle in a new spot is the cost this discipline exists to cut

How to Request

Quick (most common):

/review all

The review skill collects inputs, dispatches all agents in parallel, aggregates results.

Targeted:

/review security      ← just security
/review spec          ← just spec correctness
/review tests         ← just test quality

Direct from chat:

• "review my PR" → routes to /review pr
• "does this satisfy the spec" → routes to /review spec
• "check my tests" → routes to /review tests
• "security review" → routes to /review security

Act on Feedback

Push back if reviewer is wrong — with technical reasoning and evidence.

For structured triage and resolution of returned findings (not just re-running the same reviewer), invoke receiving-code-review.

Self-Check Before Requesting

Before routing to any review agent, run the design-principles Review Checklist. Sending a design-violated diff multiplies review cost — fix structural violations first.

See design-principles/SKILL.md → Review Checklist.

Integration

• Subagent-driven development: /review pr after each task
• pr-creator: runs /review all automatically before creating PR (Step 5)
• finishing-a-development-branch: runs /review all before merge/PR options
• Ad-hoc: /review <type> any time during development

See review/SKILL.md for the full orchestration logic.