Debug to the root

Finds the real cause of a bug with proof in hand, instead of patching the symptom.

Cuándo se usa

When something fails and the easy explanation does not add up, or the same bug comes back.

SKILL.md

# Debug to the root

A patch that hides the symptom costs more than the bug, because it comes back in
disguise. Do not propose a fix before the cause is proven.

## Procedure

1. **Reproduce.** The exact steps, the expected result and the real one. If it
   does not reproduce, that is the first thing to solve.
2. **Isolate.** Shrink the case to the smallest piece that still fails. Every
   part you remove without changing the outcome stops being a suspect.
3. **Write the hypothesis.** One concrete, checkable sentence. "Something with
   the state" does not count; "the effect runs twice because the dependency is a
   new object on every render" does.
4. **Test it.** With a log line, a breakpoint or a failing test. If the
   hypothesis does not hold, go back to step 2 instead of tweaking it.
5. **Fix the cause**, not the place where it shows. If you have to touch a second
   spot to compensate, the cause is still there.
6. **Leave the test** that fails before the fix and passes after it.

## When the comparison is "it works over there"

If something works on another site or another machine, the difference is in the
environment, not the logic. Compare versions, browser permissions, flags,
environment variables and headers. Download the HTML of the site that works and
read it: the answer is usually written right there.

When you finish, say in two sentences what the cause was and how it was proven.
If you did not find it, say so plainly: a guess sold as a diagnosis wastes more
time than an honest "I do not know".