---
name: tdd
description: "Make a bug executable with a failing regression test before changing production code. Use when the user explicitly asks for TDD, a failing test, or a regression test, OR when a bug has an obvious cheap local test target. Skip when the test path is unclear, expensive, integration-heavy, or not requested."
license: MIT
metadata:
  adapted-from: "cursor/plugins/pstack/skills/tdd"
  version: "1.0.0"
---

# TDD Bug Fix

When fixing a bug with a clear, cheap test path, make the broken behavior executable before changing production code. The goal is a focused regression test that fails before the fix and passes after it. Do not force a test when it would be impractical.

## Workflow
1. **Understand the bug.** Identify intended behavior, current behavior, the affected path, and the smallest observable reproduction.
2. **Choose the narrowest executable check.** Prefer the closest existing unit/component/integration/regression test for that codepath. If no practical path is obvious, do not invent one just to satisfy the workflow.
3. **Write the failing test first.** The smallest focused test that would have caught the bug. Encode intended behavior, not the current implementation.
4. **Run it before fixing.** Confirm it fails for the intended reason. If it passes or fails for an unrelated reason, fix the test or reproduction first.
5. **Fix the bug.** Smallest production change that satisfies the intended behavior while preserving nearby contracts.
6. **Rerun.** Confirm the test now passes.

## If a failing test is impractical
Use the closest executable regression check instead: a targeted script, manual reproduction command, browser automation, snapshot comparison, log assertion, or focused integration check. Prefer no new test over a bad test. A bad test mostly tests mocks, encodes implementation details, depends on timing or unrelated global state, needs expensive infrastructure for a small fix, or would be deleted right after proving the fix.

## Guardrails
- Do not change tests merely to match a wrong implementation.
- Do not weaken existing assertions unless the expected behavior genuinely changed and the reason is clear.
- Keep the regression test focused on the bug; avoid broad fixture churn.
- If the bug is flaky, make the test deterministic where possible and document the signal being locked down.

## Final response
Name the failing-before test/check and the failure it produced, the passing-after run and any nearby validation, and — if failing-before evidence was impossible — why, plus the closest regression check used instead.