debugging-wizard
tessl i github:jeffallan/claude-skills --skill debugging-wizardUse when investigating errors, analyzing stack traces, or finding root causes of unexpected behavior. Invoke for error investigation, troubleshooting, log analysis, root cause analysis.
Validation
75%| Criteria | Description | Result |
|---|---|---|
metadata_version | 'metadata' field is not a dictionary | Warning |
license_field | 'license' field is missing | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
body_examples | No examples detected (no code fences and no 'Example' wording) | Warning |
Total | 12 / 16 Passed | |
Implementation
70%This skill has strong structural organization with clear workflow sequencing and excellent progressive disclosure through the reference table. However, it lacks concrete executable examples and includes some unnecessary explanatory content that Claude doesn't need. The guidance is more conceptual than actionable.
Suggestions
Add concrete code examples for common debugging scenarios (e.g., setting a breakpoint in Python with pdb, using Chrome DevTools for JS)
Remove the 'Role Definition' section - Claude doesn't need persona instructions, and this wastes tokens
Remove or significantly trim the 'Knowledge Reference' section - listing tools Claude already knows adds no value
Add a specific example showing the workflow applied to a real bug (input error -> diagnosis steps -> fix)
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is reasonably efficient but includes some unnecessary content like the 'Role Definition' section explaining Claude's persona and the 'Knowledge Reference' section listing tools Claude already knows. The constraints section has some redundancy. | 2 / 3 |
Actionability | Provides a clear workflow and constraints but lacks concrete executable code examples. The guidance is structured but abstract - no actual debugging commands, code snippets, or specific tool usage patterns are shown. | 2 / 3 |
Workflow Clarity | The 6-step core workflow is clearly sequenced with logical progression from reproduction through prevention. The MUST DO/MUST NOT DO constraints provide explicit validation checkpoints like 'test one hypothesis at a time' and 'add regression tests after fixing'. | 3 / 3 |
Progressive Disclosure | Excellent structure with a concise overview and well-organized reference table pointing to one-level-deep external files. The 'Load When' column clearly signals when to access each reference, enabling efficient navigation. | 3 / 3 |
Total | 10 / 12 Passed |
Activation
65%The description has strong trigger terms that users would naturally use when debugging, but it's structured backwards - leading with 'Use when' rather than capabilities. It lacks concrete actions describing what the skill actually does (e.g., parsing logs, suggesting fixes, tracing code paths), making it unclear what specific functionality it provides beyond general investigation.
Suggestions
Add concrete capability statements before the 'Use when' clause, such as 'Analyzes stack traces, parses error logs, traces code execution paths, and suggests fixes for bugs.'
Restructure to lead with what the skill does, then follow with when to use it: '[Capabilities]. Use when [triggers].'
Add more specific file types or contexts to improve distinctiveness, such as 'application logs', 'exception handling', or specific error types.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (error investigation, troubleshooting) and some actions (analyzing stack traces, finding root causes), but lacks comprehensive concrete actions like 'parse error logs', 'trace execution paths', or 'identify failing components'. | 2 / 3 |
Completeness | Has a 'Use when...' clause which addresses when to use it, but the 'what does this do' portion is weak - it describes scenarios rather than concrete capabilities. The description focuses more on triggers than actual functionality. | 2 / 3 |
Trigger Term Quality | Good coverage of natural terms users would say: 'errors', 'stack traces', 'troubleshooting', 'log analysis', 'root cause'. These are terms users naturally use when debugging issues. | 3 / 3 |
Distinctiveness Conflict Risk | Somewhat specific to debugging/error scenarios, but could overlap with general coding assistance skills, logging skills, or monitoring skills. Terms like 'log analysis' and 'troubleshooting' are broad enough to potentially conflict. | 2 / 3 |
Total | 9 / 12 Passed |
Reviewed
Table of Contents
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.