Bugfix tdd

Skill bahadirkisbet/bardak/plugins/bardak/skills/bugfix-tdd

Discipline & quality skills for Claude Code and Codex: blind review, retrospective, architecture (less-is-more / more-is-less), no silent errors, verify the premise, pipeline verification, bugfix TDD, ADR.

Install

npx -y skills add bahadirkisbet/bardak --skill bugfix-tdd

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when fixing any bug, regression, or "it does the wrong thing" report. Not for net-new features (ordinary TDD) or pure behavior-preserving refactors.

SKILL.md

2.6 KB, as published. Nobody here has run it

Bugfix TDD

A bug fix without a failing test that reproduces it is a guess. Reproduce first — a red test that captures the bug — then fix until it is green. The test is the proof the bug existed and the guard that it stays fixed.

Announce at start: "Reproducing the bug with a failing test before fixing."

Iron Law

NO BUG FIX WITHOUT A TEST THAT REPRODUCES THE BUG AND FAILS FIRST.

When to Use

Any bug, regression, or "it does the wrong thing" report.
Not for: net-new features (that's ordinary TDD), pure refactors with behavior unchanged.

Step 1: Reproduce with a Failing Test

Write the smallest test that exercises the buggy path and asserts the correct behavior. Run it. It MUST fail.

If you can't write a test that fails, you don't yet understand the bug. Keep investigating; don't fix blind.

Step 2: Confirm the Failure Is the Bug

Read the failure. Is it failing because of the actual bug, or because the test is wrong? A test that fails for the wrong reason proves nothing — fix the test until it fails for the bug's reason.

Step 3: Fix

Make the minimal change that turns the test green. Don't expand scope; don't fix unrelated things in the same step.

Step 4: Confirm Green + No Regressions

The new test passes.
The surrounding suite still passes — the fix didn't break a neighbor.
Re-read the diff: did you fix the cause, or paper over the symptom just enough to make the test pass?

Red Flags — STOP

Thought	Reality
"I see the bug — I'll just fix it"	Then you have no proof it was the bug, or that it stays fixed. Red test first.
"I'll add the test after the fix"	After means never, and a test written green never proves it catches the bug.
"It's too hard to write a test for this"	Then you don't understand the bug yet. Keep digging.
"The fix is obvious"	Obvious fixes paper over symptoms. The failing test keeps you honest.

Common Mistakes

Fixing first, adding a test after (or never) — you lose the proof the test catches the bug.
A test that passes even before the fix — it doesn't exercise the bug.
A test that fails for the wrong reason — verify the failure mode first.
Expanding the fix beyond what the test demands.
Skipping the full-suite run — confirm the fix didn't regress a neighbor.

Required next: bardak:no-silent-errors (don't let the fix add a silent failure) and bardak:pipeline-verification (verify the fix end to end, not just the new unit test).

Gives 1 of the 12 instructions most tdd skills give

Counted across 439 of the 443 authors here whose files we hold, read 2026-08-06

write minimal code to pass the testin 302 of 439, across 218 files
write a failing test firstin 176 of 439, across 112 files
refactor code only after tests passin 171 of 439, across 101 files
watch the test fail before writing codein 142 of 439, across 93 files
test one behavior per testin 106 of 439, across 44 files
refactor code while keeping tests greenin 99 of 439, across 86 files
delete code written before testsin 98 of 439, across 54 files
run tests after each refactor stepin 85 of 439, across 54 files
Use real code instead of mocks unless unavoidablein 64 of 439, across 21 files
confirm the test fails for the right reasonhere, and in 64 of 439, across 60 files
reproduce bugs with a test before fixingin 53 of 439, across 36 files
write tests before implementationin 48 of 439, across 39 files

Said here and by no other author read

re-read the diff to verify fixing the cause

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.