|
| 1 | +--- |
| 2 | +name: fix-bug |
| 3 | +description: Fix a bug using test-driven development. Use when the user reports a bug, describes unexpected behavior, wants to fix a defect, or says something is broken. Enforces a strict test-first workflow where a failing test must be written and verified before any fix is attempted. |
| 4 | +argument-hint: "[bug description]" |
| 5 | +allowed-tools: Read, Grep, Glob, Edit, Write, Bash |
| 6 | +--- |
| 7 | + |
| 8 | +# Bug Fix Skill — Test-First Workflow |
| 9 | + |
| 10 | +You MUST follow this exact workflow. Do NOT skip steps. Do NOT fix the bug before writing a failing test. |
| 11 | + |
| 12 | +## Step 1: Understand the Bug |
| 13 | + |
| 14 | +- Read the bug description: $ARGUMENTS |
| 15 | +- Investigate the codebase to understand the relevant code |
| 16 | +- Identify the root cause (or narrow down candidates) |
| 17 | +- Summarize your understanding of the bug to the user before proceeding |
| 18 | + |
| 19 | +## Step 2: Write a Failing Test |
| 20 | + |
| 21 | +- Write a test that **directly exercises the buggy behavior** |
| 22 | +- The test must assert the **correct/expected** behavior — so it FAILS against the current broken code |
| 23 | +- The test name should clearly describe the bug (e.g., `test_orange_color_not_applied_to_head`) |
| 24 | +- Use the project's existing test framework and conventions |
| 25 | + |
| 26 | +## Step 3: Run the Test — Confirm It FAILS |
| 27 | + |
| 28 | +- Run ONLY the new test (not the full suite) |
| 29 | +- **Verify the test FAILS** and that it fails **because of the bug**, not for some other reason (typo, import error, wrong selector, etc.) |
| 30 | +- If the test passes: your test does not capture the bug. Go back to Step 2 |
| 31 | +- If the test fails for the wrong reason: fix the test, not the code. Go back to Step 2 |
| 32 | +- **Repeat until the test fails specifically because of the bug** |
| 33 | + |
| 34 | +## Step 4: Show Failure to User |
| 35 | + |
| 36 | +- Show the user the test code and the failure output |
| 37 | +- Explicitly ask: "This test fails because of the bug. Can you confirm this captures the issue before I fix it?" |
| 38 | +- **STOP and WAIT for user acknowledgment before proceeding** |
| 39 | +- Do NOT continue to Step 5 until the user confirms |
| 40 | + |
| 41 | +## Step 5: Fix the Bug |
| 42 | + |
| 43 | +- Make the **minimum change** needed to fix the bug |
| 44 | +- Do not refactor, clean up, or "improve" surrounding code |
| 45 | +- Do not change the test |
| 46 | + |
| 47 | +## Step 6: Run the Test — Confirm It PASSES |
| 48 | + |
| 49 | +- Run the new test again |
| 50 | +- **Verify it PASSES** |
| 51 | +- If it fails: go back to Step 5 and adjust the fix |
| 52 | +- **Repeat until the test passes** |
| 53 | + |
| 54 | +## Step 7: Run the Full Test Suite |
| 55 | + |
| 56 | +- Run ALL tests to make sure nothing else broke |
| 57 | +- If other tests fail: fix the regression without breaking the new test |
| 58 | +- Report the final result to the user |
| 59 | + |
| 60 | +## Rules |
| 61 | + |
| 62 | +- NEVER fix the bug before the failing test is written and confirmed |
| 63 | +- NEVER skip asking the user to acknowledge the test failure |
| 64 | +- NEVER modify the test to make it pass — modify the source code |
| 65 | +- If you cannot write a test for the bug, explain why and ask the user how to proceed |
| 66 | +- Keep the fix minimal — one bug, one fix, one test |
0 commit comments