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/evgenii-studitskikh/claude-code-saas-studio/write-testsnpx skills add evgenii-studitskikh/Claude-Code-SaaS-Studio --skill write-testsgit clone --depth 1 https://github.com/evgenii-studitskikh/Claude-Code-SaaS-StudioWrote 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/evgenii-studitskikh/claude-code-saas-studio/write-tests)<a href="https://agentmods.dev/skills/evgenii-studitskikh/claude-code-saas-studio/write-tests"><img src="https://agentmods.dev/badge/skills/evgenii-studitskikh/claude-code-saas-studio/write-tests.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.00047 | $0.00733 |
| Opus 5 | $0.00023 | $0.00367 |
| Sonnet 5 | $0.00009 | $0.00147 |
| Haiku 4.5 | $0.00005 | $0.00073 |
Grade A, and why
write-tests 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 — 22 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Author a complete, passing test suite for one user story, covering every layer the QA plan prescribes for that story's risk profile. Non-autonomous: identify the target, propose cases, get approval, write, then prove green. Never use real secrets or live network calls in tests.
Phases
- Load context — read
docs/specs/qa-plan.mdto understand the pyramid and conventions; readdocs/specs/prd.mdto list available stories. Ask the user which story or feature to target. Ifqa-plan.mdis missing, stop and direct to/qa-plan; if the test scaffold is absent (novitest.config.ts), stop and direct to/test-setup. - Propose cases — for the chosen story, enumerate the specific test cases at each layer: (a) unit tests for pure functions/helpers; (b) integration tests for server actions, route handlers, and API routes (using mocked DB/Stripe calls); (c) e2e tests for the critical user path in Playwright; (d) RLS policy tests asserting that other-tenant rows are inaccessible; (e) Stripe webhook tests using
stripe.webhooks.generateTestHeaderString(or the Stripe CLIstripe trigger) with a signed test payload — never real keys. Present the list with a note on what each case catches. Underfull, confirm each layer separately; underlean, one confirmation for the full list; undersolo, proceed and summarize. Get explicit approval before writing any test code. - Write — on approval, author the test files in the locations prescribed by the QA plan (e.g.
src/__tests__/,e2e/). Follow conventions fromdocs/specs/qa-plan.mdand, if present, the.claude/rules/tests.mdrule. Reference secrets by env-var name only (e.g.process.env.STRIPE_WEBHOOK_SECRET) — never embed literal secret-shaped strings. Use seeded or in-memory test data, not production data. - Run green — execute
npm test(orvitest run) for unit/integration tests andnpm run test:e2efor Playwright tests; show the output. If any test fails, diagnose the root cause, fix the test or the fixture, and re-run. Repeat until the full suite for this story is green; if the suite cannot be made green within the session, surface the remaining failures for the user to resolve and still point to/code-review. Underfull, show each failure and proposed fix before applying; underleanorsolo, fix and re-run, then show the final result. - Next step — once the suite is green, point to
/code-reviewto review the new tests alongside the feature code.
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 · 22 lines · 47 tokens per session scan A 1a1e1b274094
write-tests is a skill published in the GitHub repository evgenii-studitskikh/Claude-Code-SaaS-Studio (1 stars, last pushed 2mo ago), licensed MIT. It adds 47 tokens to every session and 733 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
test-software
Design, implement, and evaluate risk-based software tests across unit, integration, contract, end-to-end, and regression layers. Use when adding tests, reproducing bugs, improving coverage, diagnosing flaky tests, or defining a test strategy; do not use to change production behavior unless the user also requests…
aidex-coverage
Use when writing, placing, or running tests in any project — which layer a behaviour belongs in ("unit or E2E for X", "component test or browser test"), which tests to run for a change instead of the whole suite, when to extract a fixture, setting up an isolated disposable E2E environment, or the per-project testing…
Android Testing
JUnit + Robolectric unit tests, Compose UI tests, screenshot tests, and Espresso for legacy views.
devteam-test
Coordinate test writing and execution across the project. Launches the Test Coordinator to orchestrate language-specific test writers and verification agents.
javascript-testing-patterns
Implement comprehensive testing strategies using Jest, Vitest, and Testing Library for unit tests, integration tests, and end-to-end testing with mocking, fixtures, and test-driven development. Use when writing JavaScript/TypeScript tests, setting up test infrastructure, or implementing TDD/BDD workflows.
iOS Testing
XCTest unit tests, XCUITest UI tests, snapshot testing, and performance baselines for iOS apps.