Borrowing it
Nothing to install: this file belongs to automators-com/flowproof. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/automators-com/flowproof/main/.agents/skills/flowproof-docs/SKILL.mdgit clone --depth 1 https://github.com/automators-com/flowproofWrote 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/automators-com/flowproof/flowproof-docs)<a href="https://agentmods.dev/skills/automators-com/flowproof/flowproof-docs"><img src="https://agentmods.dev/badge/skills/automators-com/flowproof/flowproof-docs/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/automators-com/flowproof/flowproof-docs"><img src="https://agentmods.dev/badge/skills/automators-com/flowproof/flowproof-docs.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.00050 | $0.00896 |
| Opus 5.5 | $0.00020 | $0.00358 |
| Sonnet 5.5 | $0.00010 | $0.00179 |
| Haiku 4.5 | $0.00005 | $0.00090 |
Grade A, and why
flowproof-docs 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 — 97 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Flowproof documentation
Help one primary reader complete one task or understand one system. Preserve Flowproof's technical precision while making the shortest correct path easy to find.
Before editing
- Name the primary reader and their goal.
- Choose one dominant content type for each page:
- tutorial: learn by completing a guided sequence;
- how-to: complete a specific task;
- reference: look up exact contracts, values, and constraints;
- explanation: understand concepts, architecture, or tradeoffs.
- Read the relevant code, schemas, tests, examples, and current docs. Do not infer product behavior from prose alone.
- Run
python3 .agents/skills/flowproof-docs/scripts/audit_docs.pyto find broken local links and density hotspots. Treat density findings as prompts for judgment, not automatic failures.
Structure
- Start tutorials and how-to guides with the outcome, prerequisites, shortest working path, and a recognizable success result.
- Put the common path before advanced options. Link to reference pages instead of embedding complete contracts in a tutorial.
- Keep reference prose minimal. Prefer tables for fields, flags, defaults, accepted values, side effects, and platform differences.
- Split a page when audiences or content types conflict. Do not fragment one coherent task across shallow pages.
- Use descriptive headings that remain meaningful when retrieved alone.
- Define product terms, trust boundaries, prerequisites, and expected outputs before relying on them.
- Use the same name for the same concept throughout the docs.
Flowproof-specific rules
- Keep
README.mdconcise and orienting. Makedocs/the canonical home for detailed behavior, and link to it rather than duplicating it. - Preserve the distinction between containment, observed behavior, regression evidence, and deterministic replay. Never strengthen a security claim while shortening it.
- Preserve exact commands, structured field names, exit codes, platform limitations, and destructive side-effect warnings.
- Keep examples copyable and realistic. Never add secrets or unverifiable production values.
- Update the nearest
meta.jsonwhen adding, removing, or renaming a page. - Prefer relative links that resolve in both the repository and the docs site.
What ships with it
2 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 · 97 lines · 50 tokens per session scan A a4a2cf801af8
flowproof-docs is a skill published in the GitHub repository automators-com/flowproof (5 stars, last pushed yesterday), licensed Apache-2.0. It adds 50 tokens to every session and 896 once invoked, about $0.0002 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-09-19.
Other skills, from other repositories
shaft-developer
Use when starting any SHAFT testing task to select exactly one lifecycle, implementation, or tool specialist before doing the work.
shaft-test-case-design
Use when designing reviewable test cases or scenarios with traceability, data, steps, expected results, techniques, priorities, and boundary coverage.
shaft-accessibility-testing
Use when testing web or mobile accessibility for WCAG conformance, keyboard and focus behavior, semantics, errors, or user impact.
shaft-api-testing
Use when implementing or repairing SHAFT.API tests for HTTP requests, authentication, payloads, schemas, responses, contracts, or service workflows.
shaft-automated-test-authoring
Use when implementing or repairing executable SHAFT Java tests for web, mobile, API, database, CLI, TestNG, JUnit, or Cucumber behavior.
shaft-change-verification
Use when edited SHAFT Java needs a reuse plan, preview diff, guardrail check, approved application, focused test, and evidence-backed verdict.