Severity and Decision Model

Severity and Decision Model

The P0/P1/P2 model and the mechanical decision derivation, identical in both Skills. Canonical: shared/policies/severity.md.

The three severities

Severity	Meaning	Blocks?
P0 — Critical	Unsafe to merge: a serious security vulnerability, destructive data loss, a critical correctness failure, a broken production-critical flow. Should be rare and strongly evidence-backed.	Yes
P1 — Significant	Should normally be corrected before approval: a functional bug, a meaningful regression, a concurrency problem, a contract violation, an important missing test around changed behavior.	Yes
P2 — Non-Blocking	A valid engineering improvement that doesn't independently block approval: maintainability, a localized design weakness, a lower-risk test gap. Must not be used for purely cosmetic/stylistic noise.	No — never, regardless of how strongly recommended

Decision derivation is mechanical, not judgment

blocking_findings = { f in findings : severity(f) in {P0, P1} }

blocking_findings is empty      → clean/approved decision
blocking_findings is non-empty  → blocking decision

• local-code-review: REVIEW CLEAN / CHANGES REQUIRED.
• github-pr-review: Approve / Request Changes.

There is no reviewer discretion in this step. A P2 finding never produces a blocking decision by itself, no matter how many exist or how strongly worded. Conversely, a finding that actually warrants blocking must be classified P0 or P1 — the derivation is never bent to match a felt urgency.

This derivation runs exactly once, after the finding set is finalized, and produces exactly one decision value everywhere it's rendered — a report never shows a provisional decision later "corrected."

The verdict is checked again before it's ever shown

Deriving the decision once is not the last safeguard. Immediately before that decision is rendered into a report, or — in github-pr-review ACTIVE mode — submitted as a GitHub review event, a separate read-only comparator checks that the signal about to go out still matches the mechanically-derived decision above. It never derives a second decision of its own and never overrides, corrects, or "fixes up" the one already derived — it only compares. If it finds a mismatch, the inconsistent render or submission is withheld, and an internal-consistency failure is reported in its place, rather than letting a wrong verdict reach the reader. Canonical: shared/policies/verdict-consistency.md.

Repository conventions don't set severity

A target repository's own instructions (AGENTS.md, CLAUDE.md, or other local convention) may legitimately make something a finding. They never, by themselves, determine that finding's severity. A convention-sourced finding is classified under the same P0/P1/P2 definitions as any other finding — it blocks only when it independently meets the P0/P1 bar, never merely because a repository states it emphatically ("must", "never", "always").

An incomplete review never renders as clean

The mechanical derivation above assumes the review reached complete coverage. When review-stopping-criteria.md determines coverage was incomplete, the review's top-level rendered outcome is an explicit incomplete/ungraded result instead — findings already gathered are still reported in full, but the outcome is never mistaken for a clean one.

One severity model, both Skills

Neither Skill defines its own copy of this model — both reference shared/policies/severity.md directly, so a P1 in a local review and a P1 in a GitHub PR review mean exactly the same thing.

---

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.