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 waybarrios/opencode-power-pack --skill fp-checkgit clone --depth 1 https://github.com/waybarrios/opencode-power-packWrote 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/waybarrios/opencode-power-pack/fp-check)<a href="https://agentmods.dev/skills/waybarrios/opencode-power-pack/fp-check"><img src="https://agentmods.dev/badge/skills/waybarrios/opencode-power-pack/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/waybarrios/opencode-power-pack/fp-check"><img src="https://agentmods.dev/badge/skills/waybarrios/opencode-power-pack/fp-check.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to medium
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- medium Excessive Agency · line 21 Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.Fix: Add human-in-the-loop confirmation for destructive, irreversible, or high-impact operations. Never auto-execute commands that modify files, send data, or alter system state.
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.01327 |
| Opus 5.5 | $0.00013 | $0.00531 |
| Sonnet 5.5 | $0.00006 | $0.00265 |
| Haiku 4.5 | $0.00003 | $0.00133 |
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 1mo 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.
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. 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.
- 1mo ago First seen · 113 lines · 32 tokens per session scan A cba183cdc71c
fp-check is a skill published in the GitHub repository waybarrios/opencode-power-pack (544 stars, last pushed 5d ago), licensed MIT. It adds 32 tokens to every session and 1,327 once invoked, about $0.0001 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
vercel-agent
Vercel Agent guidance — AI-powered code review, incident investigation, and SDK installation. Automates PR analysis and anomaly debugging. Use when configuring or understanding Vercel's AI development tools.
oracle
Oracle second-model review: bundle prompts/files, debug, refactor, design.
code-review-web
Review web application code for bugs, security issues, performance problems, and stack-specific anti-patterns. Use this skill whenever the user wants to review code, debug a production issue, investigate a build failure, audit security, or check a PR before merging. Triggers on code review, review my code, debug…
ln-44-performance-optimizer
Profiles and improves a measured performance bottleneck; retains only verified improvements.
ln-71-operations-investigator
Diagnoses incidents from operational evidence and proposes recovery; does not change live systems.
ln-96-error-handling-engineer
Implements safe error boundaries, cancellation and user recovery contracts; not telemetry pipelines or durable retry machinery.