test-driven-development
Skill8 starsChanged 3 months agoApache-2.0View on GitHub
Use when implementing any feature or bugfix, before writing implementation code
We split this skill into the rules it gives an agent
16 rules. 5 are common, 11 are distinctive, and 0 are very specific to this project.
5
Common
Most of the 170 edited versions we read keep these.
11
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 10
Write the test first. Watch it fail.
- Common: line 12
Core principle: If you didn't watch the test fail, you don't know if it tests the right thing.
- Distinctive: line 37
Write code before the test?
- Distinctive: line 40
Don't keep it as "reference"
- Distinctive: line 41
Don't "adapt" it while writing tests
- Distinctive: line 42
Don't look at it
- Distinctive: line 73
Write one minimal test showing what should happen.
- Common: line 122
Test fails (not errors)
- Distinctive: line 132
Write simplest code to pass the test.
- Common: line 166
Don't add features, refactor other code, or "improve" beyond the test.
- Distinctive: line 192
Keep tests green. Don't add behavior.
- Distinctive: line 206
When writing or changing any test, read writing-good-tests.md for the rules that keep tests honest:
- Distinctive: line 209
Keep test-only code in test utilities, out of production classes
- Common: line 285
Before marking work complete:
- Distinctive: line 311
Never fix bugs without a test.
- Distinctive: line 320
No exceptions without your human partner's permission.
“Common” is measured: kept by at least 6 in 10 of the 170 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
digraph tdd_cycle {
rankdir=LR;
red [label="RED\nWrite failing test", shape=box, style=filled, fillcolor="#ffcccc"];
verify_red [label="Verify fails\ncorrectly", shape=diamond];
green [label="GREEN\nMinimal code", shape=box, style=filled, fillcolor="#ccffcc"];
verify_green [label="Verify passes\nAll green", shape=diamond];
refactor [label="REFACTOR\nClean up", shape=box, style=filled, fillcolor="#ccccff"];
next [label="Next", shape=ellipse];
red -> verify_red;
verify_red -> green [label="yes"];
verify_red -> red [label="wrong\nfailure"];
green -> verify_green;
verify_green -> refactor [label="yes"];
verify_green -> green [label="no"];
refactor -> verify_green [label="stay\ngreen"];
verify_green -> next;
next -> red;
}RED - Write Failing Test
Write one minimal test showing what should happen.
<Good>
```typescript
test('retries failed operations 3 times', async () => {
let attempts = 0;
const operation = () => {
attempts++;
if (attempts < 3) throw new Error('fail');
return 'success';
};const result = await retryOperation(operation);
expect(result).toBe('success'); expect(attempts).toBe(3); });
Clear name, tests real behavior, one thing
</Good>
<Bad>
```typescript
test('retry works', async () => {
const mock = jest.fn()
.mockRejectedValueOnce(new Error())
.mockRejectedValueOnce(new Error())
.mockResolvedValueOnce('success');
await retryOperation(mock);
expect(mock).toHaveBeenCalledTimes(3);
});Vague name, tests mock not code
</Bad>
Requirements:
- One behavior
- Clear name
- Real code (no mocks unless unavoidable)
Verify RED - Watch It Fail
MANDATORY. Never skip.
npm test path/to/test.test.tsConfirm:
- 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.
<Good>
```typescript
async function retryOperation<T>(fn: () => Promise<T>): Promise<T> {
for (let i = 0; i < 3; i++) {
try {
return await fn();
} catch (e) {
if (i === 2) throw e;
}
}
throw new Error('unreachable');
}
```
Just enough to pass
</Good><Bad>
```typescript
async function retryOperation<T>(
fn: () => Promise<T>,
options?: {
maxRetries?: number;
backoff?: 'linear' | 'exponential';
onRetry?: (attempt: number) => void;
}
): Promise<T> {
// YAGNI
}
```
Over-engineered
</Bad>Don't add features, refactor other code, or "improve" beyond the test.
Verify GREEN - Watch It Pass
MANDATORY.
npm test path/to/test.test.tsConfirm:
- 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 |
When writing or changing any test, read writing-good-tests.md for the rules that keep tests honest:
- Name the production change that would make the test fail — before writing it
- Assert on real behavior, never on mock behavior
- Keep test-only code in test utilities, out of production classes
- Understand a dependency's side effects before mocking it
Common Rationalizations
| Excuse | Reality |
| "Too simple to test" | Simple code breaks. Test takes 30 seconds. |
| "I'll test after" | Tests written after pass immediately — which proves nothing. They may test the wrong thing, test the implementation instead of the behavior, or miss the edge case you forgot. You never watched it fail, so you never proved it can catch the bug. Test-first forces that failure. |
| "Tests after achieve same goals (spirit not ritual)" | Tests-after answer "what does this do?"; tests-first answer "what should this do?" Tests written after are biased by the code you already wrote — you verify the cases you remembered, not the ones you'd have discovered. Coverage without proof the tests work. |
| "Already manually tested" | Manual testing is ad-hoc: no record of what you covered, no way to re-run it when the code changes, easy to forget cases under pressure. "Worked when I tried it" ≠ comprehensive. Automated tests run the same way every time. |
| "Deleting X hours is wasteful" | Sunk cost fallacy — that time is already spent either way. The real choice: rewrite with TDD (high confidence) vs. keep it and bolt tests on after (low confidence, likely bugs). Keeping code you can't trust is the waste. |
| "Keep as reference, write tests first" | You'll adapt it. That's testing after. Delete means delete. |
| "Need to explore first" | Fine. Throw away exploration, start with TDD. |
| "Test hard = design unclear" | Listen to test. Hard to test = hard to use. |
| "TDD will slow me down" | TDD IS the pragmatic path: catches bugs before commit, prevents regressions, lets you refactor without fear. "Pragmatic" shortcuts mean debugging in production — slower, not faster. |
| "Manual test faster" | Manual doesn't prove edge cases. You'll re-test every change. |
| "Existing code has no tests" | You're improving it. Add tests for existing code. |
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"
- "It's about spirit not ritual"
- "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
test('rejects empty email', async () => {
const result = await submitForm({ email: '' });
expect(result.error).toBe('Email required');
});Verify RED
$ npm test
FAIL: expected 'Email required', got undefinedGREEN
function submitForm(data: FormData) {
if (!data.email?.trim()) {
return { error: 'Email required' };
}
// ...
}Verify GREEN
$ npm test
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.
Other versions205 projects use a version of this.
Word for word · 24
- openai/plugins★ 7.4k100% same
- karim1556/skills★ 38100% same
- AkashPriyadarshii/jev-superpowers★ 37100% same
- Hassaan146/claude-skills★ 18100% same
- codeAnqiang-ma/dsh-superpowers★ 9100% same
- yonyong/Janus★ 4100% same
- OutlitAI/skills★ 3100% same
- fhmio/augment★ 2100% same
- idexal/idexal-skills★ 2100% same
- 0xrizz/os-manager★ 1100% same
14 more not listed
Edited · 118
- obra/superpowers★ 305k92% same
- NousResearch/hermes-agent★ 259k33% same
- jnMetaCode/superpowers-zh★ 8.4k25% same
- farm-fe/farm★ 5.6k73% same
- microsoft/FluidFramework★ 5k38% same
- GanyuanRan/Aegis★ 1.4k17% same
- pcvelz/superpowers★ 1.3k92% same
- math-inc/OpenGauss★ 1.3k36% same
- coco-research/coco★ 79772% same
- bolshakov/stoplight★ 62972% same
108 more not listed
Wrote their own version · 63
- addyosmani/agent-skills★ 112ksame name
- cloudflare/computer★ 9.8ksame name
- mikeyobrien/ralph-orchestrator★ 3.2ksame name
- crbnos/carbon★ 2.8ksame name
- ollaya-dev/ollaya★ 1.4ksame name
- rizqinrr/viserys-agent★ 560same name
- taichuy/1flowbase★ 285same name
- KbWen/agentic-os★ 224same name
- DevelopersGlobal/ai-agent-skills★ 216same name
- intent-driven-dev/intent-driven-template★ 185same name
53 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.
Used alongsideProjects 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.
GEd520Skillchinese-code-review
中文 review 沟通参考——话术模板、分级标注(必须修复/建议修改/仅供参考)、国内团队常见反模式应对。仅在用户显式 /chinese-code-review 时调用,不要根据上下文自动触发。
Also in 7 projects that use this
GEd520Skillchinese-commit-conventions
中文 commit 与 changelog 配置参考——Conventional Commits 中文适配、commitlint/husky/commitizen 中文模板、conventional-changelog 中文配置。仅在用户显式 /chinese-commit-conventions 时调用,不要根据上下文自动触发。
Also in 7 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 13 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 40 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
10CGSkillworkflow-runner
十步循环轻量编排器,协调 Phase Skills 执行,支持灵活组合。
Also in 8 projects that use this
- +2 more from GEd520
- +2 more from LLl0k0laD
In this repository49 other files it gives its agents.
- a-b-testingSkill
- api-devSkill
- article-extractorSkill
- audio-genSkill
- blog-writerSkill
- brainstormingSkill
- brand-guidelinesSkill
- canvas-designSkill
- changelog-generatorSkill
- code-refactorerSkill
- competitive-ads-extractorSkill
- content-research-writerSkill
- database-managerSkill
- docker-deploySkill
- docxSkill
- domain-name-brainstormerSkill
- email-campaignsSkill
- finishing-a-development-branchSkill
- game-devSkill
- git-pushingSkill
- git-workflowSkill
- godot-helperSkill
- image-enhancerSkill
- ios-simulator-skillSkill
- langsmith-fetchSkill
- lead-research-assistantSkill
- lean-ctxSkill
- mcp-builderSkill
- meeting-insights-analyzerSkill
- pdfSkill
- playwright-skillSkill
- pptxSkill
- react-nextjs-builderSkill
- review-implementingSkill
- seo-optimizerSkill
- ship-learn-nextSkill
- skill-creatorSkill
- skill-builderSkill
- social-media-managerSkill
- staff-engineer-reviewSkill
- tailored-resume-generatorSkill
- test-fixingSkill
- twitter-algorithm-optimizerSkill
- using-git-worktreesSkill
- video-framesSkill
- webapp-testingSkill
- xlsxSkill
- youtube-transcriptSkill
- your-skill-nameSkill
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.

