CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

systematic-debugging

Investigates a test failure, bug, or unexpected behavior to find its root cause before proposing any fix - reproduce the issue, trace the data flow, form and test one hypothesis at a time, then implement and verify the fix. This is the debugging stage inside the delivery-flow workflow, entered by requests like "debug this failure", "why is this test failing", "find the root cause", or "this bug keeps coming back" once delivery-flow has handed off a bug. Do not activate directly for a standalone bug report that has not gone through delivery-flow first.

68

Quality

86%

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

The canonical home for this skill is tessleng/sdlc-implementation

SKILL.md
Quality
Evals
Security

Quality

Content

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

A well-structured process skill: the four-phase workflow is clearly gated with explicit validation and feedback loops, and bundle references are properly organized one level deep with verified paths. Its main weakness is redundancy — four separate sections restate the phase rules — plus some abstract directives and an inline example that belong in references.

Suggestions

Consolidate 'Red Flags', 'Common Rationalizations', and "your human partner's Signals" into a single compact table or fold them into their relevant phases — the 3+-fixes architecture rule alone is currently stated in four places.

Replace abstract directives like 'Research more', 'Ask for help', and 'Gather more data, don't guess' with concrete next actions (e.g., specific commands to run or what evidence to collect next).

Move the ~30-line multi-layer bash instrumentation example into a reference file (e.g., references/evidence-gathering.md), keeping only a 2-3 line pointer and summary inline, consistent with how Phase 1.5 handles root-cause-tracing.md.

DimensionReasoningScore

Conciseness

The four-phase core is efficiently written, but four sections — 'Red Flags', 'Common Rationalizations', "your human partner's Signals", and the 'Quick Reference' table — largely restate the same rules already stated in the phases (e.g., the 3+-fixes architecture rule appears in Phase 4, Red Flags, and the Rationalizations table). Fits 'Mostly efficient but includes some unnecessary explanation or could be tightened': not 4 because roughly 40% of the body is restatement that could be cut, not 2 because the padding is self-reinforcement of its own process rather than explanation of concepts Claude already knows.

3 / 5

Actionability

Provides mostly executable guidance: a concrete copy-paste bash instrumentation example for multi-layer evidence gathering, explicit thresholds ('If ≥ 3: STOP and question the architecture'), a failing-test-first directive, and pointers to sibling skills and reference files. Not 5 because several directives remain abstract ('Research more', 'Ask for help', 'Gather more data, don't guess') and the Phase 1.4 evidence block is pseudocode; not 3 because the guidance is specific and executable across the common cases.

4 / 5

Workflow Clarity

Four phases are clearly sequenced with hard gating ('You MUST complete each phase before proceeding to the next'), explicit validation checkpoints (failing test required before fixing, 'Test passes now? No other tests broken?'), and feedback loops for error recovery (failed hypothesis → form NEW hypothesis; 3+ failed fixes → return to Phase 1 or question architecture). Matches the anchor 'Clear sequence with explicit validation steps; feedback loops for error recovery; checklists' — the 'Quick Reference' table serves as the checklist; only a minor label inconsistency ('see Phase 4.5' vs 'step 5 below') keeps it from being flawless, but it clearly fits this anchor over the 4 anchor, which allows validation gaps.

5 / 5

Progressive Disclosure

Three well-signaled one-level-deep references, all verified to exist, each with a one-line description in 'Supporting Techniques' plus inline pointers (Phase 1.5 gives a 'Quick version' then defers to references/root-cause-tracing.md); companion files (find-polluter.sh, condition-based-waiting-example.ts) are correctly nested one level further inside their parent references. Fits 'Good structure; most content is appropriately placed; references mostly clear; minor organization gaps' — not 5 because the 285-line body is a full process document rather than a lean overview, with the ~30-line inline multi-layer bash example being detail that could live in references/, mirroring how root-cause-tracing.md handles its quick version.

4 / 5

Total

16

/

20

Passed

Description

92%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: it states concrete capabilities in third person, provides natural trigger phrases, and adds explicit boundary guidance that sharply reduces conflict risk. The only gap is modest keyword coverage — a few common user phrasings for debugging requests are absent.

DimensionReasoningScore

Specificity

Lists multiple specific concrete actions — 'reproduce the issue, trace the data flow, form and test one hypothesis at a time, then implement and verify the fix' — giving comprehensive coverage of the debugging workflow in third-person voice ('Investigates'). It clearly matches the anchor 'Lists multiple specific concrete actions; comprehensive coverage' rather than the 4 anchor, which expects minor gaps in coverage.

5 / 5

Completeness

Explicitly answers both what ('Investigates a test failure, bug, or unexpected behavior to find its root cause before proposing any fix' with a concrete action chain) and when (concrete trigger phrases plus workflow context: 'entered by requests like ... once delivery-flow has handed off a bug'). This matches the anchor 'Clearly and explicitly answers both what AND when with concrete trigger phrases'; the when-clause is explicit, so the completeness cap of 3 does not apply.

5 / 5

Trigger Term Quality

Includes natural phrases users would actually say ('debug this failure', 'why is this test failing', 'find the root cause', 'this bug keeps coming back') plus domain keywords ('test failure, bug, unexpected behavior'), but misses common variations like 'fix this bug', 'investigate this error', or 'something is broken'. Fits 'Good keyword coverage; a few natural terms missing' — not 5 because coverage is not fully comprehensive, not 3 because the quoted triggers are exactly the phrasing a user would naturally use.

4 / 5

Distinctiveness Conflict Risk

Has a clear niche (the debugging stage inside the delivery-flow workflow) with distinct triggers and explicit negative boundary guidance ('Do not activate directly for a standalone bug report that has not gone through delivery-flow first'), which minimizes conflict with generic debugging skills. Matches 'Clear niche with distinct triggers; minimal conflict risk' rather than 4, where overlap risk would remain.

5 / 5

Total

19

/

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

tesslio/tessl-eval-demo

Path

03-ablation/versions/full/sdlc-implementation/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.