debug

anthropics/knowledge-work-plugins

Structured debugging session to reproduce, isolate, diagnose, and fix issues systematically.

What is debug?

A guided debugging workflow that takes an error message or problem description and walks through reproduction, isolation, diagnosis, and fix steps. Use it when you have an error, stack trace, or behavior that diverges from expected and the cause isn't obvious.

Reproduce the issue by understanding expected vs. actual behavior and identifying exact reproduction steps
Isolate the problem by narrowing down affected components, services, or code paths
Diagnose the root cause by forming and testing hypotheses and tracing code execution
Propose fixes with explanations and suggest tests to prevent regression
Generate a structured debug report with reproduction steps, root cause, and prevention measures

How to install debug

npx skills add https://github.com/anthropics/knowledge-work-plugins --skill debug

Claude Code

Cursor

Windsurf

Cline

How to use debug

1.Provide the error message, stack trace, or problem description to the /debug command
2.Share any relevant context such as reproduction steps, recent changes, or affected scope
3.Review the generated debug report covering reproduction, root cause, and proposed fix
4.Examine the suggested prevention measures and tests to add

Use cases

Good for

Debugging an error message or stack trace in production
Troubleshooting behavior that works in staging but fails in production
Investigating issues that appeared after a recent deploy or dependency update
Narrowing down the cause when behavior diverges from expected
Identifying root causes when only symptoms are visible

Who it's for

Backend engineers and full-stack developers
DevOps and platform engineers troubleshooting production issues
QA engineers investigating test failures
Anyone systematically debugging unfamiliar codebases

debug FAQ

What information should I provide to get the best results?

Share the exact error message or stack trace, steps to reproduce, what changed recently (deploys, config, dependencies), logs or screenshots, and the difference between expected vs. actual behavior.

Can this skill access my logs and monitoring data?

If monitoring or source control connectors are available, the skill can pull logs, error rates, metrics, recent commits, and PRs to correlate with the issue. Otherwise, you provide the information directly.

What does the output look like?

A structured debug report with sections for reproduction (expected/actual/steps), root cause explanation, proposed code or configuration fixes, and prevention measures including tests to add.

How do I trigger this skill?

Use /debug followed by your error message or problem description, such as '/debug [error message]' or '/debug this works in staging but not prod'.

Full instructions (SKILL.md)

Source of truth, from anthropics/knowledge-work-plugins.

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.

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

## 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

Share error messages exactly — Don't paraphrase. The exact text matters.
Mention what changed — Recent deploys, dependency updates, and config changes are top suspects.
Include context — "This works in staging but not prod" or "Only affects large payloads" narrows things fast.