Reproduce First, Fix Last.

Asking Claude to "fix my code" and asking it to "debug it" sound like the same request, but this short video explains that they are not. A skill called debug runs a structured session first, and only then reaches a fix. The video describes what that skill does, what starts it, and, just as important, what it does not promise.

A skill is a folder Claude reads before it acts

The video defines a skill as a folder Claude reads before it acts. The debug skill is one of them, and its SKILL.md file spells out a single job: run a structured debugging session. That job has four steps, always in the same order: reproduce, isolate, diagnose, then fix. The fix comes last, and the title of the video states the idea directly: reproduce first, fix last.

What starts the session

Claude runs the session when it recognizes one of a few situations. The video lists them:

• an error message or a stack trace,
• "this works in staging but not in production,"
• "something broke after the deploy," or
• behavior that diverges from what is expected when the cause is not obvious.

Any one of those starts the session. Nothing else does.

Repeatable, but not universal

The guarantee the video describes is repeatability. Run the skill twice on the same problem and you get the same four steps in the same order, never skipped and never reordered. That is a statement about process consistency, not about guaranteed results.

The video is just as direct about the limit. The guarantee starts only once your problem matches one of the triggers. If you describe something outside that list, the skill has nothing to say about it. So the skill is dependable for the kinds of breakage it recognizes and silent on everything else.

The carry-out

In short, debug never jumps straight to a fix. It reproduces, isolates, diagnoses and then fixes, in the same order every time, but only for the kinds of breakage it is built to recognize. The video deliberately describes the mechanism and stops there, without judging whether this is the right way to structure a debugging session.

Key takeaways

• A skill is a folder Claude reads before it acts.
• The debug skill's SKILL.md defines one job: a structured debugging session.
• The four steps are reproduce, isolate, diagnose, fix, always in that order.
• Triggers include error messages, stack traces, staging-versus-production differences, post-deploy breakage, and unexplained unexpected behavior.
• Running it twice on the same problem gives the same four steps in the same order.
• The guarantee applies only when the problem matches a trigger.
• The fix always comes last, never first.

Try it yourself

Paste this into Claude: "I have a feature that works in staging but breaks in production, and I don't know why. Read the debug skill and walk me through what you will do, in order, before you start." Watch whether Claude reproduces the problem first or jumps straight to guessing a fix. Run it on your own broken feature rather than a made-up example.