CtrlK
BlogDocsLog inGet started
Tessl Logo

systematic-debugging

ALWAYS use before attempting any fix. Never jump to solutions - investigate root cause first. Use when encountering any technical issue, bug, test failure, or unexpected behavior.

67

Quality

80%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

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

Quality

Content

77%

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, highly actionable debugging playbook with executable code examples and clear validation checkpoints across four phases. Its main weaknesses are length/repetition that could be tightened and the absence of any progressive-disclosure file structure — all detail lives inline in a single long document.

Suggestions

Move the longer technique sections (Root Cause Tracing, Defense-in-Depth Validation) and the multi-component logging recipes into reference files under ./references/ with a concise pointer, to lift progressive_disclosure.

Trim overlap between the 'Red Flags' list, 'Common Rationalizations' table, and the four-phase introductions to reduce token weight.

Replace rhetorical emphasis lines ('Violating the letter of this process is violating the spirit of debugging') with concrete guidance to improve conciseness.

DimensionReasoningScore

Conciseness

The body is mostly directive and efficient, but it is quite long with some repetition (e.g. the Red Flags list restating Common Rationalizations and the four-phase intro) and rhetorical emphasis ('Violating the letter... is violating the spirit') that could be trimmed; it earns its place for the most part but could be tightened.

2 / 3

Actionability

It provides concrete, executable guidance — multi-layer logging snippets (bash codesign/env checks), TypeScript stack-trace instrumentation, bisection scripts, and four-layer validation code — that are copy-paste ready and specific.

3 / 3

Workflow Clarity

The four phases are explicitly sequenced with a gating rule ('MUST complete each phase before proceeding'), explicit validation checkpoints ('Did it work? Yes → Phase 4'), and a feedback loop (return to Phase 1, escalate at 3+ failures) with success criteria in the Quick Reference table.

3 / 3

Progressive Disclosure

There are no bundle files (references/scripts/assets absent) and the body is a single ~426-line monolithic document; sections are well-organized internally but no detailed material is split into separate one-level-deep referenced files, so it sits at the 2-anchor 'could be better organized / content that should be separate is inline'.

2 / 3

Total

10

/

12

Passed

Description

82%

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 'Use when' trigger and clear natural-language trigger terms, but it is directive and imperative ('ALWAYS', 'Never') rather than third-person, and it does not list multiple concrete capabilities, capping specificity. Its first/second-person imperative voice conflicts with the third-person guideline.

Suggestions

Rewrite in third person (e.g. 'Investigates root causes before applying fixes') instead of imperative directives like 'ALWAYS use' and 'Never jump'.

Enumerate concrete capabilities the skill performs (e.g. 'reproduces bugs, traces data flow, isolates root causes, validates fixes') to lift specificity from 2 to 3.

Tighten the trigger scope so it is less likely to overlap with specialized fixing skills.

DimensionReasoningScore

Specificity

It names the domain (debugging/investigation) and the core action ('investigate root cause first') but does not enumerate multiple concrete actions like the 3-anchor examples do; it leans on directives ('ALWAYS use', 'Never jump') rather than a concrete capability list.

2 / 3

Completeness

It explicitly answers both what ('investigate root cause first') and when ('Use when encountering any technical issue, bug, test failure, or unexpected behavior'), satisfying the 3-anchor requirement for an explicit 'Use when...' trigger clause.

3 / 3

Trigger Term Quality

The 'Use when' clause covers natural terms users would actually say — 'technical issue, bug, test failure, or unexpected behavior' — matching the breadth of the 3-anchor example.

3 / 3

Distinctiveness Conflict Risk

The scope is broad ('any technical issue, bug, test failure') and could overlap with more specialized debugging/fixing skills; it occupies a clear-enough niche but the generic triggers invite some overlap.

2 / 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.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
heyitsnoah/claudesidian
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.