avoiding-false-positives
Prevents false positive findings by recognizing framework patterns, codebase conventions, and common non-issues. Use when uncertain whether something is a real issue.
When & Why to Use This Skill
The 'Avoiding False Positives' Claude skill is a specialized quality-assurance tool designed to refine automated code reviews. It prevents the reporting of non-issues by requiring a rigorous verification process based on framework semantics, execution path tracing, and established codebase conventions. By prioritizing accuracy over volume, this skill ensures that developers receive only high-signal, actionable feedback, significantly reducing review noise and increasing trust in AI-driven development workflows.
Use Cases
- Case 1: Validating potential bugs by tracing execution paths to ensure a suspected issue can actually manifest as incorrect behavior in production.
- Case 2: Respecting legacy codebase conventions where consistency with existing patterns (e.g., specific error handling styles or type usage) is more valuable than suggesting 'standard' improvements.
- Case 3: Filtering out irrelevant warnings in generated code, migrations, or test suites where different coding standards and intentional simplicity are expected.
- Case 4: Verifying framework-specific behaviors, such as ensuring a 'missing' validation isn't already handled by middleware, decorators, or built-in framework sanitization.
- Case 5: Assessing performance and security concerns within context, such as ignoring race conditions in idempotent operations or performance issues in low-frequency startup scripts.
| name | avoiding-false-positives |
|---|---|
| description | Use this skill when validating ANY potential code review finding. Apply BEFORE classifying to verify the finding is real; can you trace incorrect behavior, is it handled elsewhere, and are you certain about framework semantics? If any answer is no, DO NOT create the finding. |
Avoiding False Positives
Before Flagging Anything
MUST verify ALL three:
- Can you trace the execution path showing incorrect behavior?
- Is this handled elsewhere (error boundaries, middleware, validators)?
- Are you certain about framework behavior, API contracts, and language semantics?
If you cannot confidently answer all three, DO NOT create the finding.
Patterns to Recognize (DO NOT flag)
- Intentional simplicity - Not every function needs error handling if caller handles it
- Framework conventions - React hooks, dependency injection, ORM patterns have specific rules
- Test code - Different standards apply (hardcoded values, no error handling often OK)
- Generated code - Migrations, API clients, proto files (only review if hand-edited)
- Copied patterns - If code matches existing patterns in codebase, consistency > "better" approach
When uncertain about a pattern, search the codebase for similar examples before flagging.
Codebase Conventions
Before suggesting changes:
- Check existing patterns - How does this codebase handle similar cases?
- Respect established conventions - Even if non-standard, consistency > perfection
- Don't flag convention violations unless they cause bugs or security issues
Examples:
- Codebase uses
anytypes extensively → Don't flag individual uses - Codebase has no error handling in services → Don't flag one missing try-catch
- Consistency matters more than isolated improvements
Common False Positives to Avoid
Do NOT flag when handled elsewhere or guaranteed by framework:
- Null checks: Language/framework ensures non-null, or prior validation occurred
- Error handling: Error boundaries exist, function designed to throw, or caller handles
- Race conditions: Framework synchronizes (React state, DB transactions), or operations idempotent
- Performance: Data bounded (<100 items), runs once at startup, no profiling evidence
- Security: Framework sanitizes (parameterized queries, JSX escaping), or API layer validates
When uncertain, assume the developer knows something you don't.