debug
/debug
Start a debug session - load the CANONIFY.md index, route the error you paste (text, screenshot, or a log-file reference) to the canon for that area so Claude debugs with the right context, then after the fix suggest capturing the footgun via /canonify:update-canon or /canonify:create-canon. Run when the user types /canonify:debug, or says "help me debug this error", "I'm getting this exception", "here's an error log / stack trace", "why is this failing".
- Author
- ewebdzine ↗
- Repository
- canonify ↗
- Licence
- MIT
- Last repository change
- 14.09.2026
Assessment and security
- Files in this package
- 1
- Scripts
- 0
- HTML comments
- 0
- URLs in SKILL.md
- 0
No signals detected. Repository changed on 14.09.2026, without references to retired models or APIs.
MIT, open: use and modify while retaining author attribution.
What it does and when to use it
Start a debug session - load the CANONIFY.md index, route the error you paste (text, screenshot, or a log-file reference) to the canon for that area so Claude debugs with the right context, then after the fix suggest capturing the footgun via /canonify:update-canon or /canonify:create-canon. Run when the user types /canonify:debug, or says "help me debug this error", "I'm getting this exception", "here's an error log / stack trace", "why is this failing".
Triggers from the description
Original author description
Start a debug session - load the CANONIFY.md index, route the error you paste (text, screenshot, or a log-file reference) to the canon for that area so Claude debugs with the right context, then after the fix suggest capturing the footgun via /canonify:update-canon or /canonify:create-canon. Run when the user types /canonify:debug, or says "help me debug this error", "I'm getting this exception", "here's an error log / stack trace", "why is this failing".
How it works
- How to run
- Don't do
- Output template
SKILL.md preview
---
name: debug
description: Start a debug session - load the CANONIFY.md index, route the error you paste (text, screenshot, or a log-file reference) to the canon for that area so Claude debugs with the right context, then after the fix suggest capturing the footgun via /canonify:update-canon or /canonify:create-canon. Run when the user types /canonify:debug, or says "help me debug this error", "I'm getting this exception", "here's an error log / stack trace", "why is this failing".
---
# Debug - route an error to its canon, then feed the fix back
Canonify's **reactive** gate - the twin of `/canonify:build`. Build routes a *task* forward to its
canons; Debug routes a *failure* to the canon for the area it lives in, so Claude diagnoses with the
documented patterns and gotchas already in context instead of grepping the project cold. Then, once
the bug is fixed, it closes the loop: the lesson goes back into the canon so the same class of bug
cannot recur.
**Canonify does not do the debugging.** This gate front-loads the right context and, at the end,
points you at the capture command - the diagnosis and fix in between are normal work.
## How to run
1. **Load the index, set intent.** Read `CANONIFY.md` (the manifest of one-line canon summaries). If
the user typed `/canonify:debug` alone, acknowledge and wait for the error; if they included it,
go on.
2. **Take the error in.** Accept any form: pasted text, a **screenshot** (read it via vision and
transcribe the message + stack), or a referenced **log file** (read it). Pull out the routing
signal: the **file paths + line numbers** in the stack frames, the **exception / error type**, and
the **symbols / methods** named.
3. **Route the error against the index.** Walk the `CANONIFY.md` summaries and ask which canon's area
the error falls in. A stack trace is a *precise* routing signal - it names exact files and symbols,
a stronger match than a prose task. If a canon's area matches, **load it in full**, paying special
attention to its **Gotchas** section (the known footguns for that area). If nothing matches,
proceed on breadth alone and say so - do not shoehorn the error into an unrelated canon.
4. **Debug normally.** With the right canon (and its gotchas) in context, find the cause and
propose/apply the fix in the user's usual flow. This step is ordinary debugging - the gate's value
is the context it loaded around it.
5. **Close the loop - suggest, never write.** Judge whether the bug carries a *durable, reusable*
lesson (a footgun worth documenting), then point at the right command:
- **a reusable footgun + a canon was loaded** -> "worth a gotcha in `<canon>` - run
`/canonify:update-canon`", and state the rule/gotcha you would add.
- **a reusable footgun + no canon covers the area** -> "this area is undocumented - run
`/canonify:create-canon`".
- **the loaded canon ALREADY warns about this** -> surface it: the gotcha exists but the bug
happened anyway, so either it needs to be sharper (`/canonify:update-canon` to tighten it) or
`/canonify:build` never loaded that canon for the original task. This is feedback on the canon,
not a new entry.
- **a one-off slip with no general lesson** -> say so and suggest nothing. Don't nag.
The user confirms by running the suggested command. The capture itself is owned by
`/canonify:update-canon` and `/canonify:create-canon` - this gate never writes a canon.
## Don't do
- **Don't write or edit a canon here.** Debug routes and suggests; `/canonify:update-canon` (add /
revise) and `/canonify:create-canon` (new) own the capture. Zero duplication.
- **Don't claim Canonify fixed the bug.** It front-loads context and closes the loop; the diagnosis
and fix are normal work.
- **Don't capture noise.** No durable, reusable lesson -> no suggestion. A typo teaches the canon
nothing.
- **Don't force a match.** If the error's area isn't in any canon, debug on breadth and say nothing
matched - never route it into an unrelated canon.
## Output template
```
## /canonify:debug
Index loaded: CANONIFY.md (<N> canons)
Error: <the exception / message + where it surfaced>
Routing signal: <files / symbols / type pulled from the error>
Routed to: <canon>.md (matched summary: "<line>")
(or) no canon matches this area - debugging on breadth only
[diagnosis + fix - normal work]
Fix: <one-line what changed> @ `path:line`
Capture: <update | create | sharpen | none>
- update Worth a gotcha in <canon>.md: "<the rule>". Run /canonify:update-canon.
- create This area has no canon. Run /canonify:create-canon.
- sharpen <canon>.md already warns about this - it happened anyway. Sharpen it
(/canonify:update-canon), or it wasn't loaded at build time.
- none One-off slip, no reusable lesson - nothing to capture.
```
Versions
| Repository | Score | Licence |
|---|---|---|
| This page · ewebdzine/canonify | 100 | MIT |
| ericrisco/rsc-harness | 100 | MIT |
| nicsuzor/academicops | 100 | MIT |
| duronext/jig | 100 | MIT |
| drosam/agents | 100 | MIT |
| rizukirr/vibekit | 100 | MIT |
| DingyangLyu/MatClaw | 100 | Apache-2.0 |
| Kanevry/session-orchestrator | 100 | MIT |
| kdlbs/kandev | 100 | AGPL-3.0 |
Database snapshot: 13.11.2026 · package version fcfe9f59e217 (SHA-256 digest of the entire package)
Downloads in the last 30 days: 0 · ranking
Report a problem with this skill: harmful content, incorrect descriptions or an author’s removal request.
Similar skills
- 100create-canon
Author a new "canon" - one canonical-pattern doc (a .md) - for a file, service, or design element, then register it in CANONIFY.md + the category INDEX. The command name teaches the vocabulary: each pattern doc is a "canon." Run when the user types /canonify:create-canon, or… - 100update-canon
Capture a mid-coding discovery into an EXISTING canon - describe the update and Canonify routes to the right canon, checks whether it's already covered (and whether a revision is needed) or adds it in house-style, then keeps registration + the verified SHA honest. Run when the… - 90error-reading
Use when the user pastes any error output, stack trace, log, or failure message — structured interpretation before diagnosis - 100debug-triage
Use when triaging a pasted error, stack trace, or terminal transcript. Activates on "debug this", "fix this", "why is this broken", or when a user pastes red terminal output. Produces a tight cause-fix-test report, not a lecture. - 100debug-production
Ask your agent why production broke. It reads the error, stack trace, logs, and trace in LogBrew and helps you fix the bug. Use when someone asks why something broke in production, why checkout or login fails, what an error or stack trace means, or to debug a crash, exception,… - 100debug-detective
Find the root cause of a bug, crash, error message or failing test, then fix it. Use when the user says "this is broken", "why does this fail", "I get this error", "the test is failing", "it worked yesterday", or pastes a stack trace.