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 skrrt-sh/skills --skill testinggit clone --depth 1 https://github.com/skrrt-sh/skillsWrote 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/skrrt-sh/skills/testing)<a href="https://agentmods.dev/skills/skrrt-sh/skills/testing"><img src="https://agentmods.dev/badge/skills/skrrt-sh/skills/testing/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/skrrt-sh/skills/testing"><img src="https://agentmods.dev/badge/skills/skrrt-sh/skills/testing.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.00096 | $0.00794 |
| Opus 5.5 | $0.00038 | $0.00318 |
| Sonnet 5.5 | $0.00019 | $0.00159 |
| Haiku 4.5 | $0.00010 | $0.00079 |
Grade A, and why
testing 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 6d 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 — 66 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Testing
A test exists only to guard business logic that could break unnoticed.
Write
- Test business logic: domain rules, calculations, state transitions, decisions.
- Cover its corner cases: boundaries, empty or missing input, invalid states, ordering, failure paths.
- Test through the public interface. A refactor must not break a test.
- A bug fix gets one test that asserts the invariant the bug broke, such as "a refund never exceeds the charge". Never assert an incidental output of the fix.
Fix
- Fix a bug test-first: write the failing test, then the fix.
- Fix a flaky test at its root cause, such as with a fake clock. Never raise timeouts or loosen bounds. Then run it 20 times in a row.
Do not write
- Tests for third-party libraries, the framework, or the language.
- Tests for internals: private helpers, wiring, implementation steps.
- Tests for obvious code: getters, setters, constructors, code without branches, and mappers or DTO conversions, including field selection, renaming, and standard formatting. Field selection that keeps secrets or private data out is a security rule: test it.
- Assertions about a library call's result: that it is set, differs from the input, or has a format. Assert only your code's decision around the call. Stub the library when it is slow or nondeterministic.
- Unit tests of thin I/O adapters against hand-made fakes of the library they wrap.
- A test for a rule an existing test already covers. Extend that test instead.
When asked to test a unit, end the reply with one line naming what you left untested and why.
Verify
Before reporting anything as done or fixed:
- Run it for real on every platform it ships to, as every role the flow touches, such as guest and signed-in: simulators, a headless browser, staging, or a local stack.
- Check the original bug is gone and nothing that worked before broke.
- When login, onboarding, or missing data blocks the check, create a test account or seed data yourself. When no headless browser or simulator is installed, install one, such as Playwright.
- Before telling the user to change their setup, reproduce the failure and prove the cause.
- When speed or resource use is a goal, measure before and after and report the numbers.
- Keep the check loop short: script a harness instead of manual walkthroughs.
- Wait on an event, log line, or exit, never a fixed sleep. Kill jobs that stop making progress.
- Stop old instances first. Use your own headless devices; never one the user or another agent holds, and never the user's mouse or screen unless they ask. Shut down what you started.
- Report what you ran and what you saw. Unverified means not done.
What ships with it
3 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 6d ago First seen · 66 lines · 96 tokens per session scan A 614ec0839e77
testing is a skill published in the GitHub repository skrrt-sh/skills (3 stars, last pushed today), licensed MIT. It adds 96 tokens to every session and 794 once invoked, about $0.0004 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-10-22.
Other skills, from other repositories
dotnet-test
This skill should be used when running .NET tests selectively with a build-first, test-targeted workflow. Use it for running tests with xUnit focus.
laravel-testing
Use when testing controllers, services, or models, or implementing TDD on Laravel 13 with Pest 5 / PHPUnit 13 (or Pest 4 / PHPUnit 12 on PHP 8.3).
Component Test Scaffold (Next.js)
Generate React/Next.js component test skeletons (RTL) from specifications.
Component Test Scaffold (Vue.js)
Generate Vue.js component test skeletons (Vue Test Utils) from specifications.
Test Scaffold (Laravel/PHPUnit)
Generate PHP/Laravel (PHPUnit) test skeletons from specifications.
Component Test Scaffold (React)
Generate generic React component test skeletons (RTL) from specifications.