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 avmnu-sng/sutra --skill test-authoringgit clone --depth 1 https://github.com/avmnu-sng/sutraWrote 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/avmnu-sng/sutra/test-authoring)<a href="https://agentmods.dev/skills/avmnu-sng/sutra/test-authoring"><img src="https://agentmods.dev/badge/skills/avmnu-sng/sutra/test-authoring/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/avmnu-sng/sutra/test-authoring"><img src="https://agentmods.dev/badge/skills/avmnu-sng/sutra/test-authoring.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.00031 | $0.02067 |
| Opus 5 | $0.00015 | $0.01033 |
| Sonnet 5 | $0.00006 | $0.00413 |
| Haiku 4.5 | $0.00003 | $0.00207 |
Grade A, and why
test-authoring 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 — 210 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Test authoring
Write tests that catch regressions, not tests that report false safety. A test earns its place only if a real defect would make it fail. Follow the steps below in order; skipping step 1 is the number-one cause of integration-test churn.
1. Read the source of truth before asserting anything
Never guess the name, type, or shape of a value you assert on. Open the artifact that actually produces it and read it:
- The schema or type definition for a structured payload.
- The handler, controller, or function that builds the response.
- The serializer or formatter that renders the wire/output form.
- The database write (column names, nullability, defaults) behind a persisted value.
Guessing field names and shapes is the dominant integration-test failure mode. Before writing assertions, build a short mapping and keep it next to the test:
output surface -> source artifact
------------------------------------------------------------
response.user.display_name -> serializers/user.* (field: display_name)
row.status -> schema migration (enum: pending|done)
event.emitted_at -> handler build step (unix millis, not ISO)
If you cannot find the source artifact, stop and find it. Do not assert against a value you have only inferred from a variable name.
2. Enumerate the case list before writing tests
For a substantial new suite, enumerate the cases (input -> expected) from the source of truth and confirm them before writing bodies -- especially where a wrong expectation is expensive. For routine additions, enumerate but don't block. Enumerate every case as an explicit input -> expected pair -- happy path, boundaries, and known failure modes -- derived from the source of truth (step 1), not from whatever the code currently emits.
- One row per case: input/precondition -> expected outcome.
- Include the cases you deliberately leave out, and why, so a reviewer can catch a missing branch before any code exists.
- If review changes a case, update the list first; do not silently drift the expected values to match the implementation.
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 · 210 lines · 31 tokens per session scan A cebb3056516f
test-authoring is a skill published in the GitHub repository avmnu-sng/sutra (2 stars, last pushed 1mo ago), licensed MIT. It adds 31 tokens to every session and 2,067 once invoked, about $0.0002 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-08-31.
Other skills, from other repositories
memstack-development-test-writer
Use this skill when the user says 'write tests', 'add tests', 'test coverage', 'unit tests', 'integration tests', 'component tests', 'mocking', 'edge cases', or needs to generate tests with proper mocking and edge case coverage. Do NOT use for refactoring plans or database migrations.
verify
Runs this project's check chain through scripts/verify.py and reads the receipt it writes. Fires when tracked changes are finished, when the user asks whether work passes, before a commit, and before reporting a task done. Stays dormant in repositories with no detectable check chain, during read-only audits, and for…
memstack-development-webapp-testing
Use when the user says 'write browser tests', 'test this page', 'playwright test', 'e2e test', 'end to end test', 'browser test', 'test the UI', or needs Playwright-based browser testing for a web application. Do NOT use for unit tests, API tests, or non-browser testing.
plan-pipeline-execute
Execute a validated plan: worktree isolation, TDD scaffolding, level-based parallel agents, quality gate with smoke test, PR creation and merge. Handles everything through to merged PR.
qa
Systematic QA testing of a web application: diff-aware, tiered, with fix-and-verify loop.
plan-pipeline-eng-review
Engineering architecture gate: lock architecture, diagrams, edge cases, and test matrix before writing implementation code.