Build features and bug fixes test first using a strict red, green, refactor loop. Use for TDD requests, regression tests, behavior changes with clear acceptance criteria, and risky logic that benefits from executable specification.
Collected from public GitHub. Every version is saved exactly as it was and never changes. Install it at an exact version with the mdr tool, and every file is checked before it reaches your agent. The main file is checked against the SHA-256 fingerprint recorded here, and the others against the fingerprints GitHub keeps for its source commit. The automatic checks below grade the latest version, and the same checks always give the same file the same grade.
What the file says
# Test-Driven Development
Use tests to define the behavior before implementing it.
## Red
1. Identify the narrowest externally meaningful behavior.
2. Find the nearest existing test style and harness.
3. Write one focused test using the public interface or real user surface.
4. Run it and confirm it fails for the intended reason.
5. If it passes immediately, the test does not prove the requested change.
## Green
1. Implement the smallest production change that satisfies the behavior.
2. Run the focused test.
3. Run nearby tests that exercise the same module or seam.
4. Keep unrelated cleanup out of the green step.
## Refactor
1. Remove duplication and clarify names without changing behavior.
2. Keep the tests green after each meaningful change.
3. Run formatting, static checks, and the proportionate broader suite.
## Test quality
- Prefer observable outcomes over implementation details.
- Include meaningful failure messages for complex invariants.
- Avoid sleeps when a deterministic signal is available.
- Do not mock the behavior under test.
- For a bug, preserve the original reproduction as a regression test whenever practical.
The line at the top of this page pins the label git:20260816.716d56b, which is what most people want. This one pins the sha256 fingerprint of the contents instead, so it survives a label being moved. Either way the exact version is written to mdr.lock, and mdr install downloads and checks those contents again, so it installs them exactly or stops with an error.
GET https://markdownregistry.com/api/v1/artifacts/art_3au3o6n3nwcydz4x
GET https://markdownregistry.com/api/v1/resolve?ref=miosa-osa/osa/test-driven-development
GET https://markdownregistry.com/api/v1/blob/c89541cecd114c8a6695c299183edd201f1701dc06e1751c9ee3c66a9d9aeeb4
Your AI assistant does the legwork. You hear about the deals worth your word. Hand yours the standing instructions at modelranch.com and it joins the network that reads files like this one.
miosa-osa/osa · examples/skills/meeting-prep/SKILL.md · Research attendees, prepare talking points, and summarize previous interactions before meetings
addyosmani/agent-skills · skills/test-driven-development/SKILL.md · Drives development with tests using the red-green-refactor loop. Use when implementing any logic, fixing any bug, or…
mvschwarz/openrig · skills/_canonical/process/test-driven-development/SKILL.md · Use when implementing any feature or bugfix, before writing implementation code
mvschwarz/openrig · packages/daemon/specs/agents/shared/skills/process/test-driven-development/SKILL.md · Use when implementing any feature or bugfix, before writing implementation code
cbrock84/headcount · plugins/technology/skills/test-driven-development/SKILL.md · Drives implementation by writing a failing test first, then the smallest code that passes it. Use this before writing…
a5c-ai/babysitter · library/methodologies/superpowers/skills/test-driven-development/SKILL.md · Use when implementing any feature or bugfix, before writing implementation code. Enforces RED-GREEN-REFACTOR cycle.
a5c-ai/babysitter · library/methodologies/rpikit/skills/test-driven-development/SKILL.md · Test-first development practice where test specifications are written before production code, integrated into plan…
