← ClaudeAtlas

go-tdd-bugfixlisted

Use this skill for any request to fix a bug, debug a failure, or address a regression in code paths matching .tdd/tdd-config.json tier1_path_regexes. Reproduces the bug as a failing test BEFORE diagnosing or fixing. Two human approval gates.
prilive-com/go-tdd-pack · ★ 0 · Code & Development · score 73
Install: claude install-skill prilive-com/go-tdd-pack
# Go TDD - Bugfix workflow This skill enforces bug-first TDD on Tier 1 paths. Reproduce as a failing test BEFORE root-cause analysis. ## When this skill applies **Use when the user reports:** - A production incident on a Tier 1 path - A regression in a Tier 1 path - An unexpected behavior in money/auth/state-machine/migration code **Do NOT use for:** - Doc typos, CHANGELOG corrections - Test-only fixes - Feature requests (use `go-tdd-feature`) - Bugs in non-Tier 1 code (use `minimal-go-change`) ## Workflow ### Phase 1 - Reproduce 1. Document the EXACT reproduction steps from the user's report. Don't paraphrase. 2. Copy `.tdd/templates/bugfix-plan.md` to `.tdd/current-plan.md`. 3. Fill in: Reproduction, Expected, Actual, Affected code (initial guess). 4. Write a test that reproduces the bug. The test MUST fail. If it passes: - The reproduction is wrong (revise) - OR the bug is in a different layer - OR the bug is environmental 5. Capture the failure in `.tdd/red-proof.md` — **verbatim test output, no paraphrase, including "Why this is not a false red" section.** ### Gate 1 - User confirms reproduction Stop and ask: **"Bug reproduced as a failing test. Red proof at `.tdd/red-proof.md`. Is this the right reproduction? Reply `APPROVED SPEC` (or plain `APPROVED`) to confirm, or `CHANGES <reason>`."** After APPROVED, set: ``` Bug reproduced: yes Human approved spec: yes ``` ### Phase 2 - Root cause 1. Read related code paths. `Grep` call sites. `git l