Getting it into your agent
This one installs as part of its plugin. Adding the marketplace and installing the plugin brings it with everything else the plugin ships.
/plugin marketplace add navapbc/digital-service-orchestra/plugin install dsoWrote 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/navapbc/digital-service-orchestra/fp-recovery)<a href="https://agentmods.dev/skills/navapbc/digital-service-orchestra/fp-recovery"><img src="https://agentmods.dev/badge/skills/navapbc/digital-service-orchestra/fp-recovery/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/navapbc/digital-service-orchestra/fp-recovery"><img src="https://agentmods.dev/badge/skills/navapbc/digital-service-orchestra/fp-recovery.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.00118 | $0.01495 |
| Opus 5 | $0.00059 | $0.00747 |
| Sonnet 5 | $0.00024 | $0.00299 |
| Haiku 4.5 | $0.00012 | $0.00150 |
Grade A, and why
fp-recovery 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.
How it starts
The opening of the file, as written. The whole thing — 69 lines — stays where its author put it; the contents beside it link to each section on GitHub.
FP Recovery — Manual Review Escalation
Shallow entry point for the FP-recovery workflow. Loads and executes ${CLAUDE_PLUGIN_ROOT}/docs/workflows/FP-RECOVERY-WORKFLOW.md inline.
When to invoke
CI llm-review (ci.yml) has reported failure AND the engineer believes the blocking finding is a false positive. All other required checks must pass (or be filed as known intermittent bugs). See FP-RECOVERY-WORKFLOW.md "When to invoke" for the full precondition list.
Eligible finding types — FP-recovery may be invoked for findings of any of these types when the engineer believes the finding is a false positive:
- Code-level findings (logic, security, correctness, style)
- DESIGN.md lint findings — violations flagged by the
check-design-lint.shhook or equivalent design-doc linter (e.g., missing required sections, disallowed heading format, broken cross-references to ticket IDs). These are eligible when the engineer can demonstrate the design document is structurally correct and the linter rule is misapplied for the specific context.
Common false-positive patterns for DESIGN.md lint findings:
- The linter flags a missing required section that is intentionally omitted because it is not applicable to the change type (e.g., no "Data Model" section for a UI-only change).
- A ticket ID cross-reference is flagged as broken, but the ticket exists and the ID format is correct (linter regex mismatch).
- The linter rejects a heading because of an extra trailing space or Unicode em-dash that is visually indistinguishable from a standard ASCII hyphen.
- A newly added DESIGN.md section is flagged as unknown because the linter's allowed-section list has not been updated.
Finding format for DESIGN.md lint findings — when invoking FP-recovery for a DESIGN.md lint finding, the engineer must supply:
- The exact linter rule name or error message (copy from CI log).
- The specific line(s) in
DESIGN.mdthat triggered the finding. - A concise rationale explaining why the finding is a false positive (not just "it looks fine").
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 · 69 lines · 118 tokens per session scan A 245e6c56bc6e
fp-recovery is a skill published in the GitHub repository navapbc/digital-service-orchestra (6 stars, last pushed yesterday), licensed Apache-2.0. It adds 118 tokens to every session and 1,495 once invoked, about $0.0006 per session on Opus 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-09-03.
Other skills, from other repositories
adversarial-reviewer
Adversarial code review that assumes bugs exist and hunts for them. Use when asked to review code, find bugs, audit for correctness, stress-test a PR, or when someone says "tear this apart" or "what's wrong with this". Give no benefit of the doubt — every line is guilty until proven innocent.
gsd-ns-review
Route to the appropriate quality / review skill based on the user's intent. gsd-code-review-fix was absorbed by gsd-code-review --fix in #2790.
issue
Use when starting a chain from a GitHub issue — turning an issue URL or number into a triaged, planned, dispatched, and reviewed pull request. Classifies the thread (bug → root-cause discipline, feature → plan chain, question → drafted reply), synthesizes a spec from the issue's own acceptance criteria, then runs the…
gitnexus
A code-graph analysis add-on for examining an existing codebase, including symbols, call paths, execution flows, and effects across repositories. It can query GitNexus through its command-line or MCP interfaces.
cleanup-code-inspections
Reduce technical debt and improve code quality by systematically resolving static analysis warnings.
sonarqube-mcp
Provides SonarQube and SonarCloud integration patterns via the Model Context Protocol (MCP) server. Enables quality gate monitoring, issue discovery and triaging, pre-push code analysis, and rule education directly in the agent workflow. Use when the user wants to check quality gates, search for Sonar issues, analyze…