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/retemper/litmus/tddnpx skills add retemper/litmus --skill tddgit clone --depth 1 https://github.com/retemper/litmusWrote 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/retemper/litmus/tdd)<a href="https://agentmods.dev/skills/retemper/litmus/tdd"><img src="https://agentmods.dev/badge/skills/retemper/litmus/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.00049 | $0.00646 |
| Opus 5 | $0.00024 | $0.00323 |
| Sonnet 5 | $0.00010 | $0.00129 |
| Haiku 4.5 | $0.00005 | $0.00065 |
Grade A, and why
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 5d 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 — 38 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/tdd — test-driven development loop
Drive the change one thin vertical slice at a time: one failing test → just enough code to pass → refactor. Tests describe behaviour through the public interface, never implementation detail.
Core philosophy
- Test behaviour, not internals. A test should verify what a caller observes through the public surface. If you mock the unit's own collaborators or reach into private state/methods, the test couples to implementation and breaks on every refactor — exactly when you most want it green.
- Vertical slices, not horizontal. Do not write all the tests first and all the implementation later (a horizontal slice — it front-loads guesswork and delays feedback). Instead fire a tracer bullet: one test, then the code to satisfy it, then the next. Each loop is end-to-end and shippable.
- Let the test drive the design. If a behaviour is awkward to test, that is design feedback, not a reason to test internals.
The loop
- Pick the next slice. The smallest behaviour that moves the change forward.
- Know the test type. Decide which litmus type this slice needs (Unit for logic, Integration for a boundary, etc.). Not sure? Call the litmus
list_test_typestool. Load that type's rules now — callget_guide(e.g.get_guide "unit"), or readguides/NN-*.mddirectly — so your cases follow its must-cover list and principles. - RED. Write one test that asserts the behaviour. Run it. Watch it fail for the right reason (a real assertion failure, not a compile/setup error).
- GREEN. Write the least code that makes it pass. Resist building ahead of the test.
- REFACTOR. With the test green, clean up names, duplication, and structure. Re-run — still green.
- Repeat from step 1 until the change is complete.
Before you start
- If tests already cover the area, extend or modify them rather than creating parallel ones.
- Match the project's existing test framework, layout, and naming — read a neighbouring test first.
- For each new test type you introduce, load its guide once up front (
get_guide, orguides/NN-*.md) so the whole slice follows the same rules.
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.
- 5d ago First seen · 38 lines · 49 tokens per session scan A e16acc7132a0
tdd is a skill published in the GitHub repository retemper/litmus (0 stars, last pushed 1mo ago), licensed MIT. It adds 49 tokens to every session and 646 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
testing-principles
Language-agnostic testing principles including TDD, test quality, coverage standards, and test design patterns. Use when writing tests, designing test strategies, or reviewing test quality.
auto-loop
TDD-based autonomous development loop with checkpoint recovery and observability changelog.
workflow
Run the complete 5-step development workflow: focus problem → prevent over-development → test-first (TDD) → document → smart commit. Use when starting a new feature, or when the user runs /workflow or asks for the full development flow.
red-green-refactor
Guides the red-green-refactor TDD workflow: write a failing test first, implement the minimum code to make it pass, then refactor while keeping tests green. Use when a user asks to practice TDD, write tests first, follow red-green-refactor, do test-driven development, write failing tests before code, or phrases like…
specify-incremental
Decompose a single-feature specification into a linear, phase-by-phase implementation plan. Use this for medium-complexity work — single feature, one or two components — where transparent human-in-the-loop phase review is preferred over factory automation.
test-first
Drive one feature through a strict TDD Red-Green-Refactor cycle with checklists for each phase. Use when implementing new functionality test-first, or when the user runs /test-first.