home / skills / anthonylee991 / gemini-superpowers-antigravity / superpowers-tdd

superpowers-tdd skill

safe

This skill enforces test-first TDD discipline for features, bugs, and refactors, adding regression tests and guiding minimal changes.

npx playbooks add skill anthonylee991/gemini-superpowers-antigravity --skill superpowers-tdd

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

1.0 KB

---
name: superpowers-tdd
description: Applies tests-first discipline (red/green/refactor) and adds regression tests for bugs. Use when implementing features, fixing bugs, or refactoring.
---

# TDD Skill

## When to use this skill
- new features that can be unit tested
- bug fixes (always add a regression test if practical)
- refactors (protect behavior with tests first)

## Rules
- Prefer **red -> green -> refactor**.
- If tests are hard, still add **verification**: minimal repro script, integration test, or clear manual steps.
- Keep tests focused: one behavior per test where possible.
- Name tests by behavior, not implementation details.

## Process
1. Define the behavior change (what should be true after).
2. Write/adjust a test to capture it (make it fail first if possible).
3. Implement the minimal change to pass.
4. Refactor if needed (keep passing).
5. Run the relevant test suite + any linters.

## Output requirements
When you change code, include:
- what tests you added/changed
- how to run them
- what they prove

Overview

This skill enforces a tests-first discipline (red → green → refactor) for Python projects to reduce regressions and make change safer. I guide you to add focused unit tests or minimal verification when full tests are impractical. The goal is predictable, test-protected changes when implementing features, fixing bugs, or refactoring.

How this skill works

I inspect the target change and recommend a concrete test or verification that captures the desired behavior before implementing code. I prioritize small, behavior-driven tests that fail first, then show the minimal implementation to pass them, followed by refactoring while keeping tests green. When unit tests are impossible, I suggest reproducible verification scripts, integration checks, or manual reproduction steps.

When to use it

Implementing a new feature that can be covered by unit tests
Fixing a bug — add a regression test whenever practical
Refactoring code to preserve behavior with tests first
When preparing critical code paths for deployment
When introducing logic that could break existing behavior

Best practices

Follow red → green → refactor for every change
Keep tests focused: one behavior per test and behavioral names
If unit tests are hard, provide a minimal verification script or integration test
Document what tests were added/changed, how to run them, and exactly what they prove
Run the relevant test subset and linters as part of your change validation

Example use cases

Add a unit test that reproduces a reported bug, implement the fix, and keep the test as a regression guard
Write a failing unit test for a new API response shape, implement minimal code to pass, then refactor for clarity
Refactor a legacy module: write tests covering current behavior, refactor with confidence, remove no tests without replacement
Create a small script that reproduces an intermittent integration failure when unit tests cannot simulate the environment
Add end-to-end checks for a critical workflow and include them in CI as smoke tests

FAQ

What if I can’t write a unit test for the change?

Provide the smallest possible verification: a reproducible script, integration test, or clear manual steps that demonstrate the intended behavior before and after the change.

How should I name tests?

Name tests by the observable behavior or expected outcome, not by internal implementation details.

What must I include when submitting a code change?

List which tests were added or modified, how to run those tests locally, and a brief statement of what the tests prove about the change.