Use when investigating errors, analyzing stack traces, or finding root causes of unexpected behavior. Invoke for error investigation, troubleshooting, log analysis, root cause analysis.
Install with Tessl CLI
npx tessl i github:jeffallan/claude-skills --skill debugging-wizard74
Does it follow best practices?
If you maintain this skill, you can automatically optimize it using the tessl CLI to improve its score:
npx tessl skill review --optimize ./path/to/skillAgent success when using this skill
Validation for skill structure
Discovery
64%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description has strong trigger terms that match natural user language for debugging scenarios, but it's structured backwards - it leads with 'when' but never clearly states 'what' the skill actually does. The capabilities are implied through the use cases rather than explicitly stated, making it unclear what concrete actions this skill performs.
Suggestions
Add explicit capability statements before the 'Use when' clause, e.g., 'Parses error messages, traces execution flow through stack traces, correlates log entries to identify failure points.'
Restructure to follow the pattern: [What it does]. [Use when...] - currently the description only contains trigger conditions without stating concrete actions.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (error investigation, troubleshooting) and some actions (analyzing stack traces, finding root causes), but lacks concrete specific 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 is essentially all 'when' with minimal 'what'. | 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 logging skills, monitoring skills, or general code review skills. Terms like 'log analysis' and 'unexpected behavior' are broad enough to cause conflicts. | 2 / 3 |
Total | 9 / 12 Passed |
Implementation
70%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill has strong structural organization with clear workflow steps and excellent progressive disclosure through the reference table. However, it lacks concrete executable examples and includes some unnecessary role-playing framing that Claude doesn't need. The actionability would benefit significantly from inline code snippets demonstrating actual debugging commands.
Suggestions
Add concrete code examples for common debugging scenarios (e.g., actual pdb commands, Chrome DevTools snippets, git bisect workflow)
Remove or condense the 'Role Definition' section - Claude doesn't need persona framing to debug effectively
Replace the vague 'Knowledge Reference' list at the end with either nothing or specific command examples
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is reasonably efficient but includes some unnecessary framing ('You are a senior engineer with 15+ years...') and the 'Knowledge Reference' section at the end is a vague list that adds little value. The role definition section explains debugging philosophy Claude already understands. | 2 / 3 |
Actionability | Provides a clear workflow and constraints but lacks concrete, executable code examples. The guidance is procedural rather than copy-paste ready - no actual debugging commands, code snippets, or specific tool invocations are shown inline. | 2 / 3 |
Workflow Clarity | The 5-step core workflow is clearly sequenced with logical progression (Reproduce → Isolate → Hypothesize → Fix → Prevent). 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 use of a reference table with clear 'Load When' guidance for one-level-deep navigation. Content is appropriately split between overview (SKILL.md) and detailed references, with well-signaled links to specific topics. | 3 / 3 |
Total | 10 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
Table of Contents
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.