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 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/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/osouthgate/agent-plus/test-writer"><img src="https://agentmods.dev/badge/skills/osouthgate/agent-plus/test-writer.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.00071 | $0.01568 |
| Opus 5.5 | $0.00028 | $0.00627 |
| Sonnet 5.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 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 — 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.
- 1mo 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 3mo ago), licensed MIT. It adds 71 tokens to every session and 1,568 once invoked, about $0.0003 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-08-31.
Other skills, from other repositories
ios-testing-patterns
XCTest and XCUITest execution workflows and flaky test detection patterns.
verify
Verification loop — lint -> typecheck -> unit -> integration -> e2e.
testing-assistant
Manages testing lifecycle including unit tests, integration tests, validation, and quality assurance.
check-coverage
Comprehensive assessment of Unit / Integration / E2E three-layer test coverage, identify gaps and provide actionable recommendations.
proof-strategy
Produce a test strategy for a project or feature — risk map, test type decisions, coverage targets, CI config. Use when asked to "create test strategy", "what should we test", "testing plan", or "improve test coverage".
knowledge-engineering-quality-and-delivery-unit-integration-and-shared-test-harnesses
A testing guide for the CLI and web interfaces, covering unit, integration, end-to-end, and real-process test setup with shared fixtures and cleanup.