What does this skill do, and when should you use it?
This is the test-driven-development skill inside the Superpowers repository, and it requires tests before production code. It enforces a Red-Green-Refactor loop: verify that a test fails for the expected reason, write the minimum code needed to pass, then refactor while keeping the tests green. It applies to new features, bug fixes, refactoring, and behavior changes; throwaway prototypes, generated code, and configuration files require approval from a human partner. It fits developers who want explicit behavior records, regression protection, and safer refactoring.
It instructs the developer to write one minimal test for a concrete behavior, using real code rather than mocks unless unavoidable; run the test and confirm that it fails because the feature is missing; write the simplest production code that passes; rerun the test suite and confirm that the output is clean and other tests still pass; then refactor without adding behavior and repeat for the next behavior. It also supplies test-quality criteria, rationalization counters, restart conditions, a completion checklist, and a regression-testing workflow for debugging.
- A developer is implementing a new feature and wants the expected behavior defined before implementation.
- A maintainer is fixing a bug and needs a failing reproduction that prevents regression.
- A team is refactoring existing code and wants tests to verify that behavior remains unchanged.
- A developer is improving legacy code with little coverage and needs to add tests around existing behavior.
- A team frequently relies on manual checks or postpones testing and needs a stricter implementation workflow.
How do you install this skill?
- Before applying the “delete code written before tests” rule, confirm version control, backups, and a recoverable workspace to avoid deleting existing user work.
- npm test is only an example; verify the project’s test framework, dependencies, and test-path syntax first.
- For legacy systems, rapid prototypes, and configuration changes, do not apply the no-exceptions rule mechanically; obtain user confirmation and record the rationale for deviations.
- Shell / CLI
- Local filesystem
No standalone installation procedure is documented for this skill; it is located at skills/test-driven-development/ in obra/superpowers. The README says Superpowers is a collection of 14 skills and should be installed separately for each coding-agent harness. For example, Claude Code supports /plugin install superpowers@claude-plugins-official; Codex CLI supports /plugins, searching for superpowers, and selecting Install Plugin. Other harness instructions are provided in the repository README.
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/obra/superpowers.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/skills/test-driven-development" ~/.claude/skills/
rm -rf "$tmp"Generated from the source repository and skill path; it copies only this skill's folder. If the author's install steps above differ, follow those first. To scope it to one project, replace ~/.claude/skills with that project's .claude/skills.
How do you use this skill?
Once installed, send your agent any of these to trigger it:
- Use test-driven-development: write a failing test for this behavior, run it to verify the failure, then implement the minimum code and verify it passes.
Trigger it before implementing a feature, fixing a bug, refactoring, or changing behavior. Example prompt: “Use test-driven-development: write a failing test for this behavior, run it to verify the failure, then implement the minimum code and verify it passes.” The example test command is: npm test path/to/test.test.ts. Ask the human partner before treating a throwaway prototype, generated code, or configuration file as an exception.
What are this skill's strengths and limitations?
- Requires observing the expected failure, helping prove that the test detects missing behavior.
- Constrains implementation to the minimum needed and supports later refactoring.
- Covers common development work including features, fixes, refactors, and behavior changes.
- Includes completion checks, a debugging regression workflow, and testing anti-pattern guidance.
- The rules are strict and normally reject writing production code before the test.
- The listed exceptions require approval from a human partner.
- The example uses npm test, but the skill does not define a project-specific test framework or command.
- The skill has no documented standalone installation flow and is installed through Superpowers.
How does this skill compare with similar options?
Side by side with related skills; every score comes from the same FSRS standard.
| Skill | FS score | Stars | Last updated | License |
|---|---|---|---|---|
| Test-Driven Development this page | 52 · Use with care | ★ 299k | 15d ago | MIT |
| Test-Driven Development Workflow | 57 · Use with care | ★ 107k | 12d ago | MIT |
| TDD Guard | 61 · Recommended | ★ 2.4k | 13d ago | MIT |
| Test-Driven Skill Authoring | 44 · Not recommended | ★ 299k | 15d ago | MIT |
| RenderCV Testing Context | 61 · Recommended | ★ 18k | 7mo ago | MIT |
Compared with writing tests after implementation, this skill uses tests first to answer “what should this do?” and uses the observed failure as evidence that the test is meaningful. Compared with manual testing, it emphasizes repeatability, recorded behavior, and regression detection.
How did FollowSkills review this skill?
The skill scopes itself to a development workflow and requires asking the human partner for exceptions; there is no evidence of credential theft, covert exfiltration, or malicious external actions. Deductions apply because the “delete code written before tests” rule is potentially destructive without backup, rollback, or workspace-boundary guidance. Sensitive-data handling, dependency security, and data-flow disclosure are absent, and publisher identity is unverified by FollowSkills.
The document is coherent and gives a detailed RED-GREEN-REFACTOR process, failure branches, and a testing anti-pattern reference. Deductions apply because test framework, installation prerequisites, cross-project command adaptation, and diagnostics for unavailable commands are unspecified; the example also has a minor consistency issue between a synchronous operation and a Promise-typed function. Static calibration caps this at 10.
Invocation is clear for new features, bug fixes, refactoring, and behavior changes, with exceptions for prototypes, generated code, and configuration files. Deductions apply because the “always” and “no exceptions” language is dogmatic, boundaries for legacy code and non-test tasks are underdeveloped, and there is no Chinese-language support guidance. Core function does not depend on overseas services.
The skill provides clear headings, progressive workflow, examples, a checklist, an anti-pattern reference, and troubleshooting guidance; repository context supplies an MIT license, version, maintainer, update path, and contribution process. Deductions apply because the skill itself lacks versioning, changelog, dependency-install notes, and an explicit maintenance owner, while reachability of the referenced file is only indirectly supported by the supplied materials.
The skill gives a directly usable TDD cycle, test-quality criteria, failure verification, and completion checklist, with a clear goal of reducing omissions and regressions. Deductions apply because no execution evidence for this skill is provided, the strict deletion rule can impose unnecessary cost, and alternatives for rapid prototypes or legacy systems are not compared. Static calibration caps this at 7.
Concrete commands, code examples, checklists, and sample failure output make the guidance partly auditable. The repository also claims behavioral and CI tests exist, but the supplied evidence does not show actual results or committed coverage of this skill’s key paths. Static calibration caps this at 5.
Open a dimension to read why it scored that way
Evidence confidence：Low — Mostly static review, author material or a limited demo; useful for discovery, not high-risk decisions.
See the full review method →