# Skill: Write a regression test on every confirmed bug so the AI cannot break it again

> Use this skill whenever the same bug has reappeared or you want to lock in a fix -- place an automated guard at the exact door the bug crawled through, not across the entire codebase.

Source: sodigi-learn -- vibecoding/ii-ne-lomaet-pochinennoe - https://sodigi.io/learn/vibecoding/ii-ne-lomaet-pochinennoe

## When to use
- A bug has been fixed once (or several times) and keeps coming back after other changes.
- The AI fixed something in one code path and silently broke a parallel path (e.g., live mode vs. demo mode).
- You want the AI to prove a fix worked rather than just claim "looks good."
- You are about to ask the AI to modify code near a previously broken area.

## Core rules
- Write the regression test BEFORE applying the fix -- the test must fail first to prove the bug is real.
- Target the test at the exact location that broke, not the whole project. Blanket coverage is slow and pointless.
- The test must verify BOTH parallel paths (e.g., live and demo modes return the same field set).
- Run tests before doing a human code review -- a soulless machine check is more honest than self-review.
- The AI checking its own code has the same blind spots as the AI that wrote it; the automated test does not.
- After the fix, run the full test suite to make sure the repair did not break something adjacent.
- Name the test after the bug it guards so future readers understand why it exists.

## Procedure
1. Confirm the bug: describe it precisely -- what is absent or wrong, which path it occurs on.
2. Ask the AI to write a small automated test that checks the specific broken condition. The test must fail at this point.
3. Run the test -- verify it fails (bug is real, not imagined).
4. Ask the AI to fix the bug. Explicitly remind it to check ALL parallel paths (live/demo, authenticated/guest, etc.).
5. Run the test again -- it must now pass.
6. Run the full test suite -- confirm no regressions were introduced by the fix.
7. Only accept the result after seeing passing output, not after reading "I checked it."

## Ready-to-use prompt
```
This bug keeps returning: [describe the bug -- what is missing or wrong, which path].

Do this in strict order:
1. Write a small automated test that checks for the broken condition.
   Name the test after the bug.
2. Run the test. It must FAIL -- that proves the bug is real.
3. Fix the bug. Check BOTH paths -- [e.g., live mode AND demo mode] must return the same data.
4. Run the test again. It must now PASS.
5. Before saying "done," run the full test suite to confirm nothing nearby broke.
```

## Pitfalls
- Trusting "I checked it, everything works" -- the AI reviews with the same head that wrote the code; the test does not lie.
- Asking "fix it again" in a loop without adding a guard -- without a test the bug will return a sixth time.
- Writing tests on code that already works instead of on the bug that was just found.
- Checking only the primary path and forgetting the secondary one (demo mode, guest flow, error branch).
- Writing the test after the fix -- the test must fail first, otherwise you are not proving the bug existed.
- Running the human code review before the automated tests -- machine check first, opinion second.