debug — Claude Code skill: what it does, how to install
This skill takes a bug from reproduction to root cause, a fix, and regression coverage. Use it when the symptom is clear but the cause is not.
npx skills add anthropics/knowledge-work-plugins --skill debug -a claude-codeWhat debug does
The skill runs a structured debugging session. It compares expected and actual behavior, identifies exact reproduction steps, and defines the scope of the issue. It then narrows the search to a component, service, or code path while checking recent deploys, configuration changes, dependencies, logs, and error messages.
Next, the agent forms and tests hypotheses, traces the code path, and separates the root cause from its symptoms. The result covers the reproduction, cause, proposed fix, side effects, edge cases, and tests that can prevent a regression. The report is organized around reproduction, root cause, fix, and prevention.
When monitoring, source control, or project tracker connectors are available, the skill can use them for logs, metrics, recent changes, related issues, and follow-up tickets. For a post-deploy failure, check access to monitoring and source control first.
What it helps with
- reproduce a failure from an error message or stack trace
- compare expected behavior with the observed result
- narrow a bug to the responsible code path
- check recent deploys, configuration changes, or dependencies
- propose a fix and regression test
Example prompts for the agent
- `/debug Users see an error after the deploy. Here is the stack trace; find the root cause`
- `/debug It works in staging but fails in prod. Compare the behavior and inspect recent changes`
- `/debug A dependency update broke handling for large payloads. Reproduce the issue and propose a regression test`
How to install debug
1Skills CLI (Vercel)
npx skills add anthropics/knowledge-work-plugins --skill debug -a claude-code2Manually: put the files in place
~/.claude/skills/debug/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/debug/
1Skills CLI (Vercel)
npx skills add anthropics/knowledge-work-plugins --skill debug -a codex2Manually: put the files in place
.agents/skills/debug/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add anthropics/knowledge-work-plugins --skill debug -a cursor2Manually: put the files in place
.cursor/skills/debug/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install anthropics/knowledge-work-plugins debug2Manually: put the files in place
.github/skills/debug/SKILL.md1Skills CLI (Vercel)
npx skills add anthropics/knowledge-work-plugins --skill debug -a gemini-cli2Platform CLI
gemini skills install https://github.com/anthropics/knowledge-work-plugins --path engineering/skills/debugManually: put the files in place
.devin/skills/debug/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add anthropics/knowledge-work-plugins --skill debug -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
From the same set89
The whole set →Similar
Questions about debug
What does the debug skill do?
It guides a structured debugging session: reproduce the issue, isolate the affected code path, test hypotheses, identify the root cause, and prepare a fix with regression coverage.
What information helps debug investigate an issue?
Useful context includes the exact error message or stack trace, reproduction steps, recent changes, logs, screenshots, and expected behavior. Available monitoring, source control, and project tracker connectors add more checks.
Source text
SKILL.md · Apache-2.0
--- name: debug description: Structured debugging session — reproduce, isolate, diagnose, and fix. Trigger with an error message or stack trace, "this works in staging but not prod", "something broke after the deploy", or when behavior diverges from expected and the cause isn't obvious. argument-hint: "<error message or problem description>" --- # /debug > If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md). Run a structured debugging session to find and fix issues systematically. ## Usage ``` /debug $ARGUMENTS ``` ## How It Works ``` ┌─────────────────────────────────────────────────────────────────┐ │ DEBUG │ ├─────────────────────────────────────────────────────────────────┤ │ Step 1: REPRODUCE │ │ ✓ Understand the expected vs. actual behavior │ │ ✓ Identify exact reproduction steps │ │ ✓ Determine scope (when did it start? who is affected?) │ │ │ │ Step 2: ISOLATE │ │ ✓ Narrow down the component, service, or code path │ │ ✓ Check recent changes (deploys, config changes, dependencies) │ │ ✓ Review logs and error messages │ │ │ │ Step 3: DIAGNOSE │ │ ✓ Form hypotheses and test them │ │ ✓ Trace the code path │ │ ✓ Identify root cause (not just symptoms) │ │ │ │ Step 4: FIX │ │ ✓ Propose a fix with explanation │ │ ✓ Consider side effects and edge cases │ │ ✓ Suggest tests to prevent regression │ └─────────────────────────────────────────────────────────────────┘ ``` ## What I Need From You Tell me about the problem. Any of these help: - Error message or stack trace - Steps to reproduce - What changed recently - Logs or screenshots - Expected vs. actual behavior ## Output ```markdown ## Debug Report: [Issue Summary] ### Reproduction - **Expected**: [What should happen] - **Actual**: [What happens instead] - **Steps**: [How to reproduce] ### Root Cause [Explanation of why the bug occurs] ### Fix [Code changes or configuration fixes needed] ### Prevention - [Test to add] - [Guard to put in place] ``` ## If Connectors Available If **~~monitoring** is connected: - Pull logs, error rates, and metrics around the time of the issue - Show recent deploys and config changes that may correlate If **~~source control** is connected: - Identify recent commits and PRs that touched affected code paths - Check if the issue correlates with a specific change If **~~project tracker** is connected: - Search for related bug reports or known issues - Create a ticket for the fix once identified ## Tips 1. **Share error messages exactly** — Don't paraphrase. The exact text matters. 2. **Mention what changed** — Recent deploys, dependency updates, and config changes are top suspects. 3. **Include context** — "This works in staging but not prod" or "Only affects large payloads" narrows things fast.
© anthropics · Apache-2.0 · anthropics/knowledge-work-plugins