fp-check
- Repo stars 5,723
- Forks 499
- Author updated Jun 15, 2026, 04:05 PM
- Author repo skills
- Domain
- Other
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @trailofbits · no license declared
- Token usage
- Lean
- Setup complexity
- Guided setup
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Shell exec
- Network behavior
- External requests
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools，默认拥有全部工具权限。
---
name: fp-check
description: Systematically verifies suspected security bugs to eliminate false positives. Produces TRUE POSI…
category: other
runtime: no special runtime
---
# fp-check output preview
## PART A: Task fit
- Use case: Systematically verifies suspected security bugs to eliminate false positives. Produces TRUE POSITIVE or FALSE POSITIVE verdicts with documented evidence for each bug..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “When to Use / When NOT to Use / Rationalizations to Reject” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “Systematically verifies suspected security bugs to eliminate false positives. Produces TRUE POSITIVE or FALSE POSITIVE verdicts with documented evidence for each bug.”.
- **02** When the source has headings, the agent prioritizes “When to Use / When NOT to Use / Rationalizations to Reject” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files, run shell commands; may access external network resources; usually needs no extra API key.
## Running Rules
- read files, write/modify files, run shell commands; may access external network resources; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. Choose the trigger
The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
Provide inputs and boundaries
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files, run shell commands.
Validate with a small run
Start with a small task and check whether the result follows “When to Use / When NOT to Use / Rationalizations to Reject”. Inspect diffs, logs, previews, or tests before expanding scope.
Review before delivery
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: fp-check
description: Systematically verifies suspected security bugs to eliminate false positives. Produces TRUE POSI…
category: other
source: trailofbits/skills
---
# fp-check
## When to use
- Systematically verifies suspected security bugs to eliminate false positives. Produces TRUE POSITIVE or FALSE POSITIVE…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “When to Use / When NOT to Use / Rationalizations to Reject” and keep inference separate from source facts.
- read files, write/modify files, run shell commands; may access external network resources; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. Evidence boundary and execution chain
The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "fp-check" {
input -> user goal + target files + boundaries + acceptance criteria
context -> When to Use / When NOT to Use / Rationalizations to Reject
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files, run shell commands | may access external network resources
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
}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 overrating severity | Complete devil's advocate review; prove it with evidence |
Step 0: Understand the Claim and Context
Before any analysis, restate the bug in your own words. If you cannot do this clearly, ask the user for clarification using AskUserQuestion. Half of false positives collapse at this step — the claim doesn't make coherent sense when restated precisely.
Document:
- What is the exact vulnerability claim? (e.g., "heap buffer overflow in
parse_header()whencontent_lengthexceeds 4096") - What is the alleged root cause? (e.g., "missing bounds check before
memcpyat line 142") - What is the supposed trigger? (e.g., "attacker sends HTTP request with oversized Content-Length header")
- What is the claimed impact? (e.g., "remote code execution via controlled heap corruption")
- What is the threat model? What privilege level does this code run at? Is it sandboxed? What can the attacker already do before triggering this bug? (e.g., "unauthenticated remote attacker vs privileged local user"; "runs inside Chrome renderer sandbox" vs "runs as root with no sandbox")
- What is the bug class? Classify the bug and consult bug-class-verification.md for class-specific verification requirements that supplement the generic phases below.
- Execution context: When and how is this code path reached during normal execution?
- Caller analysis: What functions call this code and what input constraints do they impose?
- Architectural context: Is this part of a larger security system with multiple protection layers?
- Historical context: Any recent changes, known issues, or previous security reviews of this code area?
Route: Standard vs Deep Verification
After Step 0, choose a verification path.
Standard Verification
Use when ALL of these hold:
- Clear, specific vulnerability claim (not vague or ambiguous)
- Single component — no cross-component interaction in the bug path
- Well-understood bug class (buffer overflow, SQL injection, XSS, integer overflow, etc.)
- No concurrency or async involved in the trigger
- Straightforward data flow from source to sink
Follow standard-verification.md. No task creation — work through the linear checklist, documenting findings inline.
Deep Verification
Use when ANY of these hold:
- Ambiguous claim that could be interpreted multiple ways
- Cross-component bug path (data flows through 3+ modules or services)
- Race conditions, TOCTOU, or concurrency in the trigger mechanism
- Logic bugs without a clear spec to verify against
- Standard verification was inconclusive or escalated
- User explicitly requests full verification
Follow deep-verification.md. Create the full task dependency graph and execute phases with the plugin's agents.
Default
Start with standard. Standard verification has two built-in escalation checkpoints that route to deep when complexity exceeds the linear checklist.
Batch Triage
When verifying multiple bugs at once:
- Run Step 0 for all bugs first — restating each claim often collapses obvious false positives immediately
- Route each bug independently (some may be standard, others deep)
- Process all standard-routed bugs first, then deep-routed bugs
- After all bugs are verified, check for exploit chains — findings that individually failed gate review may combine to form a viable attack
Final Summary
After processing ALL suspected bugs, provide:
- Counts: X TRUE POSITIVES, Y FALSE POSITIVES
- TRUE POSITIVE list: Each with brief vulnerability description
- FALSE POSITIVE list: Each with brief reason for rejection
References
- Standard Verification — Linear single-pass checklist for straightforward bugs
- Deep Verification — Full task-based orchestration for complex bugs
- Gate Reviews — Six mandatory gates and verdict format
- Bug-Class Verification — Class-specific verification requirements for memory corruption, logic bugs, race conditions, integer issues, crypto, injection, info disclosure, DoS, and deserialization
- False Positive Patterns — 13-item checklist and red flags for common false positive patterns
- Evidence Templates — Documentation templates for data flow, mathematical proofs, attacker control, and devil's advocate reviews
Decide Fit First
Design Intent
How To Use It
Boundaries And Review