test-driven-development
Use when implementing any feature or bugfix, before writing implementation code
Install
git clone https://github.com/obra/superpowers /tmp/superpowers && ln -s /tmp/superpowers/skills/test-driven-development ~/.claude/skills/test-driven-developmentFrom README
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 Write 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.
More from this repo
systematic-debugging
Used when encountering any bug, test failure, or unexpected behavior, before proposing fixes
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying...
dispatching-parallel-agents
Used when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies