Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

Comenzar

systematic-debugging

Estrellas45

Forks0

Actualizado17 de marzo de 2026 a las 15:00

Structured methodology for finding root causes before writing fixes

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Ejecutar en Manus

Fuente

0xranx

0xranx/agentbrief

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Desarrolladores de softwareOcupaciones informáticas y matemáticas·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.

Más de este repositorio

mismo repositorio

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.