Skip to content
Back to skills

Debug

ASecurity

Systematic debugging when a failure's cause is unknown: reproduce first, isolate, fix the root cause once, prove it with a regression test. Use when a bug, crash, failing test or wrong output has no obvious cause, when a fix attempt did not work, or before claiming a stubborn bug fixed. For production incidents: stabilize first per `maintain`, then run this loop.

  • 2 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added September 26, 2026
ai-agentsgotestingdebugginggit

Security analysis

A100/100

Scanned September 26, 2026

npx -y skills add Tradebaas/Groundwork --skill debug --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Debug?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Debug
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/tradebaas-debug/badge)](https://www.skillsdirectory.com/skills/tradebaas-debug)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: debug
description: Systematic debugging when a failure's cause is unknown: reproduce first, isolate, fix the root cause once, prove it with a regression test. Use when a bug, crash, failing test or wrong output has no obvious cause, when a fix attempt did not work, or before claiming a stubborn bug fixed. For production incidents: stabilize first per `maintain`, then run this loop.
---

# debug: from symptom to proven root cause

A fix you never saw fail is a guess (`verify`). This loop turns an unknown failure into a
proven fix at the lowest cost. Production incident? Stabilize first per `maintain` (rollback
beats diagnosis under fire), then run this loop calmly.

## The loop

1. **Read the actual error.** The message, the stack, the failing line. Capture expected vs
   actual behavior verbatim before touching anything: the error usually says more than the
   first theory about it.
2. **Reproduce before fixing.** A failing automated test at the nearest seam is the goal; a
   minimal script is the fallback. Shrink the repro until removing anything makes the bug
   disappear. What you cannot reproduce you cannot fix, only disturb.
3. **Check what changed.** Most bugs live in the newest diff: recent commits, dependency
   bumps, config or environment changes. `git bisect` beats rereading the whole system.
4. **Hypothesize, test one change at a time.** Rank hypotheses by likelihood and cost of
   testing; each experiment changes exactly one thing and names its predicted outcome before
   running. Two simultaneous changes make the result unreadable. Read the evidence at arm's
   length: a failing suite or a log enters the context as its failures and counts (tail, grep, or
   a subagent), never whole, or the third experiment runs in a context the first two filled. Expect horses, not zebras:
   the common cause outranks the exotic one until evidence says otherwise.
5. **Fix the root cause, once.** The fix goes where the cause lives, not where the symptom
   showed (decision ladder: understand, then fix the cause once). A symptom patch that leaves
   the cause in place is not progress, and per debug hygiene a change that demonstrably fixed
   nothing gets reverted, not left in.
6. **Prove and clean.** The repro test passes and stays as the regression test; every debug
   shim (prints, sleeps, forced branches, commented-out calls) is removed; the full gate
   chain runs green.

## On a platform stack

When the stack file's header declares a hosted platform, steps 2 and 3 keep their intent and
change their instrument; the rest of the loop is unchanged. Reproduce in a real dev environment,
against the platform's own record of the failure - run history, execution logs, the audit trail -
and with its test tooling where the platform has any. For what changed, the platform keeps its
own history: solution layers and version history, the audit log of who edited what, and the
vendor's release notes for the change nobody in the project made. That is the bisect equivalent,
and it reaches one thing bisect cannot - an edit made directly in the platform editor that never
became a commit.

## Record

A non-obvious cause is lesson material: one gotcha line in STATE.md's log, so the next
session skips the dead end. For production incidents, the ten-line post-mortem belongs to
`maintain`. ⚓

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.