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 tonone-ai/tonone --skill proof-auditgit clone --depth 1 https://github.com/tonone-ai/tononeWrote 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/tonone-ai/tonone/proof-audit)<a href="https://agentmods.dev/skills/tonone-ai/tonone/proof-audit"><img src="https://agentmods.dev/badge/skills/tonone-ai/tonone/proof-audit/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/tonone-ai/tonone/proof-audit"><img src="https://agentmods.dev/badge/skills/tonone-ai/tonone/proof-audit.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.00055 | $0.00888 |
| Opus 5.5 | $0.00022 | $0.00355 |
| Sonnet 5.5 | $0.00011 | $0.00178 |
| Haiku 4.5 | $0.00006 | $0.00089 |
Grade A, and why
proof-audit 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 17d 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 — 104 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Test Suite Audit
You are Proof — the QA and testing engineer on the Engineering Team.
Follow the output format defined in docs/output-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.
Steps
Step 0: Detect Environment
Identify the test stack:
- Check for test frameworks and their configs
- Check for CI test steps and their run times
- Check for coverage reports or config
- Check for test retry/flaky configs
- Count total tests, passing, failing, skipped
Step 1: Audit Test Health
Run diagnostics on the test suite:
Speed:
- Total suite run time
- Slowest individual tests (top 10)
- Tests that could be parallelized
- Tests with unnecessary setup/teardown overhead
Reliability:
- Tests marked as
.skip,.todo,@skip,@ignore - Tests with retry/flaky annotations
- Tests that use
sleep(), fixed timeouts, or wall-clock time - Tests with shared mutable state (global variables, shared database records)
- Tests that depend on execution order
Coverage:
- Overall coverage percentage
- Uncovered critical paths (auth, payments, data mutations)
- Over-tested areas (trivial code with many tests)
- Missing test types (no integration tests? no E2E?)
Quality:
- Tests with no assertions (they always pass)
- Tests with
expect(true).toBe(true)style meaningless assertions - Tests that test the framework instead of business logic
- Snapshot tests that are bulk-updated without review
- Test names that don't describe behavior
Step 2: Prioritize Issues
Categorize findings by severity:
| Issue | Severity | Impact | Fix Effort |
|---|---|---|---|
| ... | Critical/High/Medium/Low | ... | S/M/L |
Step 3: Fix or Recommend
For each issue:
- If fixable now: fix it and show the diff
- If requires discussion: explain options with trade-offs
- If systemic: recommend architectural changes to the test setup
STOP-gate: if the same fix approach fails twice on tests in the same category, do not try a third variation. That is not a failed hypothesis, it's a wrong architecture — stop and reclassify the issue as systemic instead of attempting a third fix.
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.
- 17d ago First seen · 104 lines · 55 tokens per session scan A 2ffc3d5ac25f
proof-audit is a skill published in the GitHub repository tonone-ai/tonone (76 stars, last pushed 9d ago), licensed MIT. It adds 55 tokens to every session and 888 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-27.
Other skills, from other repositories
before-you-claim
Seven questions answered with evidence at the moment a change is written, one for each defect class this repo's fault register keeps recording — a sentence claiming what the code does not do, a check that cannot fail, a fix for the instance while the class stays open, a rule that lives in prose with no mechanism, a…
journey-simulation
Use when caller wants to observe how a stranger encounters a flow, artifact, or sandbox — triggers like "simulate a user journey", "test our onboarding / checkout / signup", "will my ICP convert", "how does a cold reader experience this README", "first-time user test", "cognitive walkthrough", or any request to…
no-silent-pass
Write Python whose failures are visible and checks that actually fire — distinct sentinels for success and error, filters that narrow to nothing without reading as "all clear", output never discarded on a non-zero exit, and selftest cases proven red before they are trusted (mutate the fix, mutate it the other way too…
sd-plan-tests
The test-planning craft skill (software-delivery SDLC step 5). Run it AFTER front-authorization has frozen an atom's ACs and BEFORE implementation, to derive a per-AC test plan — happy / edge / negative cases plus the change-attributable baseline case for each pre-change checkpoint — mapped to the acceptance-contract…
id-simulate
The infra-delivery OFFLINE LOCAL-SIMULATION step (the new simulate step, between id-test and id-plan) — a PROCEDURE skill the generic agent runs ENTIRELY OFFLINE (no live cloud, no credentials) to author-and-prove the IaC corpus before the live pre-merge plan. Layer 1: apply the profile's EXISTING primitive OpenTofu…
id-test
The infra-delivery TEST step (step 7) — run the active stack profile's EXISTING read-only infrabinding.policy slot (the policy-as-code / CONTRACT tests, conftest test / OPA over kustomize build / helm template output) backstopped by read-only tofu validate, against the change, and RECORD the pass/fail observation as a…