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/wazimmerman/zimster/test-driven-developmentnpx skills add wazimmerman/zimster --skill test-driven-developmentgit clone --depth 1 https://github.com/wazimmerman/zimsterWrote 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/wazimmerman/zimster/test-driven-development)<a href="https://agentmods.dev/skills/wazimmerman/zimster/test-driven-development"><img src="https://agentmods.dev/badge/skills/wazimmerman/zimster/test-driven-development.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.00024 | $0.00806 |
| Opus 5 | $0.00012 | $0.00403 |
| Sonnet 5 | $0.00005 | $0.00161 |
| Haiku 4.5 | $0.00002 | $0.00081 |
Grade A, and why
test-driven-development 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 3d 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 — 117 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Test-Driven Development
Adapted from Superpowers' TDD discipline under the MIT License.
Iron law
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
RED must fail for the expected reason: the behavioral defect, not a typo, broken fixture, missing dependency, or unrelated setup error.
RED for one behavior
Write the smallest test or executable reproduction for one observable behavior. State:
- the production defect/change that this test detects;
- expected failure signal;
- why current behavior should fail.
Run it. A passing test proves no new behavior. A command that fails before test discovery proves only setup failure.
Multi-behavior features
For multiple behaviors, a “module not found” RED does not prove the individual behavior tests. It proves only that the module is absent; each load-bearing behavior still needs falsifiable evidence.
Use one or a combination of:
- incremental RED-GREEN cycles for each load-bearing behavior;
- a deliberately incomplete stub that permits each behavioral test to fail meaningfully before implementation;
- focused mutation checks that remove or invert each important invariant and demonstrate the corresponding test becomes RED.
Several behaviors may share one commit and one efficient test invocation, but the evidence must identify meaningful RED for each load-bearing behavior.
Prefer real behavior over mock-call choreography. Mock only unavoidable boundaries and assert externally meaningful outcomes.
GREEN
Write the least production code that makes the focused RED pass. Do not add speculative options or unrelated refactors. Run the focused proof, then the smallest affected repository-declared test group.
REFACTOR
Only after GREEN:
- remove duplication;
- improve names/boundaries;
- simplify control flow;
- extract a reusable unit when a second real use exists.
Keep focused and affected proofs green; refactoring adds no behavior.
Regression and falsifiability checks
For a bug fix, or for a high-value invariant in a multi-behavior feature:
What ships with it
1 file 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.
- 3d ago First seen · 117 lines · 24 tokens per session scan A c4c8b4ca3d0e
test-driven-development is a skill published in the GitHub repository wazimmerman/zimster (2 stars, last pushed 16d ago), licensed MIT. It adds 24 tokens to every session and 806 once invoked, about $0.0001 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
treework-manual
Use TreeWork Manual when the user asks for it, or when the Agent judges that organizing ongoing, multi-part work as a persistent Markdown Tree would improve direction, continuity, recovery, or handoff. Adapt the Tree's depth and document detail to the user's needs, domain, and situation rather than a fixed threshold.
treework
Use TreeWork, a tree-guided development plugin for complex or evolving software projects that need staged alignment, pre-coding technical Specs, declarative project-tree planning, branch-scoped Git worktrees, durable recovery, and protected completion. It teaches the Agent to move through development along the Tree…
debugging
Investigate failures whose root cause is still unknown — narrow the search space, instrument, and test falsifiable hypotheses. Use for intermittent or environment-dependent behavior, unexplained stack traces, regressions with no known trigger, or any symptom without a confirmed cause. Ends once the root cause is…
architecture-review
Method for assessing a codebase's structure — duplication, single-responsibility violations, layering problems, and coupling — and recommending minimal, incremental improvements. Use when asked to review architecture, assess structure or technical debt, evaluate module boundaries, or plan a refactor. Reviews the…
code-quality-review
Checklist and method for reviewing code quality — readability, maintainability, SOLID, DRY, performance, and backward compatibility. Use when asked to review code, a diff, a branch, or a merge request for quality, or before finalizing significant changes. For GitHub PR review use the built-in /review; for…
security-audit
Security review and hardening workflow — root-cause analysis of vulnerabilities, authentication and authorization checks, least privilege, input handling, secret hygiene, and security regression tests. Use when reviewing code for security, fixing a vulnerability, hardening a feature, or handling auth, permissions…