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/damusix/atomic-claude/atomic-tddnpx skills add damusix/atomic-claude --skill atomic-tddgit clone --depth 1 https://github.com/damusix/atomic-claudeWrote 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/damusix/atomic-claude/atomic-tdd)<a href="https://agentmods.dev/skills/damusix/atomic-claude/atomic-tdd"><img src="https://agentmods.dev/badge/skills/damusix/atomic-claude/atomic-tdd.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.1 | $0.00142 | $0.01072 |
| Opus 5 | $0.00071 | $0.00536 |
| Sonnet 5 | $0.00028 | $0.00214 |
| Haiku 4.5 | $0.00014 | $0.00107 |
Grade A, and why
atomic-tdd 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 — 103 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Test first. Watch it fail. Write minimal code. Watch it pass. Refactor green.
Auto-trigger on:
- "let's implement X", "add feature Y", "build out Z"
- "fix bug", "patch the regression"
- "write tests for", "write a test for"
- "make the code do X"
- Any pre-implementation language for behavior changes
Explicit: /atomic-tdd.
The iron law
Write the failing test before production code. Why: tests written after implementation mirror what the code does, not what it should do. Tests-first are specifications; tests-after are tautologies.
Wrote code before a failing test? Delete it. Start over. Why: keeping existing code as reference biases the test toward the implementation rather than the intent.
The cycle
| Step | Action | Verify |
|---|---|---|
| RED | Write one minimal failing test | Run it. Must fail for the right reason — feature missing, not a typo. If it passes immediately, the test is wrong. Fix the test. |
| GREEN | Write the smallest code that makes the test pass | Run all tests. Must be green. No "while I'm here" extras. |
| REFACTOR | Clean up only after green | Re-run. Must stay green. No behavior changes. |
Repeat for the next behavior.
Required for
- New features — any new behavior
- Bug fixes — test reproduces the bug first, then fix
- Refactoring — existing tests must stay green; if none exist, add one first
- Behavior changes
Skip rules
TDD doesn't apply to these cases. Each skip requires an explicit skipped because: <reason> note in the response.
| Skip case | Example |
|---|---|
| Pure docs / Markdown / comment-only edits | Updating README, adding a JSDoc |
Pure config / .env / non-executable file edits |
Changing a JSON config, updating an env var |
| Generated code | Regenerated from a schema or spec, not hand-written |
| Throwaway prototypes the user explicitly flagged as throwaway | "Just spike this, we'll throw it away" |
Skipping silently = violation.
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 · 103 lines · 142 tokens per session scan A 8b5d6c0ef995
atomic-tdd is a skill published in the GitHub repository damusix/atomic-claude (84 stars, last pushed today), licensed MIT. It adds 142 tokens to every session and 1,072 once invoked, about $0.0007 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 skills, from other repositories
tdd-rust
TDD workflow for RTK filter development. Red-Green-Refactor with Rust idioms. Real fixtures, token savings assertions, snapshot tests with insta. Auto-triggers on new filter implementation.
rtk-tdd
Enforces TDD (Red-Green-Refactor) for Rust development. Auto-triggers on implementation, testing, refactoring, and bug fixing tasks. Provides Rust-idiomatic testing patterns with anyhow/thiserror, cfg(test), and Arrange-Act-Assert workflow.
writing-skills
当创建新技能、编辑现有技能或在部署前验证技能是否有效时使用.
test-driven-development
在实现任何功能或修复 bug 时使用，在编写实现代码之前.
test-driven-development
Use when the user explicitly requests strict or test-first TDD, or when the current conversation already contains an explicit TDD Route: strict decision from another Aegis workflow.
moai-workflow-tdd
Test-Driven Development workflow specialist using RED-GREEN-REFACTOR cycle for test-first software development. Use when developing new features from scratch or when behavior specification drives implementation.