test-driven-development
Skill14 starsChanged 7 months agoMITView on GitHub
Use when implementing any feature or bugfix, before writing implementation code. Enforces RED-GREEN-REFACTOR cycle: write failing test first, watch it fail, write minimal code, watch it pass.
190 other projects use a version of this, 120 of them edited.
Adopted by
Most recently taken up by
- DemonDamon/AgenticXedited, first seen Nov 9, 2026
- chrysogonus/power-agentsedited, first seen Nov 8, 2026
- ishandutta2007/Awesome-Agent-Skillstheir own version, first seen Nov 8, 2026
- roundpilot/superpowers-antigravityedited, first seen Nov 8, 2026
- REPOZY/superpowers-optimizedtheir own version, first seen Nov 8, 2026
- lingyired/status-trioedited, first seen Nov 8, 2026
Used with
Projects with it also use chinese-code-review, chinese-commit-conventions and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
Leodorareluctant259Skillchinese-code-review
中文代码审查规范——在保持专业严谨的同时,用符合国内团队文化的方式给出有效反馈
Also in 8 projects that use this
Leodorareluctant259Skillchinese-commit-conventions
中文 Git 提交规范 — 适配国内团队的 commit message 规范和 changelog 自动化
Also in 8 projects that use this
obraSkilldiagnosing-superpowers
Use when a superpowers session went wrong and your human partner wants to know why — repeated work, ignored plans, stumbles, poor results, a skill that didn't fire, "it took too long", "why is it so expensive", "what is it doing" — or wants to build a bug report for the superpowers maintainers, for the current session or a past one identified by id or path, on any harness.
Also in 19 projects that use this
LLl0k0laDSkillusing-agent-skills
Use when starting a session or when you need to discover which skill applies to the current task. This is the meta-skill that governs how all other skills are discovered and invoked.
Also in 39 projects that use this
LLl0k0laDSkillgit-workflow-and-versioning
Use when making any code change. Use when committing, branching, resolving conflicts, or when you need to organize work across multiple parallel streams.
Also in 47 projects that use this
MrCipherSmithSkillconstraint-driven-development
Use when a project needs a persistent, measurable quality bar — starting a project without documented standards, 'set up constraints', or when coverage/perf/a11y thresholds get re-debated per-PR. Produces CONSTRAINTS.md with enforceable numbers, ratchets, and a guard against silent weakening. NOT for throwaway prototypes or a one-off CI setup.
Also in 15 projects that use this
- +3 more from Leodorareluctant259
- +3 more from LLl0k0laD
Other versions190 projects use a version of this.
Word for word · 0
None found.
Edited · 120
- obra/superpowers★ 314k40% same
- NousResearch/hermes-agent★ 262k25% same
- openai/plugins★ 7.8k44% same
- farm-fe/farm★ 5.6k40% same
- microsoft/FluidFramework★ 4.9k15% same
- lingyired/status-trio★ 1.8k40% same
- pcvelz/superpowers★ 1.3k40% same
- math-inc/OpenGauss★ 1.3k28% same
- DemonDamon/AgenticX★ 1k40% same
- coco-research/coco★ 79739% same
110 more not listed
Wrote their own version · 70
- addyosmani/agent-skills★ 114ksame name
- cloudflare/computer★ 9.9ksame name
- jnMetaCode/superpowers-zh★ 8.4ksame name
- mikeyobrien/ralph-orchestrator★ 3.2ksame name
- crbnos/carbon★ 2.8ksame name
- ollaya-dev/ollaya★ 1.4ksame name
- GanyuanRan/Aegis★ 1.4ksame name
- taichuy/1flowbase★ 292same name
- KbWen/agentic-os★ 229same name
- DevelopersGlobal/ai-agent-skills★ 216same name
60 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository41 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .github/AGENTS.mdAGENTS.md
- .github/copilot-instructions.mdCopilot instructions
- llms.txtllms.txt
- brainstormingSkill
- drift-adr-workflowSkill
- drift-agent-prompt-authoringSkill
- drift-commit-pushSkill
- drift-dependency-updateSkill
- drift-docs-gap-fixSkill
- drift-evidence-artifact-authoringSkill
- drift-finding-message-authoringSkill
- drift-ground-truth-fixture-developmentSkill
- drift-mcp-repo-ops-usageSkill
- drift-pr-review-loopSkill
- drift-pr-reviewSkill
- drift-releaseSkill
- drift-risk-audit-artifact-updatesSkill
- drift-security-triageSkill
- drift-session-handover-authoringSkill
- drift-signal-development-full-lifecycleSkill
- fix-failing-actionsSkill
- grill-meSkill
- guard-src-drift-apiSkill
- guard-src-drift-commandsSkill
- guard-src-drift-ingestionSkill
- guard-src-drift-outputSkill
- guard-src-drift-signalsSkill
- guard-src-driftSkill
- improve-codebase-architectureSkill
- prd-to-issuesSkill
- self-improving-agentSkill
- simplify-and-hardenSkill
- skill-creatorSkill
- subagent-driven-developmentSkill
- systematic-debuggingSkill
- tddSkill
- verification-before-completionSkill
- workspace-automation-orchestratorSkill
- write-a-prdSkill
- writing-plansSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
14 rules. 13 are common, 1 is distinctive, and 0 are very specific to this project.
13
Common
Most of the 178 edited versions we read keep these.
1
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Common: line 11
Write the test first. Watch it fail.
- Common: line 13
Core principle: If you didn't watch the test fail, you don't know if it tests the right thing.
- Common: line 38
Write code before the test?
- Common: line 41
Don't keep it as "reference"
- Common: line 42
Don't "adapt" it while writing tests
- Common: line 43
Don't look at it
- Common: line 52
Write one minimal test showing what should happen.
- Common: line 68
Test fails (not errors)
- Common: line 78
Write simplest code to pass the test.
- Common: line 80
Don't add features, refactor other code, or "improve" beyond the test.
- Common: line 106
Keep tests green. Don't add behavior.
- Common: line 172
Before marking work complete:
- Common: line 198
Never fix bugs without a test.
- Distinctive: line 207
No exceptions without your human partner's permission.
“Common” is measured: kept by at least 6 in 10 of the 178 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Test-Driven Development (TDD)
Overview
Write the test first. Watch it fail. Write minimal code to pass.
Core principle: If you didn't watch the test fail, you don't know if it tests the right thing.
Violating the letter of the rules is violating the spirit of the rules.
When to Use
Always:
- New features
- Bug fixes
- Refactoring
- Behavior changes
Exceptions (ask your human partner):
- Throwaway prototypes
- Generated code
- Configuration files
Thinking "skip TDD just this once"? Stop. That's rationalization.
The Iron Law
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRSTWrite code before the test? Delete it. Start over.
No exceptions:
- Don't keep it as "reference"
- Don't "adapt" it while writing tests
- Don't look at it
- Delete means delete
Implement fresh from tests. Period.
Red-Green-Refactor
RED - Write Failing Test
Write one minimal test showing what should happen.
Requirements:
- One behavior
- Clear name
- Real code (no mocks unless unavoidable)
Verify RED - Watch It Fail
MANDATORY. Never skip.
pytest tests/path/test.py::test_name -vConfirm:
- Test fails (not errors)
- Failure message is expected
- Fails because feature missing (not typos)
Test passes? You're testing existing behavior. Fix test.
Test errors? Fix error, re-run until it fails correctly.
GREEN - Minimal Code
Write simplest code to pass the test.
Don't add features, refactor other code, or "improve" beyond the test.
Verify GREEN - Watch It Pass
MANDATORY.
pytest tests/path/test.py::test_name -vConfirm:
- Test passes
- Other tests still pass
- Output pristine (no errors, warnings)
Test fails? Fix code, not test.
Other tests fail? Fix now.
REFACTOR - Clean Up
After green only:
- Remove duplication
- Improve names
- Extract helpers
Keep tests green. Don't add behavior.
Repeat
Next failing test for next feature.
Good Tests
| Quality | Good | Bad |
| Minimal | One thing. "and" in name? Split it. | test('validates email and domain and whitespace') |
| Clear | Name describes behavior | test('test1') |
| Shows intent | Demonstrates desired API | Obscures what code should do |
Red Flags - STOP and Start Over
- Code before test
- Test after implementation
- Test passes immediately
- Can't explain why test failed
- Tests added "later"
- Rationalizing "just this once"
- "I already manually tested it"
- "Tests after achieve the same purpose"
- "Keep as reference" or "adapt existing code"
- "Already spent X hours, deleting is wasteful"
- "TDD is dogmatic, I'm being pragmatic"
- "This is different because..."
All of these mean: Delete code. Start over with TDD.
Example: Bug Fix
Bug: Empty email accepted
RED
def test_rejects_empty_email():
result = submit_form(email='')
assert result['error'] == 'Email required'Verify RED
$ pytest tests/test_form.py::test_rejects_empty_email -v
FAIL: assert None == 'Email required'GREEN
def submit_form(email):
if not email or not email.strip():
return {'error': 'Email required'}
# ...Verify GREEN
$ pytest tests/test_form.py::test_rejects_empty_email -v
PASSREFACTOR: Extract validation for multiple fields if needed.
Verification Checklist
Before marking work complete:
- Every new function/method has a test
- Watched each test fail before implementing
- Each test failed for expected reason (feature missing, not typo)
- Wrote minimal code to pass each test
- All tests pass
- Output pristine (no errors, warnings)
- Tests use real code (mocks only if unavoidable)
- Edge cases and errors covered
Can't check all boxes? You skipped TDD. Start over.
When Stuck
| Problem | Solution |
| Don't know how to test | Write wished-for API. Write assertion first. Ask your human partner. |
| Test too complicated | Design too complicated. Simplify interface. |
| Must mock everything | Code too coupled. Use dependency injection. |
| Test setup huge | Extract helpers. Still complex? Simplify design. |
Debugging Integration
Bug found? Write failing test reproducing it. Follow TDD cycle. Test proves fix and prevents regression.
Never fix bugs without a test.
Final Rule
Production code → test exists and failed first
Otherwise → not TDDNo exceptions without your human partner's permission.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

