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-apigit 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-api)<a href="https://agentmods.dev/skills/tonone-ai/tonone/proof-api"><img src="https://agentmods.dev/badge/skills/tonone-ai/tonone/proof-api/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-api"><img src="https://agentmods.dev/badge/skills/tonone-ai/tonone/proof-api.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.00051 | $0.00847 |
| Opus 5.5 | $0.00020 | $0.00339 |
| Sonnet 5.5 | $0.00010 | $0.00169 |
| Haiku 4.5 | $0.00005 | $0.00085 |
Grade A, and why
proof-api 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 — 89 lines — stays where its author put it; the contents beside it link to each section on GitHub.
API Test Suite
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 API stack:
- Check for API framework: Express, FastAPI, Django, Go, Rails, Spring Boot
- Check for existing API tests: test files with HTTP requests, supertest, pytest with client fixtures
- Check for API spec:
openapi.yaml,swagger.json,.protofiles, GraphQL schema - Check for existing test tools: Supertest, Pactum, REST-assured, Hurl, httpx
- Check for CI test integration
If no API test tool is configured, recommend based on the stack (Supertest for Node, pytest+httpx for Python, etc.).
Step 1: Map API Surface
Build a complete endpoint inventory:
| Method | Path | Auth | Request Body | Response | Tested? |
|---|---|---|---|---|---|
| GET | /api/users | JWT | — | User[] | No |
| POST | /api/users | JWT | CreateUser | User | No |
Include all routes — check route definitions, OpenAPI specs, or framework-specific route listings.
Step 2: Write Integration Tests
For each endpoint, test:
- Happy path — valid request returns expected response
- Authentication — unauthenticated requests are rejected
- Authorization — users can't access other users' data
- Validation — invalid input returns proper error responses
- Edge cases — empty arrays, missing optional fields, boundary values
- Error responses — correct status codes and error format
Step 3: Add Contract Tests (if applicable)
If there are service-to-service calls or a public API:
- Set up Pact or Specmatic for consumer-driven contracts
- Generate contracts from OpenAPI spec if available
- Test that the API matches its published contract
- Integrate contract verification into CI
Step 4: Add Load Tests (if requested)
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 · 89 lines · 51 tokens per session scan A 795e993048f5
proof-api is a skill published in the GitHub repository tonone-ai/tonone (76 stars, last pushed 9d ago), licensed MIT. It adds 51 tokens to every session and 847 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
qa-api-testing-contracts
Tests API contracts for REST, GraphQL, gRPC, AsyncAPI, and webhooks. Use when adding schema validation or breaking-change gates (Pact, can-i-deploy, oasdiff, buf); not API design.
backend-manual-testing
Use when the task touches a backend API, database or worker - booting it from the task branch, driving real requests and verifying side effects (DB rows, outbound calls, logs) as evidence.
worker-job-testing
Use when the task has a background job, queue consumer, scheduler or webhook - firing the real trigger, polling for the side effect, and the retry, idempotency and poison-message cases.
add-handler
Scaffold a new HTTP handler with service function, store method (if needed), and table-driven test, following the project's internal/{api,service,store} layout. Invoke when the user asks to add an endpoint, handler, or route.
add-endpoint
Scaffold a new HTTP endpoint across the project's handler, service, and repository layers with tests, following the existing layering. Invoke when the user asks to add a route, endpoint, or API method to a Rust service.
api-contract-testing
Use when a task adds or changes an HTTP endpoint, its request/response shape, status codes, auth or error format - the request matrix, curl templates and what counts as a contract break.