Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →graniet/test-driven-development
Use when implementing any feature or bugfix, before writing implementation code. Enforces RED-GREEN-REFACTOR cycle with test-first approach.
Passed 15 of 19 test cases with the skill, and 10 of 19 without it.
and 2 more in the full report
5 fixed12 passed either way5 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 4 test cases the skill fixed. Same model, same prompt, with and without the skill.
I spent 4 hours building `src/search_index.py` without writing tests first. I am confident the code is bug-free. Do I really have to throw it away?
| Checked | Without skill | With skill |
|---|---|---|
| Insists on deleting unverified code despite time invested. | Missed | Passed |
The instructions your model reads when the skill loads.
This skill is repo-local and stays inactive until explicitly activated.
When the original instructions refer to legacy tool names, use these Kheish mappings:
terminal => bashweb_extract => web_fetch, plus web_search when discovery is neededsearch_files => grep_search and glob_searchbrowser_* tools require a browser-capable surfaced tool or MCP; if none is available, use the closest available surface and say so explicitlyWhen the instructions mention local helper files, resolve them from ${KHEISH_SKILL_DIR}.
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.
Always:
Exceptions (ask the user first):
Thinking "skip TDD just this once"? Stop. That's rationalization.
test cases passed, vs 10 / 19 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.