CtrlK
BlogDocsLog inGet started
Tessl Logo

systematic-debugging

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes - four-phase framework (root cause investigation, pattern analysis, hypothesis testing, implementation) that ensures understanding before attempting solutions

58

Quality

73%

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 ./.agency/plugins/nori/skills/systematic-debugging/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

48%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 four-phase workflow is genuinely well-sequenced with strong feedback loops and escalation rules, but the body is padded with repeated exhortations of the same principle, and most guidance describes what to do rather than giving executable steps. Dangling references and the absence of any bundle files weaken its progressive disclosure structure.

Suggestions

Collapse the Overview, The Iron Law, When to Use, Red Flags, and Common Rationalizations sections into one concise 'When to use / when not to shortcut' section — the same 'no fixes without root cause' principle is repeated four or five times.

Replace the 'For EACH component boundary' pseudocode block and abstract steps like 'Trace Data Flow' with executable command templates in the style of the existing multi-layer bash example.

Either create real reference files for 'skills/root-cause-tracing' and '.claude/skills/test-driven-development' and link them clearly, or remove the dangling references and move the instrumentation example plus the rationalizations table into a references/ file to slim the main body.

DimensionReasoningScore

Conciseness

The single principle 'no fixes without root cause' is restated across the Overview, The Iron Law, When to Use, Red Flags, and Common Rationalizations sections, plus hortatory padding like 'Violating the letter of this process is violating the spirit of debugging' and uncited stats ('First-time fix rate: 95% vs 40%'). This is noticeably verbose with several padded sections (anchor 2), not merely occasionally loose (anchor 3).

2 / 5

Actionability

The multi-component instrumentation bash block is executable and the phases give concrete checklists, but most steps are imperative abstractions ('Keep tracing up until you find the source', the 'For EACH component boundary' pseudocode block) with no runnable commands. This lands at anchor 3 — some concrete guidance but incomplete — rather than 4, where most guidance would be executable.

3 / 5

Workflow Clarity

Four phases are explicitly gated ('You MUST complete each phase before proceeding') with verification checkpoints (Phase 3 'Verify Before Continuing'), failure feedback loops (failed fix → return to Phase 1; '≥ 3: STOP and question the architecture'), red-flag triggers, and a Quick Reference table. It falls short of anchor 5 because some checkpoints are implicit (no explicit gate check before Phase 2) and the per-phase sub-steps are uneven in specificity.

4 / 5

Progressive Disclosure

No bundle files exist and both referenced paths ('skills/root-cause-tracing', '.claude/skills/test-driven-development') are dangling; ~310 lines are inlined monolithically, including the instrumentation example and rationalizations tables that belong in separate reference files. This matches anchor 3 — structure present, but references unclear/broken and separable content inline — rather than 4, where references would be mostly clear and real.

3 / 5

Total

12

/

20

Passed

Description

83%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.

A strong description that explicitly covers both what the skill does and when to use it, with natural trigger terms and a distinct debugging niche. The main improvement opportunities are adding common synonyms like 'debug', 'error', or 'crash' and slightly more concrete action language.

DimensionReasoningScore

Specificity

Names the domain and four concrete phases ('root cause investigation, pattern analysis, hypothesis testing, implementation'), which counts as several specific actions. It falls short of anchor 5 because the phases are framework stages rather than comprehensive concrete operations.

4 / 5

Completeness

Explicitly answers both parts: the what ('four-phase framework (root cause investigation, pattern analysis, hypothesis testing, implementation) that ensures understanding') and a concrete when ('Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes'). This matches the anchor-5 example's structure; the when-clause is explicit, not weakly implied as at anchor 4.

5 / 5

Trigger Term Quality

'bug', 'test failure', 'unexpected behavior', and 'fixes' are natural phrases users would say. A few common synonyms are missing ('debug', 'error', 'crash', 'broken'), so it does not reach anchor 5's comprehensive synonym coverage.

4 / 5

Distinctiveness Conflict Risk

Debugging is a clear niche with dedicated triggers, making it mostly distinct from other skills. Minor overlap risk remains with testing/TDD skills around 'test failure'.

4 / 5

Total

17

/

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
microsoft/FluidFramework
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.