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-development-quicknpx skills add jaktestowac/awesome-copilot-for-testers --skill test-driven-development-quickgit 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-quick)<a href="https://agentmods.dev/skills/jaktestowac/awesome-copilot-for-testers/test-driven-development-quick"><img src="https://agentmods.dev/badge/skills/jaktestowac/awesome-copilot-for-testers/test-driven-development-quick.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.00108 | $0.01694 |
| Opus 5 | $0.00054 | $0.00847 |
| Sonnet 5 | $0.00022 | $0.00339 |
| Haiku 4.5 | $0.00011 | $0.00169 |
Grade A, and why
test-driven-development-quick 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 — 124 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Quick TDD
A compact standard for the red-green-refactor loop: enough to keep every change verified, short enough to read in one pass.
Framework-agnostic - match whatever runner and assertion style the project already uses. If none exists, ask which runner to target before the first test.
When to Use
- Build one new behavior test-first.
- Fix a bug by reproducing it with a failing test.
- Add a small branch or rule to code that already has tests.
Escalate to test-driven-development when the feature spans several units, needs an outside-in double loop, enters untested legacy code, or runs long enough to need a cycle log. Use writing-unit-tests when the code already exists and tests are being added after the fact.
Before the First Test
State three things:
- the behavior being built, in the user's vocabulary
- the seam - the public interface a real caller would use, which the tests observe through; name it and get it confirmed rather than assuming it
- the test list - the behaviors to build, smallest and most central first, worked one at a time
The list is a queue, not a batch. Writing all the tests up front verifies imagined behavior and locks in a shape nobody has validated.
Match the project's existing runner, test locations, and naming, and find the command that runs a single test file - the loop only works while observing red and green is cheap.
The Loop
Red
- Write one failing test for the next list entry.
- Run it and read the real output.
- Confirm it fails on the missing behavior - not a typo, missing import, or broken fixture. A mechanical failure is not red: fix it and run again.
- If it passes immediately, stop. Either the behavior exists already or the test asserts nothing.
- Check the expected value came from outside the implementation - the spec, a worked example, a known-good literal. A value recomputed the way the code computes it, or imported from the code's own constants, passes by construction.
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 · 124 lines · 108 tokens per session scan A b8ce7268a601
test-driven-development-quick is a skill published in the GitHub repository jaktestowac/awesome-copilot-for-testers (113 stars, last pushed 10d ago), licensed MIT. It adds 108 tokens to every session and 1,694 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.