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 sergeyklay/.agents --skill prove-checksgit clone --depth 1 https://github.com/sergeyklay/.agentsWrote 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/sergeyklay/.agents/prove-checks)<a href="https://agentmods.dev/skills/sergeyklay/.agents/prove-checks"><img src="https://agentmods.dev/badge/skills/sergeyklay/.agents/prove-checks/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/sergeyklay/.agents/prove-checks"><img src="https://agentmods.dev/badge/skills/sergeyklay/.agents/prove-checks.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.00221 | $0.03560 |
| Opus 5.5 | $0.00088 | $0.01424 |
| Sonnet 5.5 | $0.00044 | $0.00712 |
| Haiku 4.5 | $0.00022 | $0.00356 |
Grade A, and why
prove-checks 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 — 122 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Prove the Check Can Fail
A green result is evidence only if red was reachable. Every check runs in a state, and when that state is wrong the check does not error — it passes, cheaply and convincingly. The failure is silent by construction: nothing in the output distinguishes "the system works" from "the system was never asked".
Five ways a check goes green without testing anything:
| Shape | What happened | What green meant |
|---|---|---|
| Setup no-op | The mutation the check depends on never applied | The check compared the old state to itself |
| Subject not exercised | Only the downstream half ran, or it ran its no-op branch | The upstream half is still unverified |
| Failure suppressed | The failure path was routed to a warning or a forced exit 0 | Exit status carries no information |
| Nothing executed | The gate was set and the run exercised none of the subject anyway | Zero checks ran, and exit 0 says what a full pass says |
| Subject substituted | The named target was unreachable and the tool silently chose another one | The work was done correctly, on the wrong thing |
Trigger
Run this before recording any green as proof, and always when one of these is true:
- The check depends on a setup mutation: an in-place text edit, an env var, a secret, a generated fixture, a checked-out revision, a temporary config override.
- The job or step is wrapped in
continue-on-error,|| true,set +e,if: always(), or emits::warning::/echoinstead of a non-zero exit. - An event-driven pipeline was hand-run: a
workflow_dispatchon something whose real trigger is arepository_dispatch, a webhook, a tag push, or a release. - The run is a rehearsal of a future input ("simulate the next release", "pretend the version bumped", "assume the API returns X").
- The check passed on the first attempt after a change that should have been hard.
Not this skill: a search returning zero hits, or a claim that something is absent — those are research-it (silent-zero results, format-assumption false negatives, summariser-bounded negatives), including when the absent thing is a third-party capability.
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 Changed d0dfe69faa31
- 1mo ago Changed fefa45aeb467
- 1mo ago Changed · -8 lines 1360b219436c
- 1mo ago Changed · +5 lines bbe6bcda6aa7
- 1mo ago Changed · +2 lines c25940759731
- 1mo ago Changed · +16 lines · +23 tokens per session 8dbe68c3cadb
- 1mo ago Changed · +3 lines 6802edf925f2
- 1mo ago First seen · 104 lines · 198 tokens per session scan A e0b731f90c8d
prove-checks is a skill published in the GitHub repository sergeyklay/.agents (6 stars, last pushed 4d ago), licensed Apache-2.0. It adds 221 tokens to every session and 3,560 once invoked, about $0.0009 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-03.
Other skills, from other repositories
verify
Verify Elixir/Phoenix changes — compile, format, and test in one loop. Use after implementation, before PRs, or after fixing bugs.
triage-issue
Invoked helper skill for deep bug diagnosis, usually delegated from /qa when a reported issue needs root-cause analysis and a TDD fix plan before implementation. Use when the cause is unclear, the bug is a regression, or the user explicitly wants diagnosis. Not for lightweight QA intake (use /qa) or already-clear…
pdlc-fix
An automated bug-fixing workflow that locates a reported bug, reproduces it with a test, applies a minimal fix, runs tests, and updates the relevant documentation.
bugfix
Lightweight bug-fixing loop — reproduce → root-cause → fix test-first → verify — deliberately separate from the heavyweight feature workflow so small fixes don't drag a spec-and-plan process behind them. Demands a deterministic reproduction before any code changes, a stated root-cause hypothesis confirmed with…
wiring
When building infrastructure components, ensure they're actually invoked in the execution path.
playwright-debugging
Diagnostic Playwright workflows for flaky or failing tests, including trace analysis, UI mode, and state isolation.