-
Notifications
You must be signed in to change notification settings - Fork 2
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.
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.
| 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
|
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.
-
local-code-reviewis 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-reviewhas 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 returnsNO NEW DELTAif nothing changed. Seedocs/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.
- 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.
| 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. |