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 agentmods add skills/osouthgate/agent-plus/test-writernpx skills add osouthgate/agent-plus --skill test-writergit clone --depth 1 https://github.com/osouthgate/agent-plusWrote 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/osouthgate/agent-plus/test-writer)<a href="https://agentmods.dev/skills/osouthgate/agent-plus/test-writer"><img src="https://agentmods.dev/badge/skills/osouthgate/agent-plus/test-writer.svg" alt="Measured on agentmods" 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 | $0.00071 | $0.01568 |
| Opus 5 | $0.00036 | $0.00784 |
| Sonnet 5 | $0.00014 | $0.00314 |
| Haiku 4.5 | $0.00007 | $0.00157 |
Grade A, and why
test-writer 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 4d 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 — 96 lines — stays where its author put it; the contents beside it link to each section on GitHub.
test-writer
Writes tests that would fail if someone removed a branch or changed a real decision. Every test must answer: would this fail if the behavior broke? If not, don't write it.
Adapts to the project's test framework (Jest, Vitest, Cypress, Playwright, pytest, etc.) and conventions.
Test layers
| Layer | Use for | Avoid |
|---|---|---|
| Unit | Server/utils logic; branching; side effects; transactions; corner cases | Single call-and-return with no decisions |
| Component | Single component or small tree; form validation with mocked API; rendering; error/loading states. Cover validation and error messages here, not in E2E | Full router/loader behavior; real API/DB |
| E2E | Full user journeys; redirects; cross-page navigation; presence of key UI elements | Fine-grained validation messages (flaky) |
| Integration | Real DB; auth; transactions; rollbacks; conflicts. Names state business outcomes only | Broad "click around" coverage |
Rule of thumb: Component = "does this form/component behave when I mock deps?" E2E = "does this flow work in a real browser?" Integration = "does this flow behave against a real DB?"
When invoked
- Read the code under test (function, module, or file the user indicated). Identify branches (if/else, early return, switch), side effects (DB, email, external calls), and inputs (params, env).
- Ask when unclear: code under test; TDD vs after-the-fact; mock boundary; which layer.
- For component tests — enumerate before writing. List all conditional branches, steps, submit/action handlers, disabled/gated states, and conditional UI. Map tests to code paths. Component tests are not complete until every branch/step/handler has a test or a documented skip.
- List testable behaviors — One line per behavior: e.g. "when user not found → return error", "when status accepted → send email".
- Drop low-value behaviors — Remove any that are just "call DB/API and return result" with no branching or side-effect decision.
- Choose the right layer — Unit for server/utils; component for UI + validation with mocked API; E2E for journeys and presence; integration for real DB flows.
- Write tests for the remaining behaviors only. Each test name: scenario and expected outcome. Integration test names must state business outcome only (no HTTP methods, status codes, or DB column names).
- Verify — Work is not done until all relevant test runs pass. Run the project's test commands. Passing only one suite is not enough when other layers exist. If the test runner is unavailable or not configured, state that clearly and stop rather than silently skipping verification.
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.
- 4d ago First seen · 96 lines · 71 tokens per session scan A a6591458b1e6
test-writer is a skill published in the GitHub repository osouthgate/agent-plus (4 stars, last pushed 1mo ago), licensed MIT. It adds 71 tokens to every session and 1,568 once invoked, about $0.0004 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
check-and-test
Run lint checks (ruff for Python, Biome for TS/JS), type checks (pyright for Python, tsc for TS/JS), and the standard pytest tiers (unit + e2e + tests skipped during pre-commit). Investigates failures to determine if they are application bugs or test issues, and fixes application bugs rather than weakening tests. Does…
testing
Writes and documents the test suite for a generated cli-web- CLI (Phase 3): unit tests with mocked HTTP, live E2E tests, subprocess tests via resolvecli, and the TEST.md plan/results record. Use after the methodology skill completes implementation.
testing-assistant
Manages testing lifecycle including unit tests, integration tests, validation, and quality assurance.
testing-strategy
Test pyramid, coverage targets, and test patterns (unit/integration/E2E). TRIGGER when: planning tests, writing test code, or reviewing coverage. SKIP: quality-gate scoring of plans (use quality-validation); security testing (use security-review-checklists). (Examples use common runners such as pytest and vitest.).
test-selection
Use this skill when someone describes a specific code path, feature, or bug and asks what kind of test to write for it — or when an audit or strategy engagement surfaces a testing gap and needs a recommendation for where to start. Trigger on "what test should I write for this", "unit or integration test for X", "our…
craft-testing
Craftsman standard for automated testing: strategy, unit/integration/e2e selection, refactor-proof design, flaky tests, mocking boundaries, deterministic data, and merge-gate policy. Use WHENEVER work touches tests: writing/reviewing tests, strategy, "add tests", "why is this flaky", "what should I test", "tests pass…