CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

systematic-debugging

Four-phase debugging framework that ensures root cause investigation before attempting fixes. Never jump to solutions. Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes.

70

0.85x
Quality

76%

Does it follow best practices?

Impact

68%

0.85x

2 of 3 eval scenarios. Add 1 more for a full score.

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

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

Quality

Content

62%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 skill's workflow is its strength: a strictly sequenced four-phase process with explicit validation checkpoints and feedback loops for failed fixes. Its main weaknesses are substantial redundancy across the Red Flags, Common Rationalizations, and Quick Reference sections, and a monolithic structure that inlines example-heavy and table content that belongs in separate reference files.

Suggestions

Collapse the 'Red Flags', 'Common Rationalizations', and 'Quick Reference' sections into one — they repeat the same stop-and-return-to-Phase-1 guidance three times and account for the largest token waste.

Move the multi-component instrumentation example (secrets → workflow → build → signing) into a references/ file and keep only the general per-boundary logging pattern inline, adding one-level-deep links.

Remove rhetorical padding ('Violating the letter of this process is violating the spirit of debugging.') and unverified statistics ('95% vs 40%', '95% of no root cause cases'), and either bundle the referenced root-cause-tracing/defense-in-depth-validation skills or describe their technique inline instead of pointing to files that don't exist.

DimensionReasoningScore

Conciseness

Quotes: 'Red Flags - STOP and Follow Process', 'Common Rationalizations', 'Quick Reference', 'Violating the letter of this process is violating the spirit of debugging.', 'First-time fix rate: 95% vs 40%'. Three separate sections repeat the same stop-and-follow-process guidance, plus rhetorical filler and unverified statistics — several padded sections, matching anchor 2 rather than the 'some unnecessary explanation' of anchor 3.

2 / 5

Actionability

Quotes: 'git diff, recent commits', 'env | grep IDENTITY', 'codesign --sign "$IDENTITY" --verbose=4', 'bun test --grep "my fix"'. Mostly executable, concrete commands and specific steps for each phase; minor gaps such as the diagnostic instrumentation block being a template rather than runnable code keep it below anchor 5.

4 / 5

Workflow Clarity

Quotes: 'You MUST complete each phase before proceeding to the next', 'Create Failing Test Case ... MUST have before fixing', 'If < 3: Return to Phase 1, re-analyze with new information', 'If ≥ 3: STOP and question the architecture'. The four-phase sequence is explicit with validation checkpoints (failing test first, full suite after) and clear feedback loops for error recovery, matching the top anchor.

5 / 5

Progressive Disclosure

No references/, scripts/, or assets/ directories exist, so the ~290-line body is monolithic. Section headers provide some structure, but content that should live in separate files is inlined (the multi-layer secrets/signing instrumentation example, the rationalization tables) and mentions like 'See root-cause-tracing skill' point to unbundled skills — anchor 3, not the well-split structure of anchor 4.

3 / 5

Total

14

/

20

Passed

Description

78%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 clearly and explicitly states both what the skill does and when to use it, with natural trigger terms for common debugging situations. It is held back from the top tier only by un-enumerated capabilities and a slightly over-broad 'any unexpected behavior' trigger scope.

Suggestions

Enumerate the four phases (or name them, e.g. 'root-cause investigation, pattern analysis, hypothesis testing, implementation') to raise specificity from 1-2 named actions to several concrete actions.

Add common trigger synonyms such as 'error', 'crash', 'debug', or 'broken build' so users' natural phrasing matches more variations.

Narrow the trigger scope from 'any unexpected behavior' to situations involving diagnosing and fixing issues, reducing overlap with general review/verification skills.

DimensionReasoningScore

Specificity

Quotes: 'Four-phase debugging framework that ensures root cause investigation before attempting fixes', 'Never jump to solutions'. It names the domain and 1-2 concrete actions (investigate root cause, don't jump to fixes) but does not list several specific actions or enumerate the phases, so it sits at anchor 3 rather than 4.

3 / 5

Completeness

Quotes: 'Four-phase debugging framework that ensures root cause investigation before attempting fixes' (what) and 'Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes' (when). Both what and when are explicit with concrete trigger phrases, matching the top anchor.

5 / 5

Trigger Term Quality

Quotes: 'Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes'. Good natural keyword coverage ('bug', 'test failure', 'unexpected behavior', 'proposing fixes'), but common variations like 'error', 'crash', 'debug', or 'broken' are missing, which keeps it below the comprehensive anchor 5.

4 / 5

Distinctiveness Conflict Risk

Quotes: 'Four-phase debugging framework', 'Use when encountering any bug, test failure, or unexpected behavior'. The debugging niche and fix-proposal triggers are mostly distinct, but the broad scope of 'ANY ... unexpected behavior' creates minor overlap risk with related testing/review/verify skills, so it matches anchor 4 rather than 5.

4 / 5

Total

16

/

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.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

secondsky/claude-skills

Path

plugins/systematic-debugging/skills/systematic-debugging/SKILL.md

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.