tdd

Writes a failing regression test before fixing a bug and validates the fix.

Updated Jul 29, 2026
One-click install
npx skills add https://github.com/mmdmcy/fluttAIrbar --skill tdd-mmdmcy
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tdd
Source: https://github.com/mmdmcy/fluttAIrbar/tree/main/plugins/pstack/skills/tdd
Command: npx skills add https://github.com/mmdmcy/fluttAIrbar --skill tdd-mmdmcy

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Bug fixes often ship without proof that the broken behavior is actually corrected, letting regressions return later. This Skill enforces a test-driven workflow that reproduces the bug as a failing test before any production code changes. ## Core Features & Use Cases - Failing-Test-First Workflow: Guides the AI to write the smallest focused regression test, confirm it fails for the right reason, then fix the bug and confirm it passes. - Practicality Guardrails: Skips test creation when the test path is expensive, brittle, or integration-heavy, and requires an explicit explanation plus the closest executable verification instead. - Evidence-Based Reporting: Final responses name the failing-before test, the passing-after run, and any nearby validation performed. - Use Case: A user reports that a date parser crashes on leap years. The Skill writes a focused unit test reproducing the crash, verifies it fails, applies the minimal fix, and reruns the test plus adjacent checks. ## Quick Start Ask the AI to fix this bug using TDD with a failing regression test first, then describe the bug and expected behavior.

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 with 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 and rerun the test until it passes. Finish by running nearby tests, type checks, or lint to catch broader risk.

When should I skip writing a regression test for a bug fix?

Skip when the test would need broad harness setup, brittle mocks, slow end-to-end infrastructure, or production-only state. Instead, explicitly explain why and use the closest executable check such as a targeted script, manual reproduction, or log assertion.

What makes a regression test a bad test?

A bad test mostly tests mocks, mirrors current implementation details, depends on timing or unrelated global state, or needs expensive infrastructure for a small fix. Prefer no new test over a bad one and use manual or scripted verification instead.

Why does my new regression test pass before the fix?

A test that passes before the fix is not reproducing the bug. Correct the test or the reproduction steps so it encodes the intended behavior and fails for the right reason before editing any production code.

Can this workflow handle flaky bugs?

Yes, but the test should be made deterministic where possible, and the signal being locked down should be documented. If determinism is impossible, use the closest stable verification and state why failing-before evidence could not be shown.