debug
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.
Install
npx skills add https://github.com/anthropics/knowledge-work-plugins --skill debugSKILL.md
/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.
Related skills
improve-codebase-architecturemattpocock1MScan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.codebase-designmattpocock691KShared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.web-design-guidelinesvercel-labs676KReview UI code for Web Interface Guidelines compliance. Use when asked to "review my UI", "check accessibility", "audit design", "review UX", or "check my site against best practices".code-reviewmattpocock631KReview the changes since a fixed point (commit, branch, tag, or merge-base) along two axes: Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/spec asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to \"review since X\".