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/jaktestowac/awesome-copilot-for-testers/test-driven-developmentnpx skills add jaktestowac/awesome-copilot-for-testers --skill test-driven-developmentgit clone --depth 1 https://github.com/jaktestowac/awesome-copilot-for-testersWrote 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/jaktestowac/awesome-copilot-for-testers/test-driven-development)<a href="https://agentmods.dev/skills/jaktestowac/awesome-copilot-for-testers/test-driven-development"><img src="https://agentmods.dev/badge/skills/jaktestowac/awesome-copilot-for-testers/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.1 | $0.00101 | $0.04887 |
| Opus 5 | $0.00051 | $0.02443 |
| Sonnet 5 | $0.00020 | $0.00977 |
| Haiku 4.5 | $0.00010 | $0.00489 |
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 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 — 305 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Test-Driven Development
Use this skill when tests should drive the design instead of documenting it afterwards. It keeps the work in small, verified steps: one failing test, one minimal implementation, one cleanup, repeat.
This skill is framework-agnostic. It does not assume a runner, an assertion library, or a mocking tool. Detect what the project already uses before the first cycle; if nothing exists yet, ask which runner to target before writing a test.
When to Use
Trigger phrases: "TDD", "test-driven", "test-first", "red-green-refactor", "write the test first", "start with a failing test", "make it fail, then make it pass", "reproduce it with a test before fixing".
Typical situations:
- build a new behavior test-first
- fix a bug by reproducing it with a failing test first
- add safety before refactoring untested code
- explore an unclear interface by writing the call you wish existed
- recover a codebase where implementation consistently outruns verification
Reach for this skill before writing production code, not after. If tests are being added to code that already exists, use writing-unit-tests instead.
What TDD Is Here
TDD is a design technique that produces tests as a by-product - not a coverage technique. The loop's value is the pressure it puts on the interface: code that is hard to test first is usually code that is hard to use.
Judge a session by whether the design got clearer and every change was verified, not by the coverage number it produced.
The seam
A seam is the public boundary the test observes behavior through - the interface a real caller would use. Tests live at seams, never against internals.
Every cycle starts by knowing which seam it drives. If you cannot name the seam, you are not ready to write the test.
Seams are agreed, not assumed. Name the seams you intend to test at and get them confirmed before the first test exists. Testing effort is finite; agreeing the seams up front is how it lands on the critical paths and the complex logic instead of on every edge case. Do not write a test at a seam nobody has confirmed.
What ships with it
4 files 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.
- 6d ago First seen · 305 lines · 101 tokens per session scan A 9a9e575eb549
test-driven-development is a skill published in the GitHub repository jaktestowac/awesome-copilot-for-testers (113 stars, last pushed 10d ago), licensed MIT. It adds 101 tokens to every session and 4,887 once invoked, about $0.0005 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
skill-tdd
Build features with tests-before-code rigor — use for new features needing test coverage.
outside-in-tdd
Use when writing tests from the outside-in, defining behavior before code, or any feature where tests should start from observable business behavior and let internal design emerge.
testing-strategy
Design test strategies and test plans with coverage targets. Complements /draft:coverage which measures what this skill plans. Auto-loaded by /draft:implement before TDD.
ralphctl-test-driven-development
Execute-phase skill — write the failing test before the code that makes it pass; for bug fixes, this is the reproduction test itself. Use for any logic change, bug fix, or behavioural modification; for the full root-cause triage pipeline around an unexpected failure, see ralphctl-debugging-and-error-recovery.
red-synthesize-green
Use when implementing any feature or fix using TDD, before writing any implementation code.
refactor
You are the Refactor Specialist, a rigorous code quality engineer who improves code structure, maintainability, and performance while preserving behavior. You never break working code - you make it better.