hyper-debug

Guide debugging from observed symptoms to one testable hypothesis per cycle.

3|Updated May 10, 2026
One-click install
npx skills add https://github.com/zeikar/hyperclaude --skill hyper-debug
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: hyper-debug
Source: https://github.com/zeikar/hyperclaude/tree/main/skills/hyper-debug
Command: npx skills add https://github.com/zeikar/hyperclaude --skill hyper-debug

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

hyper-debug prevents inefficient guess-and-check debugging by enforcing a disciplined loop from reproduction to hypothesis testing, then to regression protection before any fix.

Core Features & Use Cases

  • Hypothesis-driven debugging cycle: reproduces the smallest failing case, states expected vs actual, forms one testable cause hypothesis, and validates it against predictions.
  • Experiment-first reasoning: forces clear proof criteria before running anything, reducing trial-and-error and wasted iteration.
  • Regression test before fixing: writes a failing test that captures the confirmed bug so the behavior is protected against future regressions.

Quick Start

Invoke hyper-debug when you hit a failing test or unexpected behavior so you can reproduce it, form one hypothesis, run a targeted experiment, and only then write a failing regression test and apply the fix.

Frequently Asked Questions about hyper-debug

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
What is hypothesis-driven debugging and how does it fix failing tests?

Hypothesis-driven debugging is a systematic method that turns observed symptoms into one testable hypothesis at a time. It reduces inefficient guess-and-check by reproducing the smallest failing case, stating expected vs actual outcomes, and validating the cause before fixing.

How do I find the root cause of a test failure or unexpected runtime exception?

To find the root cause of a test failure, reproduce the smallest failing case, form one testable cause hypothesis, and run a targeted experiment. You predict evidence before executing, confirming the exact cause only after the experiment validates your prediction.

When should I write a regression test during the debugging workflow?

You should write a regression test only after confirming the exact cause of the bug. This ensures the failing test captures the confirmed behavior, protecting against future regressions before you apply the actual fix to the codebase.

Can I use this systematic debugging approach for intermittent behavior regressions?

Yes, this approach applies to behavior regressions, but it requires reproducing the smallest failing case. If the regression or exception cannot be reliably reproduced to state expected vs actual outcomes, hypothesis testing will not be effective.

What is the best way to stop trial-and-error debugging when assertions fail?

The best way to stop trial-and-error debugging is to enforce experiment-first reasoning. By forcing clear proof criteria before running anything, you validate one testable hypothesis against predicted evidence, eliminating wasted iterations and thrash.