Borrowing it
Nothing to install: this file belongs to mrlarson2007/copilot-tdd-harness. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/mrlarson2007/copilot-tdd-harness/master/.github/skills/tdd-workflow/SKILL.mdgit clone --depth 1 https://github.com/mrlarson2007/copilot-tdd-harnessWrote 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/mrlarson2007/copilot-tdd-harness/tdd-workflow)<a href="https://agentmods.dev/skills/mrlarson2007/copilot-tdd-harness/tdd-workflow"><img src="https://agentmods.dev/badge/skills/mrlarson2007/copilot-tdd-harness/tdd-workflow.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.00060 | $0.01127 |
| Opus 5 | $0.00030 | $0.00563 |
| Sonnet 5 | $0.00012 | $0.00225 |
| Haiku 4.5 | $0.00006 | $0.00113 |
Grade A, and why
tdd-workflow 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 8d 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 — 114 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Use this skill when implementing or changing behavior via strict TDD.
This skill assumes a concrete target behavior has already been chosen by the
user or by tdd-planning. It governs execution discipline; it does not decide
which feature slice to implement next.
Core Rules (Distilled)
- Never write production code before a failing test (RED first).
- Write exactly one new test per TDD cycle (one behavior at a time).
- Prefer edge cases first, then happy-path coverage.
- In GREEN, write the smallest possible code to pass the failing test only.
- Every RED, GREEN, and REFACTOR edit must be followed by an explicit VERIFY step.
- If VERIFY disproves the expected result, revert only the in-scope changes from the current step and return to the preceding step.
- Do not refactor while any test is failing.
- Keep tests permanent; do not delete or weaken tests to force passing results.
- Commit immediately after GREEN — test + production code together in one commit.
- Commit again after REFACTOR — if any refactoring was done, commit the cleaned-up code before starting the next RED cycle. Never carry uncommitted refactoring into the next cycle.
Required Test Naming
All newly added tests should follow:
WhenCondition_ShouldExpectedOutcome
Examples:
WhenInputIsNull_ShouldThrowValidationErrorWhenCartIsEmpty_ShouldReturnZeroTotalWhenTokenIsExpired_ShouldReturnUnauthorized
Execution Discipline
RED
- Add one failing test for the next behavior.
- VERIFY the expected failing result through
tdd-test-run. - No production code edits.
GREEN
- Make the failing test pass with minimal code.
- VERIFY the expected passing result through
tdd-test-run. - Avoid speculative functionality.
- Keep all existing tests green.
Minimal GREEN examples:
- Return a constant required by the test (temporarily) instead of building broader logic.
- Add the narrowest conditional branch needed for the new failing edge case.
- Create only the smallest helper needed to satisfy current assertions.
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.
- 8d ago First seen · 114 lines · 60 tokens per session scan A d2fc2a6f1a87
tdd-workflow is a skill published in the GitHub repository mrlarson2007/copilot-tdd-harness (5 stars, last pushed 3mo ago), licensed MIT. It adds 60 tokens to every session and 1,127 once invoked, about $0.0003 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
engram-testing-coverage
TDD and coverage standards for Engram. Trigger: When implementing behavior changes in any package.
nw-fp-clojure
Clojure language-specific patterns, data-first modeling, REPL-driven development, and spec.
strict-tdd
Strict RED->GREEN->REFACTOR test-driven development with enforcement. Never write production code before a failing test. Atomic commits per TDD cycle.
mobiai-mobile-tdd
You MUST use this before writing any implementation code for a mobile feature, bug fix, refactor, or behavior change. Tests come before implementation — no exceptions.
tdd
This skill should be used when the user wants to implement features or fix bugs using test-driven development. Enforces the RED-GREEN-REFACTOR cycle with vertical slicing, context isolation between test writing and implementation, human checkpoints, and auto-test feedback loops. Uses multi-agent orchestration with the…
conductor-implement
Execute tasks from a track's implementation plan following TDD workflow.