
Systematic Debugging
- 53 installs
- 31 repo stars
- Updated April 12, 2026
- itallstartedwithaidea/agent-skills
Systematic Debugging is an agent skill that enforces four-phase root cause analysis—usable whenever a solo builder needs to prove why a bug exists before committing a fix.
About
Systematic Debugging is a journey-wide agent skill from Agent Skills by googleadsagent.ai that stops trial-and-error patching. The agent must reproduce the bug reliably, rank hypotheses, instrument and test one variable at a time, and only then apply a targeted fix—articulating the causal chain before writing corrective code. That rigor matters for solo builders who cannot afford regressions from multi-file guesswork. After the fix, the skill expects defense-in-depth: assertions, validation, or monitoring that catches the same bug class again, plus a short post-mortem for future you and your agent. Invoke it when tests fail, users send stack traces, or behavior diverges across environments. It complements ship-time QA and operate-time incident response without replacing dedicated security audits or feature planning skills.
- Four-phase root cause analysis: reproduce, hypothesize, test minimally, then fix
- Blocks fixes until root cause is stated in plain language
- One-variable-at-a-time hypothesis testing with observable evidence
- Defense-in-depth hardening after the targeted fix
- Session ends with post-mortem: root cause, fix, and preventive measures
Systematic Debugging by the numbers
- 53 all-time installs (skills.sh)
- +3 installs in the week ending Aug 2, 2026 (Skillselion tracking)
- Ranked #306 of 596 Debugging skills by installs in the Skillselion catalog
- Security screen: LOW risk (skills.sh audit)
- Data as of Aug 4, 2026 (Skillselion catalog sync)
npx skills add https://github.com/itallstartedwithaidea/agent-skills --skill systematic-debuggingAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 53 |
|---|---|
| repo stars | ★ 31 |
| Security audit | 3 / 3 scanners passed |
| Last updated | April 12, 2026 |
| Repository | itallstartedwithaidea/agent-skills ↗ |
What it does
Replace shotgun debugging with a four-phase root-cause workflow before any fix lands in your repo.
Who is it for?
Best when you're facing flaky tests, production-only bugs, or stack traces and want scientific debugging discipline.
Skip if: Greenfield feature work with no failure signal, or situations where you only need lint formatting without a defect to analyze.
When should I use this skill?
A test fails unexpectedly or intermittently; a user reports a bug with a stack trace or reproduction steps; or code behaves differently across environments.
What you get
You get a reproduced failure, a validated root cause, a minimal fix, defense-in-depth guards, and a post-mortem note instead of unexplained green tests.
- Documented root cause in plain language before the fix
- Targeted code fix with hypothesis evidence trail
- Defense-in-depth guards and a post-mortem note
By the numbers
- Four-phase root cause analysis process
- Defense-in-depth hardening step after targeted fix
- Post-mortem documentation required at session end
Files
Systematic Debugging
Part of Agent Skills™ by googleadsagent.ai™
Description
Systematic Debugging replaces trial-and-error fixes with a disciplined four-phase root cause analysis process. The agent reproduces the bug reliably, generates ranked hypotheses, tests each hypothesis with minimal instrumentation, and applies a targeted fix with defense-in-depth hardening. No fix is applied without first understanding why the bug exists.
Agents are prone to "shotgun debugging"—changing multiple things simultaneously and hoping the problem disappears. This skill enforces scientific rigor: one variable at a time, observable evidence at each step, and a clear causal chain from root cause to fix. The agent must articulate the root cause in plain language before writing any corrective code.
After the immediate fix, the agent applies defense-in-depth: adding assertions, input validation, or monitoring that would catch the same class of bug in the future. The debugging session concludes with a post-mortem note documenting the root cause, the fix, and the preventive measures added.
Use When
- A test fails unexpectedly or intermittently
- A user reports a bug with a stack trace or reproduction steps
- Code behaves differently in production than in development
- An error message is unclear or misleading
- Multiple potential causes exist and guessing would waste time
- A previous fix attempt did not resolve the issue
How It Works
graph TD
A[Bug Report] --> B[Phase 1: Reproduce]
B --> C{Reproducible?}
C -->|No| D[Gather More Context]
D --> B
C -->|Yes| E[Phase 2: Hypothesize]
E --> F[Rank Hypotheses by Likelihood]
F --> G[Phase 3: Test Top Hypothesis]
G --> H{Root Cause Found?}
H -->|No| I[Eliminate Hypothesis]
I --> F
H -->|Yes| J[Phase 4: Fix + Harden]
J --> K[Write Regression Test]
K --> L[Apply Defense-in-Depth]
L --> M[Document Post-Mortem]The four phases enforce a strict progression: you cannot fix what you cannot reproduce, you should not fix what you do not understand, and you must not close a bug without preventing its recurrence.
Implementation
class DebuggingSession:
def __init__(self, bug_report):
self.report = bug_report
self.hypotheses = []
self.evidence = []
self.root_cause = None
def phase_reproduce(self):
"""Create a minimal, reliable reproduction."""
minimal_input = self.minimize_reproduction(self.report.steps)
result = self.execute(minimal_input)
assert result.matches(self.report.expected_failure), \
"Cannot proceed without reliable reproduction"
return ReproductionCase(minimal_input, result)
def phase_hypothesize(self, repro):
"""Generate ranked hypotheses from evidence."""
self.hypotheses = [
Hypothesis("Race condition in async handler", likelihood=0.7),
Hypothesis("Null reference from cache miss", likelihood=0.5),
Hypothesis("Stale closure over mutable state", likelihood=0.3),
]
return sorted(self.hypotheses, key=lambda h: -h.likelihood)
def phase_test(self, hypothesis, repro):
"""Test one hypothesis with minimal instrumentation."""
probe = self.instrument(hypothesis.target_area)
result = self.execute_with_probe(repro, probe)
if result.confirms(hypothesis):
self.root_cause = hypothesis
else:
hypothesis.eliminated = True
self.evidence.append(result)
def phase_fix(self):
"""Apply targeted fix with defense-in-depth."""
fix = self.root_cause.generate_fix()
regression_test = self.root_cause.generate_regression_test()
hardening = self.apply_defense_in_depth([
InputValidation(self.root_cause.entry_point),
AssertionGuard(self.root_cause.invariant),
MonitoringAlert(self.root_cause.symptom),
])
return DebugResult(fix, regression_test, hardening)Root-Cause Tracing Checklist
1. Read the actual error, not just the message—examine the full stack trace 2. Identify the first divergence from expected behavior, not the crash site 3. Check recent changes via git log --oneline -20 and git diff 4. Verify assumptions about input data, environment state, and dependencies 5. Instrument, don't guess—add logging at the divergence point
Best Practices
- Always reproduce before hypothesizing; never skip Phase 1
- Limit active hypotheses to 3-5 ranked by likelihood and testability
- Change one variable per test cycle to maintain causal clarity
- Write the regression test before applying the fix
- Apply defense-in-depth: validation, assertions, and monitoring beyond the fix
- Document the root cause even for "obvious" bugs—patterns emerge over time
Platform Compatibility
| Platform | Support | Notes |
|---|---|---|
| Cursor | Full | Debugger + Shell for reproduction |
| VS Code | Full | Integrated debugger support |
| Windsurf | Full | Terminal-based debugging |
| Claude Code | Full | Shell access for instrumentation |
| Cline | Full | Step-through debugging |
| aider | Partial | Limited to log-based debugging |
Related Skills
- Test-Driven Development - Write the failing test that exposes the bug before applying any fix
- Code Review - Review the fix and regression test for quality before merging
- Agent Security Scanning - Security-focused analysis that may identify vulnerability root causes during debugging
Keywords
debugging root-cause-analysis systematic-debugging reproduce-hypothesize-test-fix defense-in-depth regression-test post-mortem bug-fix
---
© 2026 googleadsagent.ai™ | Agent Skills™ | MIT License
Related skills
How it compares
Use instead of ad-hoc chat “try this patch” loops when you need evidence-backed root cause before code changes.
FAQ
Who is systematic-debugging for?
Developers and agent operators who debug their own SaaS, APIs, and scripts and want one enforced process instead of shotgun edits.
When should I use systematic-debugging?
In Ship when tests fail or behavior is wrong before release; in Operate when incidents need reproduction and root cause; in Build when implementation bugs appear during integration—any time you have a concrete failure to investigate.
Is systematic-debugging safe to install?
The skill encourages minimal instrumentation rather than destructive commands, but review the Security Audits panel on this page and constrain agent shell access when testing hypotheses.