Skill Tracer
Skills › Knowledge Work Plugins › debug

debug

skill · 95 lines · Apache-2.0 · engineering/skills/debug/SKILL.md

The facts

Its 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.

The description the agent reads to decide when to use it.

From its settingsline 3

When it starts

Someone brings a concrete, unexplained failure — an error message, a stack trace, or behavior that diverges from what's expected — and wants it diagnosed and fixed rather than just explained. The agent picks this up when a person describes something broken and the cause isn't obvious.

Things a person might say (the model's guesses)

  • “I'm getting a TypeError: cannot read property 'id' of undefined in the checkout flow”
  • “This works in staging but not in prod”
  • “Something broke after this morning's deploy and I can't tell what”

A model's summary of when it is used.

A model's reading

What it takes when started

<error message or problem description>

What to type after its name when you start it.

From its settingsline 4

Licence

Apache-2.0, from LICENSE

The terms its author shares it under, which let it be shown here.

From the repositorylicence text

The text

Open on GitHub

Most marks come from matching words in the file, so treat them as pointers.

1---
2name: debug
3description: 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.
4argument-hint: "<error message or problem description>"
5---
6
7# /debug
8
9> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).
11Run a structured debugging session to find and fix issues systematically.

/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.

Raw lines 1 to 12
Boilerplate, lines 13 to 18. The same text appears in 24 other files here. Close
13## Usage
15```
16/debug $ARGUMENTS
17```
19## How It Works
21```
22┌─────────────────────────────────────────────────────────────────┐
23│ DEBUG │
24├─────────────────────────────────────────────────────────────────┤
25│ Step 1: REPRODUCE │
26│ ✓ Understand the expected vs. actual behavior │
27│ ✓ Identify exact reproduction steps │
28│ ✓ Determine scope (when did it start? who is affected?) │
29│ │
30│ Step 2: ISOLATE │
31│ ✓ Narrow down the component, service, or code path │
32│ ✓ Check recent changes (deploys, config changes, dependencies) │
33│ ✓ Review logs and error messages │
34│ │
35│ Step 3: DIAGNOSE │
36│ ✓ Form hypotheses and test them │
37│ ✓ Trace the code path │
38│ ✓ Identify root cause (not just symptoms) │
39│ │
40│ Step 4: FIX │
41│ ✓ Propose a fix with explanation │
42│ ✓ Consider side effects and edge cases │
43│ ✓ Suggest tests to prevent regression │
44└─────────────────────────────────────────────────────────────────┘
45```

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                           │
└─────────────────────────────────────────────────────────────────┘
Raw lines 19 to 46
47## What I Need From You
49Tell me about the problem. Any of these help:
50- Error message or stack trace
51- Steps to reproduce
52- What changed recently
53- Logs or screenshots
54- Expected vs. actual behavior

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
Raw lines 47 to 55
56## Output
58```markdown
59## Debug Report: [Issue Summary]
61### Reproduction
62- **Expected**: [What should happen]
63- **Actual**: [What happens instead]
64- **Steps**: [How to reproduce]
66### Root Cause
67[Explanation of why the bug occurs]
69### Fix
70[Code changes or configuration fixes needed]
72### Prevention
73- [Test to add]
74- [Guard to put in place]
75```

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]
Raw lines 56 to 76
77## If Connectors Available
79If **~~monitoring** is connected:
80- Pull logs, error rates, and metrics around the time of the issue
81- Show recent deploys and config changes that may correlate
83If **~~source control** is connected:
84- Identify recent commits and PRs that touched affected code paths
85- Check if the issue correlates with a specific change
87If **~~project tracker** is connected:
88- Search for related bug reports or known issues
89- Create a ticket for the fix once identified

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
Raw lines 77 to 90
Uses an outside tool ~~monitoring :79
Uses an outside tool ~~source :83
Uses an outside tool ~~project :87
91## Tips
931. **Share error messages exactly** — Don't paraphrase. The exact text matters.
942. **Mention what changed** — Recent deploys, dependency updates, and config changes are top suspects.
953. **Include context** — "This works in staging but not prod" or "Only affects large payloads" narrows things fast.

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.
Raw lines 91 to 95

From anthropics/knowledge-work-plugins at 2574e29, 2026-10-27. Skills read by DeepSeek V4.1 Flash on 2026-11-04. Summary and techniques by Claude Opus 5.5 on 2026-11-06.