tdd
Use only when the user explicitly asks for TDD, a failing test, or a regression test, OR when the bug has an obvious cheap local test target. Skip when the test path is unclear, expensive, integration-heavy, or not requested.
Install
git clone https://github.com/cursor/plugins /tmp/plugins && ln -s /tmp/plugins/pstack/skills/tdd ~/.claude/skills/tddFrom README
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. If the available test would require broad harness , brittle mocks, slow end-to-end infrastructure, production-only state, vague reproduction steps, or large unrelated fixture churn, skip adding a new test and use the closest useful verification instead. Workflow Understand the bug. Identify the intended behavior, current behavior, affected path, and smallest observable reproduction. Choose the narrowest executable check. Prefer the closest unit, component, integration, or regression test already used for that codepath. If no practical test path is obvious, do not create one from scratch just to satisfy the workflow. Write the failing test first. Add the smallest focused test that would have caught the bug.