Review Verification Protocol

Use this protocol before reporting any review finding. It is the evidence gate for code-review and every specialist review skill. Skipping it creates false positives that waste reviewer time and erode trust.

Hard gates per finding

Apply these gates once per finding. If a gate fails, omit the finding, downgrade it, or rephrase it as a question. Do not ship soft accusations.

Required checks before flagging

• Read the actual changed code or document, not just a summary.
• Search for usages before claiming something is unused, dead, or unreferenced.
• Use local code navigation for references, implementations, call relationships, and diagnostics when semantic evidence helps. Use direct reads/search for exact strings, docs, config, logs, fixtures, and generated assets, and repository commands for tests, builds, or other validation.
• Check whether validation, authorization, error handling, cleanup, or behavior coverage exists at a higher layer, middleware, caller, transaction boundary, database constraint, generated contract, test harness, or runbook.
• Distinguish incorrect behavior from a valid different style.
• Consider intentional design documented in comments, AGENTS.md, docs, migrations, feature files, or existing architecture.
• Verify framework/library syntax against current docs when the finding depends on version-sensitive APIs.

Issue-type prompts

• Missing behavior, validation, or error handling: Confirm the missing case can occur and matters to a supported user, operator, API, or domain flow.
• Authorization, privacy, or security: Identify the trust boundary, actor, data class, and route/command/path. Use any available repository security process and sanitized evidence; never expose secrets.
• Unused or dead code: Search tests, generated contracts, trait impls, macros, serde names, SQLx mappings, route registration, CLI recipes, and docs links.
• Test weakness: Check whether another layer already covers the behavior; prefer behavior and invariant gaps over implementation-detail assertions.
• Refactor or architecture concern: Name the boundary, ownership, or responsibility that moved, blurred, or coupled.
• Performance or scalability: Confirm a hot path, unbounded input, query-shape change, repeated allocation/I/O, or resource contention risk.
• Concurrency, async, and resources: Check task lifetimes, cancellation, lock scopes, .await points, transactions, handles, pools, backpressure, and cleanup.
• Documentation, workflow, or agent guidance: Check whether the changed doc is authoritative, linked from the right index, concise, and free of conflicting duplicate policy.

Before submitting findings

1. Every finding passed the hard gates.
2. Findings use the format and severity vocabulary from code-review unless the user requested a different format.
3. No finding is style preference, unverified speculation, or unrelated future work.
4. Validation status is truthful: passed, failed, not run, and why.
5. Re-reviews verify previous fixes only unless a fresh full review was requested.

If uncertain, read more context, ask a Question, downgrade the severity, or remove the finding.