debugging-strategies
Master systematic debugging techniques, profiling tools, and root cause analysis to efficiently track down bugs across any codebase or technology stack. Use when investigating bugs, performance issues, or unexpected behavior.
67
51%
Does it follow best practices?
Impact
95%
1.01xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./tests/ext_conformance/artifacts/agents-wshobson/developer-essentials/skills/debugging-strategies/SKILL.mdQuality
Discovery
67%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 good structural completeness with an explicit 'Use when' clause, but suffers from moderate vagueness in its capability listing—using category-level terms like 'debugging techniques' and 'profiling tools' rather than concrete actions. The trigger terms cover the basics but miss many natural user phrasings, and the 'any codebase or technology stack' claim makes it overly broad, increasing conflict risk with other skills.
Suggestions
Replace abstract categories with specific concrete actions, e.g., 'Analyze stack traces, set breakpoints, inspect logs, profile CPU/memory usage, bisect commits to isolate regressions'.
Expand trigger terms in the 'Use when' clause to include natural user language like 'error', 'crash', 'exception', 'slow', 'not working', 'memory leak', 'stack trace'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (debugging) and some actions ('debugging techniques, profiling tools, root cause analysis'), but these are still fairly abstract categories rather than concrete specific actions like 'set breakpoints, analyze stack traces, inspect memory usage'. | 2 / 3 |
Completeness | Clearly answers both 'what' (systematic debugging techniques, profiling tools, root cause analysis to track down bugs) and 'when' with an explicit 'Use when investigating bugs, performance issues, or unexpected behavior' clause. | 3 / 3 |
Trigger Term Quality | Includes some relevant keywords like 'bugs', 'performance issues', 'unexpected behavior', and 'debugging', but misses common natural variations users might say such as 'error', 'crash', 'stack trace', 'slow', 'broken', 'not working', 'exception'. | 2 / 3 |
Distinctiveness Conflict Risk | While debugging is a recognizable niche, the phrase 'across any codebase or technology stack' is very broad and could overlap with general coding assistance, code review, or performance optimization skills. The triggers 'bugs' and 'performance issues' could conflict with more specific skills. | 2 / 3 |
Total | 9 / 12 Passed |
Implementation
35%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is a comprehensive but overly verbose debugging guide that reads more like a textbook chapter than a concise skill file for Claude. It explains many concepts Claude already knows (scientific method, rubber duck debugging, 'read error messages'), includes large blocks of generic advice, and buries useful executable examples within excessive framing. The content would benefit enormously from aggressive trimming and splitting language-specific sections into referenced files.
Suggestions
Remove all generic debugging advice Claude already knows (scientific method, rubber duck debugging, 'take breaks,' 'read error messages') — focus only on specific, non-obvious techniques and executable code patterns.
Move language-specific debugging sections (JS/TS, Python, Go) into separate referenced files to reduce the main file to a concise overview with navigation links.
Replace the abstract markdown checklists in Phases 1-4 with concrete, executable examples showing actual debugging commands and their expected output.
Add explicit feedback loops with branching logic (e.g., 'If git bisect identifies commit X, run `git diff X~1 X` to see the change, then verify by reverting') instead of generic step lists.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose and padded with content Claude already knows. Explains basic concepts like the scientific method, rubber duck debugging, 'read error messages,' and 'take breaks.' The debugging mindset section, common mistakes, and best practices are all generic advice that wastes tokens. Markdown checklists rendered as code blocks add unnecessary bulk. | 1 / 3 |
Actionability | Contains some executable code examples (pdb, Chrome DevTools, git bisect, VS Code launch.json), but much of the content is abstract guidance wrapped in markdown checklists rather than concrete, copy-paste-ready instructions. Phases 1-4 are descriptive frameworks rather than actionable steps with specific commands. | 2 / 3 |
Workflow Clarity | The four-phase process (Reproduce → Gather Info → Hypothesize → Test) provides a sequence, but each phase is filled with abstract checklists rather than concrete validation checkpoints. There are no explicit feedback loops or verification steps—e.g., no 'if this doesn't work, try X' branching logic within the workflow. | 2 / 3 |
Progressive Disclosure | References to external files are listed at the bottom (references/debugging-tools-guide.md, etc.), which is good structure. However, the main file is a monolithic wall of text (~400+ lines) with extensive inline content that should be split into referenced files. The language-specific debugging sections alone could each be separate references. | 2 / 3 |
Total | 7 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
skill_md_line_count | SKILL.md is long (537 lines); consider splitting into references/ and linking | Warning |
Total | 10 / 11 Passed | |
- Repository
- Dicklesworthstone/pi_agent_rust
- Commit
6e3d68c
- 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.