Run any Skill in Manus with one click

Get Started

systematic-debugging

Stars45

Forks0

UpdatedMarch 17, 2026 at 15:00

Structured methodology for finding root causes before writing fixes

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

0xranx

0xranx/agentbrief

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	systematic-debugging
description	Structured methodology for finding root causes before writing fixes

Methodology from obra/superpowers (MIT)

Systematic Debugging

Core rule: find the root cause before writing any fix.

Phase 1 -- Root Cause Investigation

Reproduce the bug with the simplest possible input.
Read the actual error message / stack trace. Do NOT guess.
Trace the data flow backwards from the failure site to the origin.
Identify the earliest point where observed behavior diverges from expected.

Phase 2 -- Pattern Analysis

Search the codebase for similar patterns (same API, same data path).
Check recent changes (git log, git blame) near the failure site.
Look for related open issues or past fixes for the same component.
Note if the bug is deterministic or intermittent -- intermittent implies concurrency, timing, or external state.

Phase 3 -- Hypothesis Testing

Form exactly one hypothesis at a time.
Design a minimal experiment that can confirm or refute it.
Run the experiment. Read the output fully.
If refuted, discard the hypothesis and return to Phase 1 or 2. Do NOT patch and hope.

Phase 4 -- Implementation

Write a failing test that demonstrates the root cause.
Apply the smallest change that makes the test pass.
Run the full test suite to check for regressions.
Verify the original reproduction case is resolved.
Document why the bug happened, not just what you changed.

Anti-patterns to Avoid

Shotgun debugging: making multiple changes at once.
Fixing symptoms instead of root causes.
Claiming "fixed" without re-running the reproduction case.
Skipping the hypothesis step and jumping straight to code changes.

More from this repository

same repository

self-improving

0xranx/agentbrief

Learn from corrections, mistakes, and discoveries during conversations. When the user corrects you, when something fails unexpectedly, or when you discover a project-specific pattern worth remembering — record it as a learning so future sessions benefit automatically.

2026-03-2045

twitter-workflow

0xranx/agentbrief

When the user wants to draft tweets, plan threads, post to Twitter/X, or manage their Twitter presence

2026-03-1845

design-review-checklist

0xranx/agentbrief

When reviewing UI/UX for quality, consistency, and polish. Use when the user says 'review the design,' 'check the UI,' 'does this look good,' 'design audit,' 'UX review,' or 'polish the frontend.' Also use after implementing any user-facing feature to catch visual and interaction issues before shipping.

2026-03-1845

tdd

0xranx/agentbrief

Red-green-refactor cycle for test-driven development

2026-03-1845

ceo-review

0xranx/agentbrief

When reviewing product decisions, feature scope, or user-facing changes from a founder/CEO perspective. Use when the user says 'does this make sense,' 'should we build this,' 'review the product,' 'is this good enough,' 'founder review,' 'product sense check,' or before any significant launch. This is the strategic taste layer — not engineering quality, but product quality.

2026-03-1845

agent-browser

0xranx/agentbrief

Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to "open a website", "fill out a form", "click a button", "take a screenshot", "scrape data from a page", "test this web app", "login to a site", "automate browser actions", or any task requiring programmatic web interaction.

2026-03-1845

name	systematic-debugging
description	Structured methodology for finding root causes before writing fixes

Methodology from obra/superpowers (MIT)

Systematic Debugging

Core rule: find the root cause before writing any fix.

Phase 1 -- Root Cause Investigation

Reproduce the bug with the simplest possible input.
Read the actual error message / stack trace. Do NOT guess.
Trace the data flow backwards from the failure site to the origin.
Identify the earliest point where observed behavior diverges from expected.

Phase 2 -- Pattern Analysis

Search the codebase for similar patterns (same API, same data path).
Check recent changes (git log, git blame) near the failure site.
Look for related open issues or past fixes for the same component.
Note if the bug is deterministic or intermittent -- intermittent implies concurrency, timing, or external state.

Phase 3 -- Hypothesis Testing

Form exactly one hypothesis at a time.
Design a minimal experiment that can confirm or refute it.
Run the experiment. Read the output fully.
If refuted, discard the hypothesis and return to Phase 1 or 2. Do NOT patch and hope.

Phase 4 -- Implementation

Write a failing test that demonstrates the root cause.
Apply the smallest change that makes the test pass.
Run the full test suite to check for regressions.
Verify the original reproduction case is resolved.
Document why the bug happened, not just what you changed.

Anti-patterns to Avoid

Shotgun debugging: making multiple changes at once.
Fixing symptoms instead of root causes.
Claiming "fixed" without re-running the reproduction case.
Skipping the hypothesis step and jumping straight to code changes.