Agent skill · software engineering · cursor
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.
Why this skill is useful
Provides a structured approach to TDD for bug fixing, including specific regression test strategies and practical alternatives when tests are impractical.
What it needs
About 2k tokens when loaded. Last updated 2026-08-06. 2,555 stars on the source repository.
What this skill does
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 setup, 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 1. Understand the bug. Identify the intended behavior, current behavior, affected path, and smallest observable reproduction. 2. 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. 3. Write the failing test first. Add the smallest focused test that would have caught the bug. The test should encode intended behavior, not mirror the current implementation. 4. Run the new test before fixing. Confirm it fails for the intended reason. If it passes or fails for an unrelated reason, correct the test or reproduction before editing the implementation. 5. Fix the bug. Make the smallest production change that satisfies the intended behavior while preserving nearby contracts. 6. Rerun the regression test. 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 is one that mostly tests mocks, encodes current implementation details, depends on timing or unrelated global state, needs expensive infrastructure for a small fix, or would be deleted immediately after proving the fix. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills cursor/tdd