FAQ

FAQ

Short, practical answers grounded in what's actually implemented. If an answer here ever conflicts with a linked canonical file, the file wins — see Repository-Documentation-Map.

Does local-code-review run automatically, e.g. on every save or commit? No. It must never be invoked automatically. Every invocation — including every re-review after a fix — requires fresh, explicit user approval scoped to that one run. See policies/invocation-approval.md.

Can local-code-review post comments to my GitHub PR? No. It never touches GitHub, even when you supply an associated PR reference — that reference is only used to reconcile prior findings as context. Reading is read-only; there is no publishing path in this Skill. Use github-pr-review for anything GitHub-facing.

Can github-pr-review review and approve my own PR? It can review its own PR — analysis always runs and produces a real verdict. It will never submit a formal Approve / Request Changes on that work; the result may be published as an informational COMMENT only. See policies/review-authority.md.

If I ask it to "approve if clean," will it approve? Only if independently trusted authorization exists, scoped to that exact PR/HEAD/action, from a source the reviewing agent doesn't control. Natural-language phrasing like "approve if clean" expresses what you want, not authorization to mutate GitHub — ambiguity always fails closed to a non-mutating result. See GitHub-PR-Review-Guide.

Does either Skill ever merge a PR? No. Maximum positive action is Approve; neither Skill merges, deletes branches, or changes approval-count / stale-review branch protection rules.

Does either Skill run my tests, linters, or build? No — not even in github-pr-review's optional repository-backed checkout mode. Cloning PR code is not permission to execute it. Optional runtime-validation evidence uses a repository-declared command under a verified isolation boundary, and is bounded. When that isolation boundary is unavailable, it stays unavailable by default; a user can explicitly, out-of-band, and per-invocation authorize a bounded trusted-host execution path instead, with no sandbox guarantees and clearly-labeled evidence — see docs/features/runtime-validation.md.

How can I tell whether runtime validation actually ran, and where? Check the report's Validation section. Each entry shows executed, failed, skipped, or unavailable with a reason, and every executed/failed entry also carries provenance — sandbox or trusted-host — telling you which backend produced it. If you don't see the section, or every entry is skipped/unavailable, nothing ran on any machine. See Feature-Runtime-Validation-Evidence.

What happens if I give it a Jira ticket it can't reach? It stops that Jira-scoped path with an explicit JIRA CONTEXT UNRESOLVED — it never infers the ticket's content from the key, branch name, or PR title. Supplying no reference at all is fine and never required. See Review-Context-and-Existing-Evidence.

Do I need to give it context (a ticket, an ADR) for a review to work? No. Missing optional context never fails or degrades a review — it proceeds on repository/diff-driven reasoning alone.

Can a P2 finding ever block a clean/approved result? No — never, no matter how many P2 findings exist or how strongly worded one is. Only P0/P1 findings block. See Severity-and-Decision-Model.

Is there a maximum number of re-review loops? Neither Skill has a loop-count concept — that's an orchestration concern outside either Skill's package. local-code-review ships no review-config.yaml and no max_loops setting by design.

Can I run these Skills outside Claude Code? Yes — that's a deliberate design goal. Each Skill is a portable Agent Skills package intended to run on any compatible runtime (Claude Code, Codex, Cursor, OpenCode). See Packaging-and-Portability.

Does it use a specialized reviewer for security, database, or performance? Not a separate persona or a selectable mode. Base review always reasons about every materially implicated dimension; on top of that, when the evidence already gathered warrants it, one or more domain-specific deepening capabilities (Security, Distributed Systems, Database/Migration, Performance, Dependency/Supply-Chain) engage and compose into that same single review — never a separate verdict, and never triggered merely by file type or path. See Specialist-Depth-Review.

How is this different from CodeRabbit / Copilot / Bugbot / etc.? Those tools mostly compete on bug-finding quality inside a managed SaaS product. This repository's durable focus is the governance protocol — who may review, what exact state was reviewed, whether review authority is valid, and how the final decision is produced — as a portable, self-contained fallback that needs no external review service. See AI-Code-Review-Landscape and docs/CODE_REVIEW_COMPARISON.md.

---

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.