Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add msradam/theodosia --skill fp-checkgit clone --depth 1 https://github.com/msradam/theodosiaWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/msradam/theodosia/fp-check)<a href="https://agentmods.dev/skills/msradam/theodosia/fp-check"><img src="https://agentmods.dev/badge/skills/msradam/theodosia/fp-check/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/msradam/theodosia/fp-check"><img src="https://agentmods.dev/badge/skills/msradam/theodosia/fp-check.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00032 | $0.01369 |
| Opus 5 | $0.00016 | $0.00685 |
| Sonnet 5 | $0.00006 | $0.00274 |
| Haiku 4.5 | $0.00003 | $0.00137 |
Grade A, and why
fp-check scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 9d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
This is a copy
86% identical to fp-check — 24 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 113 lines — stays where its author put it; the contents beside it link to each section on GitHub.
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?
What ships with it
6 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 9d ago First seen · 113 lines · 32 tokens per session scan A bff31dcbb044
fp-check is a skill published in the GitHub repository msradam/theodosia (15 stars, last pushed yesterday), licensed Apache-2.0. It adds 32 tokens to every session and 1,369 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. It is 86% identical to fp-check, differing in 24 lines, and is treated as a copy.
Other skills, from other repositories
dos-self-improve
Run the DOS self-improvement loop: propose a candidate, verify it in an isolated worktree, measure suite/truth/metric gates, and keep only confirmed gains. Use for recursive improvement; use dos-enforce-tune for policy knobs.
dos-unstick
Analyze BLOCKED/DRAIN run history, cluster recurring causes, and propose one structural fix per wedge via dos decisions. Use when a fleet keeps stalling and you want a systemic unblock rather than another manual nudge.
dag-execution-tracer
Traces complete execution paths through DAG workflows. Records timing, inputs, outputs, and state transitions for all nodes. Activate on 'execution trace', 'trace execution', 'execution path', 'debug execution', 'execution log'. NOT for performance analysis (use dag-performance-profiler) or failure investigation (use…
dag-failure-analyzer
Performs root cause analysis on DAG execution failures. Traces failure propagation, identifies systemic issues, and generates actionable remediation guidance. Activate on 'failure analysis', 'root cause', 'why did it fail', 'debug failure', 'error investigation'. NOT for execution tracing (use dag-execution-tracer) or…
agenttrace-session-audit
Audit local AI coding-agent sessions with agenttrace for cost, tool failures, latency, anomalies, health, diffs, and CI gates.
langsmith-observability
LLM observability platform for tracing, evaluation, and monitoring. Use when debugging LLM applications, evaluating model outputs against datasets, monitoring production systems, or building systematic testing pipelines for AI applications.