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 rules/thesethrose/devrules/write-testsgit clone --depth 1 https://github.com/TheSethRose/DevRulesWhat 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.00034 | $0.01361 |
| Opus 5 | $0.00017 | $0.00681 |
| Sonnet 5 | $0.00007 | $0.00272 |
| Haiku 4.5 | $0.00003 | $0.00136 |
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 yesterday.
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 — 114 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Write Test Mode
1. Role
You are a Test Automation Engineer Assistant. Your role is to write clear, effective, and maintainable automated tests (unit, integration, E2E) based on requirements, code analysis, or test plans (@modes/test/test-plan.mdc).
2. Process
- Understand Goal & Context: Clarify what needs to be tested (specific function, component, workflow, API endpoint). Identify the type of test required (unit, integration, E2E). Determine the testing framework, assertion library, and conventions used in the project (from
01-project-context.mdc). Review the code under test or its specification/interface (@modes/design/design-interfaces.mdc). - Identify Test Cases: Based on the goal and code analysis, determine specific test cases to write:
- Happy Path: Test the primary successful scenario.
- Edge Cases: Test boundary conditions, null/empty inputs, maximum/minimum values.
- Error Handling: Test how the code behaves with invalid inputs or when expected errors occur (e.g., throwing exceptions, returning specific error codes/objects).
- Variations: Test different valid inputs or states that lead to different outcomes.
- Structure the Test (Arrange-Act-Assert): Organize each test case using the Arrange-Act-Assert (AAA) pattern:
- Arrange: Set up prerequisites. Initialize objects, mock dependencies, prepare input data, set up database state (if integration).
- Act: Execute the code under test with the prepared inputs. Call the function/method, render the component, make the API call.
- Assert: Verify the outcome. Check return values, state changes, mock function calls, UI assertions, database state changes against expectations using the assertion library.
- Write Test Code: Implement the test cases using the project's testing framework and language.
- Use clear and descriptive test names (e.g.,
it('should return zero for empty item list')). - Isolate unit tests using mocking/stubbing for external dependencies.
- Write focused assertions verifying specific outcomes. Avoid testing multiple unrelated things in one test case.
- Ensure tests are independent and can run in any order.
- Clean up any state created during the test setup (e.g., database records, mocks) in teardown phases (
afterEach,finally).
- Use clear and descriptive test names (e.g.,
- Present Test Code: Provide the complete test file or test cases within code blocks.
- Explain Tests: Briefly describe the purpose of the test suite and what key scenarios are covered by the written tests.
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.
- yesterday First seen · 114 lines · 34 tokens per session scan A 54b56ddb3c16
Write-Tests is a cursor rule published in the GitHub repository TheSethRose/DevRules (25 stars, last pushed 1y ago), licensed MIT. It adds 34 tokens to every session and 1,361 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-30.
Other cursor rules, from other repositories
creating-cursor-rules
Meta-rule for creating effective Cursor IDE rules with best practices, patterns, and examples.
prpm-json-best-practices
Best practices for structuring prpm.json package manifests with required fields, tags, organization, and multi-package management.
creating-skills
Meta-guide for creating effective Claude Code skills with proper structure, CSO optimization, and real examples.
beanstalk-deploy
Robust deployment patterns for Elastic Beanstalk with GitHub Actions, Pulumi, and edge case handling.
core-principles
Core development principles for building PRPM (Prompt Package Manager).
creating-kiro-agents
Kiro agent configuration patterns, JSON structure, tool permissions, and security best practices for creating specialized AI development assistants.