Skip to content

Choosing a Review Skill

amirbena edited this page Sep 17, 2026 · 2 revisions

Choosing a Review Skill

A task-oriented decision boundary between local-code-review and github-pr-review, grounded in each Skill's own SKILL.md and the full matrix in docs/CODE_REVIEW_COMPARISON.md §9.

Rule of thumb

No PR yet → local-code-review. A PR exists and you are not its author → github-pr-review.

An implementing Agent never reviews its own PR — see the root README and policies/review-orchestration-policy.md.

By situation

Your situation Use
You have committed, staged, unstaged, or untracked changes and no PR yet local-code-review
You want a coding-agent-ready fix prompt for the findings, locally local-code-review with include_fix_prompt=true
Someone opened a PR you did not author and you want a report github-pr-review (passive)
That same PR, and you want inline comments plus an Approve/Request Changes decision github-pr-review (active — needs review permission)
You want to re-check a PR after a small fix push github-pr-review re-review — see Review-Context-and-Existing-Evidence

Active vs. passive — where that distinction actually exists

local-code-review has no "active" mode. It always returns one structured report to the caller. It never publishes anything, never touches GitHub, and never has an Approve/Request Changes decision — its decision labels are REVIEW CLEAN / CHANGES REQUIRED. Do not assume it can post PR comments; that capability does not exist in this Skill.

github-pr-review has two delivery modes on the same analysis: passive (returns a report, no mutation) and active (may publish inline comments, a summary, and — only under independently trusted authorization — submit Approve / Request Changes). See docs/features/github-review-publication.md.

Delta / re-review behavior — where it exists

  • local-code-review is stateless between invocations. Each run requires fresh, explicit user approval — including every re-review after a fix. Its practical re-review aid is the staged-delta fingerprint short-circuit (recognizing an unchanged staged delta) and, optionally, reconciling an associated PR's prior findings if you supply one.
  • github-pr-review has SHA-bound delta re-review. When the same reviewer re-reviews a PR and the previously reviewed SHA is known reliably, it scopes the new pass to what changed since then, and returns NO NEW DELTA if nothing changed. See docs/features/delta-re-review.md.

Do not assume symmetry the repository doesn't have: local-code-review does not have GitHub-posting behavior, and github-pr-review does not have a "staged/unstaged/untracked" category model — that vocabulary is specific to a local working tree.

Both Skills, always

  • Read-only for your code: neither edits, commits, pushes, or merges.
  • Same shared P0/P1/P2 severity model and mechanical blocking rule.
  • Same optional review-context model (a ticket, an ADR, an HLD, a plan) — see Review-Context-and-Existing-Evidence.
  • One reviewer owner per review scope.

Full side-by-side capability matrix: docs/CODE_REVIEW_COMPARISON.md §9.


Wiki Page Map

Page What it covers
Home Wiki entry point: what the two Skills are and where to go next.
Getting-Started First steps to package and run either Skill.
Choosing-a-Review-Skill How to decide between local-code-review and github-pr-review.
How-the-Review-Model-Works Concept-level walkthrough of the review pipeline shared by both Skills.
Architecture-Overview Component-level map of how the repository's pieces fit together.
Specialist-Depth-Review When and how a review goes deeper than its base pass.
Local-Code-Review-Guide Usage guide for reviewing local, not-yet-PR'd Git changes.
GitHub-PR-Review-Guide Usage guide for reviewing an existing GitHub Pull Request.
Review-Context-and-Existing-Evidence How optional requirements/context and prior review evidence are supplied.
Feature-Pages Index of per-feature capability pages and their shared template.
Feature-Delta-Re-Review How a re-review scopes itself to only what changed since the last pass.
Feature-GitHub-Publication-and-Authorization What a PR review publishes to GitHub and under what authority.
Feature-Human-Style-Review-Output The senior-engineer-voice prose summary output option.
Feature-Requirement-Coverage How supplied requirements are checked and reported as covered or not.
Feature-Runtime-Validation-Evidence How a review can execute commands or reproductions as evidence.
Severity-and-Decision-Model The P0/P1/P2 severity levels and how the merge decision is derived.
Packaging-and-Portability How the Skills go from source repository to a standalone archive.
Development-Workflow Contributor guide for working on this repository itself.
Benchmark-Testing Orientation to this repository's own review-quality benchmark pipeline.
Repository-Documentation-Map Where each concern's canonical, authoritative source lives.
AI-Code-Review-Landscape Neutral snapshot comparing this project against other AI code-review products.
FAQ Short, practical answers to common questions.

Clone this wiki locally