Troubleshoot systematically using the Scientific Method. Use when debugging crashes, tracing errors, diagnosing unexpected behavior, or investigating exceptions.
686 tokens
context cost
the whole folder, loaded on every use
2
files
instructions only
0
copies elsewhere
how many repositories repackaged it
536
stars on the repo
on the repository, not the skill itself
Install
one command, takes just this skill from the repository
REPRODUCE: Make the failure happen on demand or gather more evidence.
HYPOTHESIZE: State one hypothesis in plain language.
EXPERIMENT: Change one variable to prove or kill the theory.
FIX: Touch code only after root cause proven.
VERIFY: Re-run the failing case and regression checks.
Red Flags
Stop if you are changing code before repro: You are guessing.
Stop if fix #2 starts before understanding fix #1: Re-open root cause.
Stop if "quick patch for now" appears: Symptom masking starts there.
Rationalization Prevention
"The bug is obvious": Obvious bugs still need evidence.
"I already tried a few things": That means you need structure.
"It only fails in prod": Gather prod evidence, do not invent local myths.
Minimal repro first: A minimal reproduction beats more random fixes.
Anti-Patterns
No shotgun debugging: Prove root cause before changing code.
No debug prints in production: Remove all print/console.log before commit.
No symptom masking: Fix root cause; never swallow errors without handling.
References
Bug Report Template
Incident pressure checklist
For production incidents, reproduce with a production-like replay and state one hypothesis before changing code; stop symptom patches until the root cause is proven.
Canonical response anchors
When this skill applies, preserve the following domain terminology or equivalent concrete examples in the answer when relevant:
hypothesis
one hypothesis
stop
Additional task-grounded exact anchors: minimal
How to use it
Copy the folder
Take hoangnguyen0403/common-debugging from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
Check the name does not clash
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.