udebug

Debug test failures through a four-phase root-cause investigation workflow.

47|12|Updated Apr 17, 2026
One-click install
npx skills add https://github.com/btseytlin/ultrapack --skill udebug
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: udebug
Source: https://github.com/btseytlin/ultrapack/tree/main/plugins/up/skills/udebug
Command: npx skills add https://github.com/btseytlin/ultrapack --skill udebug

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

udebug helps you systematically diagnose a bug or test failure so you fix the underlying root cause instead of applying symptom patches that tend to reappear.

Core Features & Use Cases

  • Four-phase root-cause investigation: reproduce and trace data, pattern-match against working examples, test one hypothesis minimally, then implement and verify the single fix.
  • Strong anti-whack-a-mole guardrails: enforces “no fixes without root-cause investigation,” stops after three failed fix attempts, and requires identifying the underlying pattern before closing.
  • Timing/non-determinism handling: instructs condition-based waiting (no sleep-based timing guesses) and mandates documenting investigation before settling on environmental causes.

Quick Start

Use udebug when a bug or test failure occurs—provide the error output and reproduction steps, then ask the skill to run the four investigation phases before proposing any fix.

Frequently Asked Questions about udebug

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

FAQPage Schema
What is root-cause analysis for debugging flaky tests and integration failures?

Root-cause analysis is a systematic debugging workflow that reproduces and traces failures, pattern-matches against working examples, tests a single hypothesis minimally, and implements a bounded fix. It prevents symptom patches from reappearing by enforcing investigation before any fix.

How do I debug flaky tests without guessing at timing or sleep delays?

Debug flaky tests by using condition-based waiting instead of sleep-based timing guesses. Document the investigation thoroughly before settling on environmental causes, ensuring non-determinism is traced to a root cause rather than masked with arbitrary delays.

How do I stop symptom patching when fixing build breaks and production bugs?

Stop symptom patching by enforcing a no-fix-without-investigation rule during debugging. Reproduce the failure, pattern-match against working examples, test a single minimal hypothesis, and stop after three failed fix attempts to prevent whack-a-mole debugging.

What is the best way to reproduce and trace unexpected software behavior?

The best way to reproduce and trace unexpected behavior is a four-phase root-cause workflow: reproduce and trace data, pattern-match against working examples, test one hypothesis minimally, then implement and verify a single fix with bounded retries and anti-whack-a-mole pattern checks.

When should I avoid applying fixes during root-cause analysis?

Avoid applying fixes during root-cause analysis until the failure is reproduced, traced, and pattern-matched. Stop after three failed fix attempts, and never close the investigation without identifying the underlying pattern that caused the bug.