CtrlK
BlogDocsLog inGet started
Tessl Logo

structured-debugging

Hypothesis-driven debugging methodology for hard bugs. Use this skill whenever you're investigating non-trivial bugs, unexpected behavior, flaky tests, or tracing issues through complex systems. Activate proactively when debugging requires more than a quick glance — especially when the first attempt at a fix didn't work, when behavior seems "impossible", or when you're tempted to blame an external system (model, API, library) without evidence.

69

Quality

83%

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

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 methodology is clearly sequenced with strong validation checkpoints and concrete, actionable guidance including a copy-paste exit template. The main weaknesses are mild redundancy between the cycle and the failure-modes section, and a broken reference to a missing worked-example file.

Suggestions

Create the referenced examples/headless-bg-agent-empty-stdout.md (or remove the dead reference) so progressive disclosure works as advertised.

Trim or fold the 'Failure Modes to Avoid' section into the relevant cycle steps to remove redundancy with steps already stated.

Move the worked examples and possibly the failure-mode detail into a separate referenced file to shorten the main body and improve progressive disclosure.

DimensionReasoningScore

Conciseness

The body is mostly efficient and useful, but the opening paragraph and the 'Failure Modes to Avoid' section partly restate themes already covered in the cycle, and some general debugging philosophy ('the natural instinct is to form a theory and immediately apply a fix') is padding Claude already knows.

2 / 3

Actionability

Although it is instruction-only with no executable code, the guidance is concrete and specific: 'identify the 2-3 places where your hypothesis makes a testable prediction', 'Prefer logging values over presence checks', a list of common instrumentation traps, and a copy-paste exit template ('Root cause: ... Evidence: ... Fix: ...').

3 / 3

Workflow Clarity

The 6-step cycle (Hypothesize, Design Instrumentation, Verify Data Collection, Run and Observe, Document Findings, Iterate) is clearly sequenced with explicit validation checkpoints ('believe the data', 'A test run that produces no data is wasted'), a 3-round escalation rule, and an exit checklist.

3 / 3

Progressive Disclosure

The body is well-organized into clear sections, but it is a ~190-line monolithic file with no bundle files split out, and its only external reference ('examples/headless-bg-agent-empty-stdout.md') points to a file that does not exist, so the reference is broken.

2 / 3

Total

10

/

12

Passed

Description

90%

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 is strong: it clearly answers what the skill does and when to use it, with natural, distinctive trigger terms. Its only weakness is mild verbosity and framing triggers as conditions rather than concrete actions, which keeps specificity just below the top anchor.

Suggestions

Lead with one or two concrete actions (e.g., 'Form, instrument, and verify hypotheses to root-cause hard bugs') so specificity reads as multiple concrete actions rather than trigger conditions.

Tighten the 'when' clause to reduce length without losing the distinctive triggers.

DimensionReasoningScore

Specificity

It names the domain and core approach ('Hypothesis-driven debugging methodology for hard bugs') plus many trigger scenarios, but it enumerates when-conditions rather than listing multiple concrete actions the way the anchor-3 example does; it is also somewhat verbose.

2 / 3

Completeness

It states the 'what' ('Hypothesis-driven debugging methodology for hard bugs') and gives explicit 'when' guidance via 'Use this skill whenever...' and 'Activate proactively when...', satisfying both halves.

3 / 3

Trigger Term Quality

Phrases like 'flaky tests', 'unexpected behavior', 'behavior seems "impossible"', and 'the first attempt at a fix didn't work' are natural things a user would actually say when they need this skill.

3 / 3

Distinctiveness Conflict Risk

It carves a clear niche (hard-bug methodology) with distinctive triggers such as 'first attempt at a fix didn't work' and 'tempted to blame an external system ... without evidence' that are unlikely to fire for routine development skills.

3 / 3

Total

11

/

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
QwenLM/qwen-code
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.