Hyper debug
Use when encountering a test failure, exception, regression, or unexpected behavior — before proposing fixes. Also when the user invokes /hyperclaude:hyper-debug. Forms hypotheses systematically instead of guess-and-check thrashing.From its SKILL.md
npx -y skills add zeikar/hyperclaude --skill hyper-debugAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
2.0 KB, 410 tokens by cl100k_base, as published. Nobody here has run it
hyper-debug
Debugging discipline tailored to this author's preferences.
Skip when
- You already know the exact line and exact fix (typo, missing import, obvious null check). Just fix it.
- The "bug" is a one-character correction that doesn't merit a hypothesis.
If you catch yourself rationalizing ("the cause is probably X, let me just try…") — that's hypothesis stacking. Run the cycle.
The cycle
- Reproduce. Smallest possible repro. If you can't reproduce, you can't debug.
- State the expected vs actual. Two sentences. "I expected X. I got Y."
- Hypothesize one cause. One. Not five. Pick the most likely.
- Predict what would prove the hypothesis right or wrong before running anything. "If hypothesis is correct, X should happen."
- Run the experiment. Compare to prediction.
- If wrong, hypothesize again. New hypothesis. Don't stack them.
- Once cause is confirmed, write a failing test that captures the bug before fixing — so it doesn't regress silently later.
- Fix. Run. Commit.
Anti-patterns
- Hypothesis stacking — trying five "fixes" at once and not knowing which one worked.
- Skipping the regression test — "the fix is obvious, no test needed." Write the test.
- Logging-only debugging — endless
console.logwithout forming hypotheses. Logs serve a hypothesis, not the other way around. - Reading code top-to-bottom — start at the failing assertion and walk backward, not forward.
When to escalate
If after 2-3 hypotheses you still don't know the cause, stop iterating. Re-read the error message slowly, check if your repro is actually exercising the buggy code, or take a 5-minute break — you have a wrong assumption somewhere upstream.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most debug triage skills give in 410 tokens
Counted across 1,020 of the 1,639 authors here whose files we hold, read 2026-09-06
- Find root cause before attempting any fixin 134 of 1020, across 118 files
- Create a failing test case before implementing a fixin 109 of 1020, across 95 files
- Read error messages and stack traces completelyin 102 of 1020, across 88 files
- Reproduce the issue consistently before investigatingin 90 of 1020, across 77 files
- Make the smallest possible change to test a hypothesisin 90 of 1020, across 76 files
- Trace data flow backward to find the sourcein 84 of 1020, across 70 files
- Form a single hypothesis before testingin 78 of 1020, across 64 files
- Implement only one fix at a timein 76 of 1020, across 63 files
- Question the architecture if three fixes failin 73 of 1020, across 59 files
- Add diagnostic instrumentation at component boundariesin 68 of 1020, across 56 files
- Compare broken code against working examplesin 68 of 1020, across 57 files
- Write a regression test before applying the fixin 62 of 1020, across 55 files
Said here and by no other author read
- Walk backward from the failing assertion
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.