CtrlK
BlogDocsLog inGet started
Tessl Logo

systematic-debugging

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes

59

Quality

67%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

High

Do not use without reviewing

Fix and improve this skill with Tessl

tessl review fix ./claude/skills/systematic-debugging/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

70%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The content is a well-sequenced debugging workflow with strong validation checkpoints and real executable instrumentation examples. Its main weaknesses are redundant reinforcement sections that bloat the body and three dead references to supporting files that are not present in the bundle.

Suggestions

Either add the referenced root-cause-tracing.md, defense-in-depth.md, and condition-based-waiting.md files to the bundle or remove the dangling references so navigation is not broken.

Consolidate the overlapping 'Red Flags', 'Common Rationalizations', and 'your human partner's Signals' sections — they repeat the same 'STOP and return to Phase 1' guidance and can be merged to cut tokens.

Move the detailed multi-layer bash instrumentation example into a reference file, keeping only a short pointer in SKILL.md to improve progressive disclosure.

DimensionReasoningScore

Conciseness

The core four-phase content is efficient and assumes Claude's competence, but the Red Flags, Common Rationalizations, and 'your human partner's Signals' sections heavily overlap each other and repeat the 'STOP, return to Phase 1' message, so it could be tightened.

3 / 5

Actionability

Mostly executable guidance: the bash instrumentation example uses real commands (git diff, security find-identity, codesign --verbose=4) and the steps are concrete, with only the boundary-instrumentation block leaning pseudocode — minor gaps.

4 / 5

Workflow Clarity

The four phases are clearly sequenced with 'MUST complete each phase before proceeding', explicit validation checkpoints ('Verify Before Continuing'), and feedback loops ('didn't work → new hypothesis', '3+ fixes → question architecture'), matching clear sequence with validation and error-recovery loops.

5 / 5

Progressive Disclosure

Section structure and headers are decent and a Quick Reference table aids navigation, but the body references three files (root-cause-tracing.md, defense-in-depth.md, condition-based-waiting.md) that do not exist in the bundle, breaking navigation, and redundant inline sections could live in separate files.

3 / 5

Total

15

/

20

Passed

Description

65%Weight 40%Scale 1-5

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 a strong, explicit trigger clause and good natural keyword coverage, but it underspecifies the concrete actions the skill performs, leaning on the skill name and a temporal hint to convey the 'what'. It is distinct and unlikely to trigger for the wrong skill.

Suggestions

Add one or two concrete actions to the description (e.g., 'investigate root cause, reproduce, trace data flow') so the 'what' is explicit, not just implied by 'before proposing fixes'.

Include a couple more natural trigger terms like 'error', 'crash', or 'exception' to broaden keyword coverage toward a 5.

DimensionReasoningScore

Specificity

The description states concrete triggers ('any bug, test failure, or unexpected behavior') but names no concrete actions the skill performs — the 'what' is only implied by 'before proposing fixes', matching 'Names the domain but actions are minimal or generic' rather than the score-3 anchor which expects listed actions.

2 / 5

Completeness

The 'when' is explicit and specific ('Use when encountering... before proposing fixes') and the 'what' is weakly present (investigate before fixing), so both exist with the 'what' less explicit — not a 5 because the what is implied rather than concrete.

4 / 5

Trigger Term Quality

'bug', 'test failure', and 'unexpected behavior' are natural phrases users say, but common variants like 'error', 'crash', 'exception', or 'broken' are missing, fitting 'Good keyword coverage; a few natural terms missing'.

4 / 5

Distinctiveness Conflict Risk

The debugging niche and 'before proposing fixes' framing are mostly distinct from other skills, with only minor overlap risk against general coding skills.

4 / 5

Total

14

/

20

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.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
joshmanders/dotfiles
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.