fp-check

# False Positive Check ## When to Use - "Is this bug real?" or "is this a true positive?" - "Is this a false positive?" or "verify this finding" - "Check if this vulnerability is exploitable" - Any request to verify or validate a specific suspected bug ## When NOT to Use - Finding or hunting for bugs ("find bugs", "security analysis", "audit code") - General code review for style, performance, or maintainability - Feature development, refactoring, or non-security tasks - When the user explicitly asks for a quick scan without verification ## Rationalizations to Reject If you catch yourself thinking any of these, STOP. | Rationalization | Why It's Wrong | Required Action | |---|---|---| | "Rapid analysis of remaining bugs" | Every bug gets full verification | Return to task list, verify next bug through all phases | | "This pattern looks dangerous, so it's a vulnerability" | Pattern recognition is not analysis | Complete data flow tracing before any conclusion | | "Skipping full verification for efficiency" | No partial analysis allowed | Execute all steps per the chosen verification path | | "The code looks unsafe, reporting without tracing data flow" | Unsafe-looking code may have upstream validation | Trace the complete path from source to sink | | "Similar code was vulnerable elsewhere" | Each context has different validation, callers, and protections | Verify this specific instance independently | | "This is clearly critical" | LLMs are biased toward seeing bugs and...