Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

Commencer

systematic-debugging

Étoiles45

Forks0

Mis à jour17 mars 2026 à 15:00

Structured methodology for finding root causes before writing fixes

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

0xranx

0xranx/agentbrief

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·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.

Plus depuis ce dépôt

même dépôt

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.