ds-tdd
Skill80 starsChanged 15 days agoMITView on GitHub
Fix a bug by first writing a focused test that fails for the right reason, then making the smallest change that makes it pass. Use when the user asks for TDD or a regression test, when a bug has a cheap local test target, or for /ds-tdd.
In this repository28 other files it gives its agents.
- ds-adoptSkill
- ds-best-of-nSkill
- ds-blast-radiusSkill
- ds-blueprintSkill
- ds-catchupSkill
- ds-context-resetSkill
- ds-design-auditSkill
- ds-designSkill
- ds-explainSkill
- ds-helpSkill
- ds-jurySkill
- ds-ledgerSkill
- ds-lessonsSkill
- ds-modeSkill
- ds-plan-loopSkill
- ds-pr-commentsSkill
- ds-principlesSkill
- ds-prSkill
- ds-readySkill
- ds-review-loopSkill
- ds-reviveSkill
- ds-sharpenSkill
- ds-shipSkill
- ds-swarmSkill
- ds-unslopSkill
- ds-unstickSkill
- ds-verify-loopSkill
- ds-watch-prSkill
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 7 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
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
- Distinctive: line 14
Write the smallest test that would have caught the bug.
- Distinctive: line 15
Run it. Show the output. It must fail, and fail for the bug, not for a typo or missing import.
- Distinctive: line 17
Run the new test and the surrounding suite.
- Distinctive: line 18
If a clean test is impractical (heavy setup, brittle mocks, production-only state), use the closest runnable check instead: a script, a …
- Distinctive: line 27
Never edit a test to match a wrong implementation.
- Distinctive: line 28
Do not weaken existing assertions without a clear, stated reason.
- Distinctive: line 29
No test beats a bad test: one that mostly tests mocks, depends on timing, or would be deleted right after.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
ds-tdd
Make the bug executable before touching production code, so the fix is proven, not claimed.
Steps
- Pin down the bug: expected behavior, actual behavior, the code path, and the smallest way to reproduce it.
- Find the nearest existing test style for that code path. Use it. Do not build a new harness just for this.
- Write the smallest test that would have caught the bug. It checks intended behavior, not the current implementation.
- Run it. Show the output. It must fail, and fail for the bug, not for a typo or missing import. If not, fix the test first.
- Make the smallest production change that gives the intended behavior without breaking nearby contracts.
- Run the new test and the surrounding suite. Show the output.
- If a clean test is impractical (heavy setup, brittle mocks, production-only state), use the closest runnable check instead: a script, a repro command or a log check. Say why you skipped the test.
Stop when
- The new test failed before the fix and passes after it, both shown with output, and the surrounding suite passes.
- Or after three fix attempts the test still fails. Stop, report what you learned and run /ds-unstick.
Rules
- Never edit a test to match a wrong implementation.
- Do not weaken existing assertions without a clear, stated reason.
- No test beats a bad test: one that mostly tests mocks, depends on timing, or would be deleted right after.
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.