CtrlK
BlogDocsLog inGet started
Tessl Logo

creating-debug-tests-and-iterating

Use this skill when faced with a difficult debugging task where you need to replicate some bug or behavior in order to see what is going wrong.

48

Quality

50%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

High

Do not use without reviewing

Fix and improve this skill with Tessl

tessl review fix ./.agency/plugins/nori/skills/creating-debug-tests-and-iterating/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

50%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body delivers a usable debugging loop and concrete tool pointers in a compact form, but it is held back by placeholder/abstract steps, a broken numbering sequence, missing validation checkpoints, and a lack of well-signaled reference files. Tightening the loop with explicit pass/fail checks and real example paths would lift workflow clarity and actionability.

Suggestions

Add an explicit validation checkpoint inside the loop, e.g. 'Run the debug script; if it reproduces the bug, proceed to fix; if not, keep updating the script.'

Fix the numbering (the list jumps from 3 to 5) and replace placeholder paths like "./path/to/cli.sh" with a concrete minimal example so the snippets are copy-paste ready.

Trim the three near-duplicate language snippets for one CLI invocation to a single representative example, or split per-tool detail into a reference file to improve token efficiency and progressive disclosure.

DimensionReasoningScore

Conciseness

The body is short and mostly direct (e.g. "write scripts that test the application interfaces"), but the example block lists three near-identical language snippets for the same CLI invocation and pads the loop with redundant system-reminders, so some tokens are not earning their place.

2 / 3

Actionability

It gives concrete, runnable snippets (subprocess.run, exec) and named tools (playwright, tmux), but several steps are abstract ("identify the application boundary", "Analyze the output... do whatever you need to") and paths are placeholders ("./path/to/cli.sh"), so it is not fully copy-paste ready.

2 / 3

Workflow Clarity

The numbered list lays out a real loop (add logs -> run -> analyze -> update) with a feedback flavor, but there is no explicit validation checkpoint confirming the bug is reproduced or fixed, the numbering breaks (jumps 3 -> 5), and cleanup/other-tests steps are listed without sequencing detail.

2 / 3

Progressive Disclosure

Content is organized into short sections (Debug Testing, Example, Emulators), but there are no bundle files to offload detail to and the single external reference is to a different skill's path (.claude/skills/webapp-testing/SKILL.md) rather than a structured one-level-deep reference set.

2 / 3

Total

8

/

12

Passed

Description

50%

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 clear, natural trigger for reproduction-based debugging but reads as a single conditional sentence: it states "when" well while leaving "what it does" largely implied, and it lists only one concrete action. Tightening it into explicit capability-plus-trigger form with a couple of concrete actions would lift specificity and completeness.

Suggestions

Add an explicit 'what it does' clause naming concrete actions, e.g. 'Writes external test scripts that reproduce the bug, adds instrumentation logs, and iterates until the cause is found.'

Broaden trigger coverage with natural user phrasings like 'reproduce the issue' or 'figure out why something is failing' alongside 'debugging task'.

Reformat to the 'capabilities. Use when...' pattern so both what and when are stated explicitly, matching the rubric's top anchor.

DimensionReasoningScore

Specificity

It names the domain ("a difficult debugging task") and one concrete action ("replicate some bug or behavior"), but stops short of listing multiple specific actions like 'add logs', 'write a debug script', or 'clean up'; not comprehensive enough for a 3.

2 / 3

Completeness

It clearly answers "when" ("Use this skill when faced with a difficult debugging task...") but the "what does this do" side is only implied through the trigger rather than stated as a capability, so it lacks the explicit dual statement a 3 requires.

2 / 3

Trigger Term Quality

"debugging task", "bug", and "replicate" are relevant and natural, but common phrasings users actually say (e.g. "figure out why X is broken", "reproduce the issue", "why is this failing") are only partially covered; missing common variations keeps it at 2.

2 / 3

Distinctiveness Conflict Risk

The trigger ("difficult debugging task where you need to replicate some bug") carves a reasonably specific niche around reproduction-based debugging, but it could still overlap with general debugging or testing skills, so it is not fully conflict-free.

2 / 3

Total

8

/

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