tdd

Writes a failing regression test before fixing a bug with a clear test path.

3|2|Updated Aug 28, 2026
One-click install
npx skills add https://github.com/adjohn/pstack --skill tdd-adjohn
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: tdd
Source: https://github.com/adjohn/pstack/tree/main/skills/tdd
Command: npx skills add https://github.com/adjohn/pstack --skill tdd-adjohn

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Bug fixes often ship without proof that the bug is actually fixed, letting the same regression return later. This Skill enforces a test-driven bug-fixing workflow: reproduce the bug as a failing test first, then make the smallest production change that turns it green. ## Core Features & Use Cases - Failing-Test-First Workflow: Guides a seven-step process from understanding the bug through writing the failing test, fixing the code, and rerunning validation. - Pragmatic Fallbacks: When a failing test is impractical (expensive harness, brittle mocks, production-only state), it mandates an explicit explanation and the closest executable regression check instead of silently skipping verification. - Guardrails Against Bad Tests: Prevents weakening assertions, mirroring broken implementations, or adding low-signal tests that mostly exercise mocks. - Use Case: A user reports that a date parser returns the wrong day for leap years. The Skill writes a focused unit test that fails on the leap-year input, fixes the parser, and confirms the test passes along with adjacent suite checks. ## Quick Start Ask the assistant to fix this bug using TDD by first writing a failing regression test that reproduces the issue.

Frequently Asked Questions about tdd

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I fix a bug using test-driven development?▼

Write the smallest test that reproduces the bug and confirm it fails for the intended reason, then make the minimal production change until it passes. Finish by running adjacent tests, type checks, or lint to catch broader risk.

When should I write a regression test for a bug fix?▼

Write one when the bug has a clear, cheap test target such as an existing unit or integration test for that codepath. Skip it when the test would need broad harness setup, brittle mocks, or slow end-to-end infrastructure.

What should I do if a failing test is impractical to write?▼

Explicitly state why the failing test is not worth the cost, then use the closest executable regression check such as a targeted script, manual reproduction command, log assertion, or snapshot comparison. Never silently skip the verification step.

Why is it bad to change a test to match the current implementation?▼

Matching a test to a wrong implementation locks in the bug instead of the intended behavior. Tests should encode expected behavior, and existing assertions should only be weakened when the expected behavior has genuinely changed.

What makes a regression test a bad test?▼

A bad test mostly exercises mocks, mirrors implementation details, depends on timing or global state, or needs expensive infrastructure for a small fix. Prefer no new test over one that would be deleted immediately after proving the fix.