fp-check

Restate the exact claim, trace data flow from source to sink, prove attacker control and mathematical bounds, then run a devil's advocate review. The Skill issues a FALSE POSITIVE verdict if any of six gate reviews fail, with the failing gate documented.

Prove the attacker controls data reaching the vulnerable operation, confirm the vulnerable condition is mathematically possible given validation, and create a pseudocode or executable PoC showing the attack path. Real impact must be RCE, privilege escalation, or information disclosure.

Use deep verification for ambiguous claims, cross-component bug paths spanning 3+ modules, race conditions or concurrency in the trigger, logic bugs without a clear spec, or when standard verification is inconclusive. Standard verification handles single-component, well-understood bug classes.

Memory corruption in safe Rust, Go without unsafe.Pointer or cgo, or managed languages is almost always a false positive because the type system or runtime prevents it. Verify whether the code uses unsafe blocks, cgo, or native calls before accepting the claim.

Code that looks dangerous may be safe due to upstream validation, API contracts with built-in bounds checks, or conditional logic making the vulnerable path unreachable. Each finding requires full data flow tracing and mathematical proof rather than pattern matching.