Review Context and Existing Evidence

Review Context and Existing Evidence

Two distinct concepts, each with its own canonical policy. Both are optional, and both apply identically to local-code-review and github-pr-review. Canonical sources: shared/policies/review-context.md, shared/policies/review-evidence.md.

Review context — what the change is supposed to do

Evidence about intended scope and requirements: explicit instructions, a Jira/tracker ticket, acceptance criteria, a GitHub Issue, an HLD, an ADR, an implementation plan, or a PR/task description. It shapes what the reviewer inspects and what "correct" means for this change — it is never itself a verdict and never substitutes for reading the code.

Two input forms:

• Textual / free-form — consumed directly, no resolution step (pasted ticket text, instructions, an HLD excerpt, …).
• Reference-based — a bare Jira key/URL or GitHub Issue reference is a pointer, not the context itself:
  • A Jira reference is resolved read-only, before review reasoning, via whatever Jira MCP/connector the runtime exposes. If it cannot be resolved, the review returns JIRA CONTEXT UNRESOLVED rather than guessing from the key or branch name. Jira is never mandatory when no reference is supplied.
  • A GitHub Issue reference resolves through read-only GitHub access or pasted text — there is no automatic PR↔Issue discovery.

When context is missing, the review proceeds exactly as if it never existed — no failure, no degradation.

Existing review evidence — what a prior review already established

Previously produced review information that may bear on the current review — prior findings, resolved findings, settled decisions, maintainer clarifications. Distinct from review context, with its own canonical policy (review-evidence.md).

• local-code-review reconciles an optional associated PR reference's prior findings and settled decisions against the current local delta. See policies/pr-context.md.
• github-pr-review always considers the PR's own prior reviews (with their APPROVED / CHANGES_REQUESTED / COMMENTED state), review/issue comments, and thread-resolved state, retrieved paginated-to-exhaustion. See policies/pr-scope.md, "Existing review awareness."

In both Skills, evidence is reconciled against the current target, never blindly inherited: a resolved thread is evidence, not proof — a reintroduced defect is a fresh finding; a changed HEAD re-classifies every prior human finding.

Prior-review / delta-re-review awareness — where it exists

• github-pr-review has SHA-bound delta re-review: when the same reviewer re-reviews and the previously reviewed SHA is known reliably, the pass scopes to what changed since then, returning NO NEW DELTA if nothing did. See policies/reviewer-delta-review.md and, for the deeper stateful reconciliation of prior finding/lifecycle state, policies/stateful-delta-rereview.md.
• local-code-review has no GitHub review history to key off. It is architecturally stateless between invocations; its closest analogues are the staged-delta fingerprint short-circuit and reconciling an associated PR reference's prior findings (above).

Usage guide: docs/features/delta-re-review.md.

Scope-boundary reasoning

When review context is supplied, the reviewer can detect: required behavior that's missing, an implementation that contradicts stated acceptance criteria, unrelated scope expansion, a valid-but-out-of-scope finding, or a repository-policy violation regardless of ticket scope. A stated non-goal narrows what's expected to be built; it never narrows what's expected to be safe. See review-context.md, "Scope-boundary reasoning."

Requesting deeper focus in a named domain

Review context may include an explicit ask for deeper focus in a named domain — "focus especially on database migration safety." That request may raise specialist depth in that domain immediately, but it is additive only: it can never narrow the base review's per-dimension obligation, suppress another materially implicated dimension, lower the evidence bar, or change severity/remediation semantics. Without an explicit ask, specialist-depth activation still proceeds from evidence alone. See Specialist-Depth-Review.

Boundaries

• Read-only: resolving context or evidence never grants either Skill a state-changing capability, including no Jira mutation.
• Never expands the review target: a ticket, Issue, ADR, or PR description never becomes an additional thing under review.
• Never bypasses local-code-review's per-invocation approval gate or github-pr-review's self-review mutation boundary.

---

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.