Systematic Debugging

VerifiedCaution

Systematically diagnose and resolve a bug or unexpected behavior — reproduce, isolate, hypothesize, instrument, and verify.

Sby Skills Guide Bot
DevelopmentIntermediate
7/25/2026
Claude CodeCursorCodex
#debugging#root-cause-analysis#troubleshooting#workflow#code-inspection

Recommended for

Automated summary

This skill enforces a six-step debugging discipline — reproduce, isolate, form one hypothesis, instrument, fix, verify — instead of trial-and-error patching.

Strengths

  • Explicit framework that forbids guess-and-check and requires reading the code path before changing anything
  • A single testable hypothesis stated with file and line, preventing the accumulation of competing theories
  • A table of common bug categories (type mismatch, async race, state desync, boundary violation, null path) with the first thing to check for each
  • Quality guardrails: narrowest fix at the right layer, removal of temporary instrumentation, and lint/type-check before declaring done

Limitations

  • Allowed tools (Read, Grep, Glob, Bash) exclude browser devtools and interactive debuggers, weakening diagnosis of purely front-end issues
  • Assumes the user can give precise reproduction steps; intermittent bugs are only handled by adding logging first
  • Offers no regression-test writing strategy beyond running existing tests if any exist
When to use it

Use it whenever a bug or unexpected behavior is reported and you need the root cause rather than a symptom-level patch.

When not to use it

Skip it for architecture redesigns or feature requests, where there is no failing behavior to reproduce yet.

Security analysis

Caution
Quality score80/100

The skill is a debugging methodology with no destructive, exfiltrating, or obfuscated instructions; all guidance is about reading code, forming hypotheses, and verifying fixes. The only risk surface is the declared Bash tool, which is used for legitimate purposes (reproducing, running tests/linters, appending a learnings entry). That is powerful but not malicious, so it warrants 'caution' rather than 'risky'.

Findings
  • •Bash is in allowed-tools, granting arbitrary shell execution (e.g., running linters/tests); no commands are hard-coded, but scope is project-tooling only by convention, not restriction
  • •Step 6 instructs running linter/type-checker/tests via Bash, meaning the agent will execute project scripts that could themselves be untrusted
  • •The 'append an entry to learnings.md' instruction requires write access not covered by Read/Grep/Glob, likely forcing shell redirection/tee through Bash
How this analysis is made

Examples

Erreur au rafraîchissement
Quand je rafraîchis la page /dashboard, j'obtiens « Cannot read properties of undefined ». Aide-moi à trouver la cause racine au lieu de contourner le problème.
Total de commande instable
Le total du panier est parfois faux, mais seulement si je clique sur Payer deux fois très vite. Débogue ça méthodiquement.
Why is this broken
This endpoint returns 500 only in staging — the same code works locally. Figure out why it's broken and fix the real cause.

name: debug description: Systematically diagnose and resolve a bug or unexpected behavior — reproduce, isolate, hypothesize, instrument, and verify. Use when the user reports a bug, says "this doesn't work", "why is this broken", or encounters unexpected behavior. allowed-tools: Read, Grep, Glob, Bash

Systematic Debugging

Read learnings.md beside this file before starting; append an entry when a bug's root cause defied a category below.

Governing Principle

Bugs are information gaps. Debugging is not guessing — it is a systematic process of narrowing the gap between expected and actual behavior until the root cause is isolated and verifiable.

Procedure

  1. Reproduce — confirm the bug exists and is deterministic. If the user hasn't described exact steps, ask. If it's intermittent, instrument logging before proceeding.

  2. Isolate — narrow the scope:

    • Discover the entry point: which route, server function, or component is involved?
    • Trace the data flow from trigger to symptom. Read the code path, don't guess.
    • Identify the boundary where expected behavior diverges from actual behavior.
  3. Hypothesize — form exactly ONE testable hypothesis. State it as: "The bug occurs because [X] causes [Y] at [file:line]." Never hold multiple hypotheses simultaneously — test one, discard or confirm, then move to the next.

  4. Instrument — add the minimum observation needed to confirm or reject the hypothesis:

    • Console.log at the divergence point (remove after)
    • Read error output carefully — the first error in a stack is usually the root cause
    • Check types: is the runtime value what the type signature claims?
    • Check timing: is an async operation completing before it's consumed?
  5. Fix — apply the narrowest possible change that addresses the root cause, not the symptom. Constrain the fix:

    • Does it match the project's established patterns? (/patterns)
    • Does it introduce a new failure mode?
    • Is the fix in the right layer? (data bug → fix in service, not in component rendering)
  6. Verify — confirm the fix resolves the original reproduction AND doesn't break adjacent behavior:

    • Run the project's linter and type-checker
    • If tests exist, run them
    • Manually trace the fixed code path once more

Common Bug Categories

| Category | First thing to check | |---|---| | Type mismatch | Runtime value vs declared type — look for as any casts hiding the real type | | Async race | Missing await, check-then-act without atomicity (TOCTOU) | | State desync | Cache not invalidated after mutation, stale closure in a hook | | Boundary violation | Server code imported client-side, env variable missing at runtime | | Null path | Optional field accessed without guard, empty array not handled |

Constraints

  • Never guess-and-check. Read the code path before changing anything.
  • Remove all debugging instrumentation (console.log, temp vars) before considering the fix complete.
  • If the bug reveals a missing pattern or architectural gap, flag it — don't silently patch around it.

Handoffs

  • Bug reveals a design problem → /system-design.
  • Fix needs to follow an established pattern → /patterns.
  • User wants to understand why the bug existed → /teach.
  • Fix complete → /full-review to validate.

From the file to a first result

The download contains exactly the content displayed on this page. This copy may differ from the latest version in the source repository.

View the source and supporting files

This download contains SKILL.md only. Any scripts, references, templates and dependencies are not included. Get the required files from the source, preserving their directory structure, before continuing.

1. Download the file

Download SKILL.md

From the root of a test project, save the file as .skill-downloads/systematic-debugging-mrzxuoux/SKILL.md, or use the command below. This folder is for inspecting the skill before installation.

Command for macOS/Linux or WSL: requires a POSIX shell and curl. On Windows without WSL, use the download button and create the folder manually.

mkdir -p '.skill-downloads/systematic-debugging-mrzxuoux' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/systematic-debugging-mrzxuoux/download' --output '.skill-downloads/systematic-debugging-mrzxuoux/SKILL.md.part' && mv '.skill-downloads/systematic-debugging-mrzxuoux/SKILL.md.part' '.skill-downloads/systematic-debugging-mrzxuoux/SKILL.md'

2. Check prerequisites

Read SKILL.md before using it. If it references scripts or external services, inspect them and prepare the required access in your test environment.

Tools declared by the author (check availability in your agent): Read, Grep, Glob, Bash

No recognized prerequisites section in this file. This does not mean it is self-contained: libraries, tools and access requirements may be mentioned elsewhere in the content or source repository.

The platforms on this page are catalog indications. The paths below follow tool documentation; they do not prove this skill has been run in those tools. No minimum tool version is confirmed for this listing.

3. Load the skill

After inspection, copy the complete folder into your project using one of the commands below, then open a new tool session. The command stops if a folder with the same name already exists: compare the files before replacing it.

Claude Code
test -f '.skill-downloads/systematic-debugging-mrzxuoux/SKILL.md' && test -s '.skill-downloads/systematic-debugging-mrzxuoux/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/debug' && cp -R '.skill-downloads/systematic-debugging-mrzxuoux' '.claude/skills/debug'

Cursor
test -f '.skill-downloads/systematic-debugging-mrzxuoux/SKILL.md' && test -s '.skill-downloads/systematic-debugging-mrzxuoux/SKILL.md' && mkdir -p '.cursor/skills' && test ! -e '.cursor/skills/debug' && cp -R '.skill-downloads/systematic-debugging-mrzxuoux' '.cursor/skills/debug'

Codex
test -f '.skill-downloads/systematic-debugging-mrzxuoux/SKILL.md' && test -s '.skill-downloads/systematic-debugging-mrzxuoux/SKILL.md' && mkdir -p '.agents/skills' && test ! -e '.agents/skills/debug' && cp -R '.skill-downloads/systematic-debugging-mrzxuoux' '.agents/skills/debug'

OpenSkills

OpenSkills must already be installed. The local install/read procedure is checked with OpenSkills 1.5.0, which requires Node.js ≥ 20.6.0. Catalog slugs are not resolved automatically.

Official OpenSkills installation
openskills install './.skill-downloads/systematic-debugging-mrzxuoux'

openskills read 'systematic-debugging-mrzxuoux'

Reading should display the installed file content and its base directory. It does not run the skill or install its dependencies.

For an agent that reads AGENTS.md, then sync the index. This command changes AGENTS.md: review the diff before using it.

openskills sync

Manual method or another tool: attach SKILL.md to a conversation, or open it in an agent that can read files. Include any required supporting resources. No universal folder is recognized by every tool.

4. Try a first task

Use a short, synthetic input: an API endpoint, a small document or an interface brief. In a new conversation, attach the file or give the agent its path, then adapt this request:

Read .skill-downloads/systematic-debugging-mrzxuoux/SKILL.md and apply its instructions to this example: [describe a test input]. Identify any missing files, dependencies or access. Produce the result requested by the skill without inventing data or running unreviewed scripts.

Expected result: output matching the skill instructions, or a precise list of missing prerequisites. A read confirmation alone does not validate a first use. If an external resource is unavailable, that path remains untested.

Related skills