ce-debug

A systematic debugging skill that finds the root cause of a bug and then optionally fixes it. It is used when debugging errors, investigating test failures, reproducing bugs from issue trackers such as GitHub, Linear, or Jira, or when a problem persists after failed fix attempts, including when the user pastes stack traces or error messages or says things like 'debug this', 'why is this failing', or 'fix this bug'. Its central discipline is to investigate before fixing: no fix is proposed until the full causal chain from trigger to symptom can be explained with no gaps, and 'somehow X leads to Y' counts as a gap.

Work proceeds through a defined execution flow. Phase 0 triages the input, fetching issue content when a tracker is referenced (for GitHub it uses gh issue view with title, body, comments, and labels) and reading the full comment thread, since later comments often carry updated reproduction steps or prior failed attempts. A trivial-bug fast-path can present an obvious one-line fix, but still runs the fix-or-diagnose user-choice gate before editing. Phase 1 reproduces the bug, verifies environment sanity (correct branch, installed dependencies, expected runtime version, required env vars, no stale build artifacts), and traces the code path backward from the symptom to where valid state first became invalid using observed rather than assumed values.

Phase 2 forms hypotheses with predictions for uncertain links — if a fix appears to work but the prediction is wrong, only a symptom was found, not the cause — and changes one thing at a time to avoid shotgun debugging. Phase 3 implements the fix only if the user chose to, with test-first discipline and workspace safety checks such as confirming uncommitted work and prompting to create a branch off a default branch. Phase 4 produces a structured handoff summary and prompts for the next action. Throughout, it avoids asking questions by default, investigating first and asking only when genuine ambiguity blocks progress.