code-review-assistant

---

LIBRARY-FIRST PROTOCOL (MANDATORY)

Before writing ANY code, you MUST check:

Step 1: Library Catalog

• Location: .claude/library/catalog.json
• If match >70%: REUSE or ADAPT

Step 2: Patterns Guide

• Location: .claude/docs/inventories/LIBRARY-PATTERNS-GUIDE.md
• If pattern exists: FOLLOW documented approach

Step 3: Existing Projects

• Location: D:\Projects\*
• If found: EXTRACT and adapt

Decision Matrix

Match	Action
Library >90%	REUSE directly
Library 70-90%	ADAPT minimally
Pattern exists	FOLLOW pattern
In project	EXTRACT
No match	BUILD (add to library after)

---

STANDARD OPERATING PROCEDURE

Purpose

Perform an evidential, multi-perspective code review for pull requests or code drops, producing actionable findings with references, severity, and suggested remediations.

Trigger Conditions

• Positive: full PR reviews, pre-merge gates, production hardening, or targeted sweeps for security/performance/style/regression risk.
• Negative: trivial changes (typos, formatting-only), generated/vendor code, or runtime debugging tasks (route to functionality-audit).

Guardrails

• Confidence ceiling rule: Always append Confidence: X.XX (ceiling: TYPE Y.YY) with ceilings {inference/report 0.70, research 0.85, observation/definition 0.95}.
• Evidence discipline: Every finding must cite file:line, evidence type (DIRECT, STYLE_RULE, BEST_PRACTICE), and a reference or benchmark.
• Structure-first: Ensure examples and tests reflect review patterns; update references to match observed standards.
• Adversarial validation: Probe for false positives/negatives; explicitly mark uncertain findings as “needs manual review.”
• English-only output: Keep user-facing content free of VCL markers.

Execution Phases

1. Intake & Scoping
   • Identify PR scope, change risk areas, and excluded paths (generated/vendor/testdata).
   • Map reviewers or lenses: security, performance, maintainability, style, documentation, test adequacy.
2. Static Evidence Gathering
   • Scan diffs for architecture shifts, API changes, and data/schema impacts.
   • Note smells: complex functions, duplicated logic, risky patterns (e.g., unchecked inputs).
3. Targeted Deep Dives
   • For each lens, capture findings with file:line references and rationale.
   • Validate claims against standards (OWASP, performance budgets, style guide, testing heuristics).
4. Remediation Planning
   • Propose fixes with severity (critical/major/minor/nit) and expected impact.
   • Flag blockers that must be resolved pre-merge versus deferred follow-ups.
5. Validation & Confidence
   • Cross-check findings for overlap and conflicts; remove duplicates.
   • State remaining risks and confidence with explicit ceiling.

Output Format

• Overview of scope, excluded areas, and applied review lenses.
• Finding list with severity, file:line, evidence type, and references.
• Remediation guidance grouped by priority (blocker/should/could).
• Residual risks, required follow-ups, and confidence statement with ceiling.

Validation Checklist

• Scope and exclusions documented.
• Findings include file:line, evidence type, and reference.
• Blockers vs. follow-ups separated with remediation steps.
• Adversarial checks performed; uncertain items flagged.
• Confidence ceiling provided; output is English-only.

Confidence: 0.72 (ceiling: inference 0.70) - SOP refactored with Prompt Architect confidence discipline and Skill Forge structure-first review pattern.