Mandatory verification steps for all code reviews to reduce false positives. Load this skill before reporting ANY code review findings.
user-invocable
false
Review Verification Protocol
This protocol MUST be followed before reporting any code review finding. Skipping these steps leads to false positives that waste developer time and erode trust in reviews.
Anti-confabulation (gate 0 — runs before every other gate)
Before issuing any verdict — flag, reject, or downgrade a finding — you MUST echo the exact artifact you are judging, quoted from a source you read in this turn:
For a code finding: the file:line plus the cited code, read freshly now (not recalled from earlier in the session).
For a diff review: the actual diff hunk under review.
The artifact is the only source of truth. Never infer what you are reviewing from the branch name, the working directory, surrounding files, or recollection. If your mental model differs from the freshly read source, the source wins. A verdict issued without a same-turn echo of its target is invalid — emit the echo first, or do not emit the verdict.
This gate exists because an LLM under contextual priming will confidently flag code that is not in the file. It runs before the hard gates below.
Hard gates (sequenced)
Complete these in order before you add a finding. Skip a gate only when it clearly does not apply (e.g. skip the usages gate if the finding is not about dead code or “unused”).
— You name the exact file path(s) and the function, , or block you read in full (not only a diff hunk or partial snippet).
Read scope
Pass:
impl
macro_rules!
Usages (dead / unused) — Pass: You ran a repo-wide reference search (rg, IDE references, or equivalent) and either state zero matches for the symbol you call unused, or list each match and why it still supports the finding.
Surrounding behavior — Pass: You checked callers, trait impls, #[cfg], or error propagation that could make the pattern intentional; note one concrete checked location (path + rough location) or state “none relevant after search.”
Edition and API — Pass: You opened the relevant Cargo.toml for the crate under review and either quote the [package] edition = "..." line or state the default edition applies and name the manifest path you checked.
Wrong vs style — Pass: In one sentence, you explain why the code is incorrect, unsound, or risky for this project—not merely a different valid style.
Pre-Report Verification Checklist
Before flagging ANY issue, verify:
I read the actual code - Not just the diff context, but the full function/impl block
I searched for usages - Before claiming "unused", searched all references
I checked surrounding code - The issue may be handled elsewhere (trait impls, error propagation)
I verified syntax against current docs - Rust edition, crate versions, and API changes
I checked the project's Rust edition - Edition 2021 vs 2024 changes what is required vs optional (see Edition-Aware Review)
I distinguished "wrong" from "different style" - Both approaches may be valid
I considered intentional design - Checked comments, project conventions (e.g. AGENTS.md or CLAUDE.md), architectural context
Verification by Issue Type
"Unused Variable/Function"
Before flagging, you MUST:
Search for ALL references in the codebase (grep/find)
Check if it's pub and used by other crates in the workspace
Check if it's used via derive macros, trait implementations, or conditional compilation (#[cfg])
Verify it's not a trait method required by the trait definition
Common false positives:
Trait implementations where the method is defined by the trait
#[cfg(test)] items only used in test builds
Derive-generated code that uses struct fields
Types used via From/Into conversions
"Missing Error Handling"
Before flagging, you MUST:
Check if the error is handled at a higher level (caller propagates with ?)
Check if the crate has a top-level error type that wraps this error
Verify the unwrap() isn't in test code or after a safety-ensuring check
Common false positives:
unwrap() in tests and examples (expected pattern)
expect("reason") after validation (e.g., regex::Regex::new on a literal)
Error propagation via ? (the caller handles it)
let _ = tx.send(...) — intentional when receiver may have dropped
Verify the identifier actually leaks — types, modules, and functions are NOT hygienic in macro_rules!
Check if $crate is used correctly for exported macros (not crate or self)
Confirm ::core:: / ::alloc:: paths are needed (only for macros used in no_std contexts)
Check whether the macro is internal-only or #[macro_export]
Common false positives:
Non-hygienic type names in internal macros — only matters for exported macros
$crate not used in macros that are only pub(crate) — $crate is for cross-crate usage
Using ::std:: in macros for std-only crates — only flag if crate supports no_std
"Procedural Macro Performance"
Before flagging, you MUST:
Verify the macro is actually in a proc-macro crate (check Cargo.toml for proc-macro = true)
Check if syn features are minimized (full syn with "full" feature vs selective features)
Confirm compile-time impact is meaningful (proc macros used across many files vs one-off)
"Wrong Fragment Type"
Before flagging, you MUST:
Verify the suggested fragment type actually works in that position
Check if :tt is intentionally used for flexibility (common in TT munching patterns)
Confirm :expr greediness issues actually manifest (test with the macro's actual call sites)
FFI-Specific Verification
"Missing repr(C)"
Before flagging, you MUST:
Confirm the type actually crosses the FFI boundary (passed to/from C code)
Check if the type is only used on the Rust side of the FFI wrapper
Verify there isn't a #[repr(transparent)] wrapper instead
Common false positives:
Internal Rust types that are converted before FFI call — only the FFI-facing type needs repr(C)
Types used with repr(transparent) newtype wrappers — the wrapper handles layout
Opaque pointer types (*mut c_void) — no layout guarantee needed
"FFI Safety"
Before flagging, you MUST:
Check if the unsafe FFI call has a SAFETY comment documenting invariants
Verify ownership transfer is actually ambiguous (check for Box::into_raw/Box::from_raw pairs)
Confirm CString lifetime issues are real (the CString must outlive the pointer passed to C)
Check if callback unwinding is actually possible (pure data functions can't panic across FFI)
Common false positives:
extern "C" fn callbacks that never panic — catch_unwind not needed
*const c_char from CStr::as_ptr() held within the same scope — lifetime is fine
Bindgen-generated code with unsafe — bindgen output is inherently unsafe-heavy by design
Concurrency-Specific Verification
"Memory Ordering Too Weak"
Before flagging, you MUST:
Verify the atomic is actually shared between threads that need synchronization
Check if Relaxed is sufficient (counters, flags with no dependent data)
Confirm Acquire/Release vs SeqCst choice matters (most code doesn't need SeqCst)
Common false positives:
Relaxed on simple counters/metrics — no ordering needed for independent values
Relaxed on boolean flags polled in a loop — the loop provides eventual visibility
SeqCst used "for safety" — not wrong, just potentially over-synchronized
Before Submitting Review
Submission gate — Pass: Every finding uses [FILE:LINE] ISSUE_TITLE and includes the exact line (or minimal contiguous lines) that demonstrates the issue, so a reader can jump to the proof without trusting memory.
Final verification:
Re-read each finding and ask: "Did I verify this is actually an issue?"
For each finding, can you point to the specific line that proves the issue exists?
Would a Rust domain expert agree this is a problem, or is it a style preference?
Does fixing this provide real value, or is it busywork?
Format every finding as: [FILE:LINE] ISSUE_TITLE
For each finding, ask: "Does this fix existing code, or does it request entirely new code that didn't exist before?" If the latter, downgrade to Informational.
If this is a re-review: ONLY verify previous fixes. Do not introduce new findings.