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 skills add nimadorostkar/Claude-Skills-collection --skill test-driven-developmentgit clone --depth 1 https://github.com/nimadorostkar/Claude-Skills-collectionWrote 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/nimadorostkar/claude-skills-collection/test-driven-development)<a href="https://agentmods.dev/skills/nimadorostkar/claude-skills-collection/test-driven-development"><img src="https://agentmods.dev/badge/skills/nimadorostkar/claude-skills-collection/test-driven-development/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/nimadorostkar/claude-skills-collection/test-driven-development"><img src="https://agentmods.dev/badge/skills/nimadorostkar/claude-skills-collection/test-driven-development.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.00039 | $0.01167 |
| Opus 5 | $0.00019 | $0.00583 |
| Sonnet 5 | $0.00008 | $0.00233 |
| Haiku 4.5 | $0.00004 | $0.00117 |
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 7d 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 — 106 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Test-Driven Development
Purpose
Use tests to drive design. TDD's value is not primarily the tests it produces — it is the pressure it puts on the design, because code that is hard to test is hard to use.
When to Use
- Implementing logic with clear inputs and outputs.
- Fixing a bug (the failing test comes first, always).
- Working in a codebase where you do not fully understand the existing behavior.
- Designing an API you will have to live with.
Capabilities
- The red-green-refactor cycle.
- Test selection: choosing the next test that moves the design forward.
- Outside-in (from the API) and inside-out (from the core) approaches.
- Using tests to characterize existing behavior before changing it.
Inputs
- The requirement, small enough to express as one test.
- The existing code, if any.
Outputs
- Code that exists because a test demanded it.
- A suite where every test failed before it passed.
- A design that is testable because it was built under test.
Workflow
- Red — Write the smallest test that fails for the right reason. Run it. Watch it fail. A test you have not seen fail is a test that may not be testing anything.
- Green — Write the least code that makes it pass. Hardcoding the answer is legitimate at this stage; the next test will force generalization.
- Refactor — With the test green, improve the structure. The test is your safety net, and this is the only step where you may change design without changing behavior.
- Choose the next test deliberately — The next test should either force a generalization or cover a new case. A test that already passes teaches nothing.
- Repeat in small cycles — Minutes, not hours. If you have been red for twenty minutes, the step was too big — revert and take a smaller one.
Best Practices
- Watch the test fail. A test that passes before you have written the code is testing nothing, and this happens more often than anyone admits.
- If a test is hard to write, the design is wrong. That signal is TDD's main product; do not suppress it by mocking your way around the difficulty.
- Do not write five tests and then the implementation. That is not TDD; it is speculation followed by a large step.
- Triangulate: the second test is what forces you to replace
return 42with an actual calculation. One test permits a hardcoded answer. - TDD is poor at discovering an algorithm you do not yet understand. Spike it in a scratch file, throw the spike away, then TDD the real thing knowing where you are going.
- Never skip the refactor step. TDD without refactoring produces working code with a poor design and a suite that pins it in place.
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.
- 7d ago First seen · 106 lines · 39 tokens per session scan A 91ecfe4d8c04
test-driven-development is a skill published in the GitHub repository nimadorostkar/Claude-Skills-collection (26 stars, last pushed 23d ago), licensed MIT. It adds 39 tokens to every session and 1,167 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-09-03.
Other skills, from other repositories
test-writer
Write thorough tests following TDD and BDD principles.
test-first-bugfix
Test-driven bug fixing — reproduce before you fix. Use this skill whenever the user reports a bug, describes unexpected behavior, says something is broken, mentions a regression, or asks you to fix an error. This includes phrases like "this is broken", "X doesn't work", "there's a bug in", "getting an error when", "it…
tdd
Test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants integration tests, or asks for test-first development.
rspec-testing
This skill should be used when writing, reviewing, or improving RSpec tests for Ruby on Rails applications. Use this skill for all testing tasks including model specs, controller specs, system specs, component specs, service specs, and integration tests. The skill provides comprehensive RSpec best practices from…
issue-driven-development
Use for any development work - the master 13-step coding process that orchestrates all other skills, ensuring GitHub issue tracking, proper branching, TDD, code review, and CI verification.
tdd-full-coverage
Use when implementing features or fixes - test-driven development with RED-GREEN-REFACTOR cycle and full code coverage requirement.