debugging-wizard
tessl install 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.
Review Score
72%
Validation Score
12/16
Implementation Score
70%
Activation Score
65%
Generated
Validation
Total
12/16Score
Passed| Criteria | Score |
|---|---|
metadata_version | 'metadata' field is not a dictionary |
license_field | 'license' field is missing |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata |
body_examples | No examples detected (no code fences and no 'Example' wording) |
Implementation
Suggestions 4
Score
70%Overall Assessment
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 | Score | Reasoning |
|---|---|---|
Conciseness | 2/3 | 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. |
Actionability | 2/3 | 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. |
Workflow Clarity | 3/3 | 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'. |
Progressive Disclosure | 3/3 | 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. |
Activation
Suggestions 3
Score
65%Overall Assessment
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 | Score | Reasoning |
|---|---|---|
Specificity | 2/3 | 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'. |
Completeness | 2/3 | 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. |
Trigger Term Quality | 3/3 | 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. |
Distinctiveness Conflict Risk | 2/3 | 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. |