From superpowers-plus
Enforces strict Test-Driven Development (TDD) for features and bugfixes: Red (write and verify failing test), Green (minimal code), Refactor cycle before any implementation.
npx claudepluginhub bordenet/superpowers-plus --plugin superpowers-plusThis skill uses the workspace's default tool permissions.
- Implementing any feature or bugfix — before writing implementation code
Mandates invoking relevant skills via tools before any response in coding sessions. Covers access, priorities, and adaptations for Claude Code, Copilot CLI, Gemini CLI.
Share bugs, ideas, or general feedback.
systematic-debugging), reviewing others' code (providing-code-review)Core principle: If you didn't watch the test fail, you don't know if it tests the right thing.
Wrong skill? Debugging existing failures →
systematic-debugging. Reviewing others' code →providing-code-review.
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
Write code before the test? Delete it. Start over. No exceptions.
Write one minimal test showing what should happen. One behavior, clear name, real code (no mocks unless unavoidable).
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);
});
Run test. Confirm it fails for the expected reason (feature missing, not typo). Test passes? You're testing existing behavior — fix test.
Write simplest code to pass. Don't add features, refactor, or "improve" beyond the test.
Run test. Confirm it passes. Other tests still pass. Output pristine.
After green only: remove duplication, improve names, extract helpers. Keep tests green. Don't add behavior.
Next failing test for next feature.
Before marking work complete:
Can't check all boxes? You skipped TDD. Start over.
| Problem | Solution |
|---|---|
| Don't know how to test | Write wished-for API. Write assertion first. |
| Test too complicated | Design too complicated. Simplify interface. |
| Must mock everything | Code too coupled. Use dependency injection. |
| Failure | Fix |
|---|---|
| Wrote implementation before test | Delete implementation, write failing test first |
| Test passed immediately (no RED phase) | Test is wrong — it's testing existing behavior, not new behavior |
| Must mock everything to test | Code is too coupled — refactor to use dependency injection |
When adding mocks or test utilities, read @testing-anti-patterns.md to avoid: testing mock behavior instead of real behavior, adding test-only methods to production classes.
debate — when test architecture decisions arise (≥3 approaches to test a complex feature)systematic-debugging — when tests fail for non-obvious reasons, switch to root-cause investigationverification-before-completion — after TDD cycle, verify ALL tests pass before claiming done