Menu

Individual skill

ds-tdd

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.

skills/ds-tdd/SKILL.md

Read pinned source

Source commit d4f1ebe72e8314c3a0c6135bb82f623c650f7218

What was checked

Matches the observed repository HEAD
Yes
Scanner rules are current
Yes
Repository scan complete
No
Skill scan complete
Yes
Observed behavior
Instructions only
Last checked
Nov 5, 2026

These are observations at the recorded commit, not a guarantee of safety. Review the source before running it.

Install this skill

Choose an agent in your Stack or copy a command below. Commands fetch the pinned commit and copy only this skill directory. Existing destinations are refused. Copying a command does not install anything.

An install command is unavailable: current rules, complete repository and skill scans, an eligible behavior level and a permitted license are required.

Repository context

Repository stars (not skill ratings)
221
Repository last updated
Oct 28, 2026
License
MIT

Observed agent integration: No specific integration evidence. Standard SKILL.md installation does not imply verified compatibility.

Files and excerpt

File metadata and permitted, redacted excerpts come from the recorded scan. Source links are pinned to that commit.

Browse files
Read excerpt

# ds-tdd

Make the bug executable before touching production code, so the fix is proven, not claimed.

## Steps

1. Pin down the bug: expected behavior, actual behavior, the code path, and the smallest way to reproduce it.
2. Find the nearest existing test style for that code path. Use it. Do not build a new harness just for this.
3. Write the smallest test that would have caught the bug. It checks intended behavior, not the current implementation.
4. 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.
5. Make the smallest production change that gives the intended behavior without breaking nearby contracts.
6. Run the new test and the surrounding suite. Show the output.
7. 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.