CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

deflake

Stabilize a flaky test with a minimal, assertion-preserving fix — never by weakening or deleting the check.

Quality

80%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./.qwen/skills/deflake/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

88%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 body is an exemplary lean, opinionated procedure: a closed set of allowed fixes, hard rules that forbid flake-hiding workarounds, and an explicit verify loop with a failure escape hatch. The only notable gaps are the absence of any code snippets and reliance on external documents (prepare-pr skill, "Shared Rules") that are not part of this bundle.

DimensionReasoningScore

Conciseness

The ~58-line body is lean and assumes vitest competence: no concept explanations, no library introductions, every rule is load-bearing (e.g. "a fixed count of setImmediate turns elapses in milliseconds and races real I/O" is skill-specific rationale, not padding). It matches anchor 5; a 4 would require trimming some genuinely useful constraint.

5 / 5

Actionability

Guidance is concrete and specific: exact APIs ("testTimeout (3rd arg to it)", "vi.waitFor", "vi.useFakeTimers()", "seed the RNG", "pre-warm... in beforeAll"), an exact command ("npx vitest run <file>"), and a concrete escape hatch (write <workdir>/failure.md and stop). It falls short of anchor 5 because there are no copy-paste-ready code snippets and failure.md's expected content is only sketched.

4 / 5

Workflow Clarity

The sequence is clear (read the issue → read the test → apply the smallest allowed fix → verify → prepare PR/report) with explicit validation ("must pass every time" over repeated runs, then the standard verify gate) and an explicit feedback loop for failure (write failure.md and stop). This matches the anchor-5 pattern of clear sequence with validation and error recovery.

5 / 5

Progressive Disclosure

Sections are well-organized and appropriately sized for a single-purpose skill with no bundle files (references/, scripts/, assets/ do not exist). It loses a point because it points to ".qwen/skills/prepare-pr/SKILL.md" and "the Shared Rules" — clearly signaled but external to the bundle and unresolved within it, leaving "bilingual <workdir>/e2e-report.md (per the Shared Rules)" partially underspecified.

4 / 5

Total

18

/

20

Passed

Description

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

The description is concise and concrete with a strong distinctiveness hook ("flaky test", "assertion-preserving"), but it answers only "what" and never "when". Adding an explicit trigger clause and a couple of natural synonyms would lift the completeness and trigger-term dimensions substantially.

Suggestions

Add an explicit trigger clause, e.g. "Use when a test fails and then passes on a rerun of the same commit, when the user reports an intermittent/flaky/nondeterministic test failure, or when a CI run shows a non-deterministic test."

Include common synonyms users actually say — "intermittent test failure", "unstable test", "test flakiness", "nondeterministic test" — to improve trigger-term coverage.

Name the concrete fix classes briefly (raise timeouts, stabilize waits, seed randomness, isolate shared resources) to move specificity from one action to several.

DimensionReasoningScore

Specificity

"Stabilize a flaky test with a minimal, assertion-preserving fix" names one concrete action plus constraints, matching the '1-2 concrete actions, not comprehensive' anchor. It is not a 4 because the description does not list several specific actions, and not a 2 because the action named is concrete, not generic.

3 / 5

Completeness

The description clearly answers "what" (stabilize a flaky test with a minimal, assertion-preserving fix) but has no "Use when..." clause or equivalent explicit trigger guidance, which per the judging guidelines caps completeness at 3.

3 / 5

Trigger Term Quality

"flaky test", "stabilize", and "fix" are the natural phrases a user would say when they need this skill. A few natural synonyms are missing ("intermittent failure", "nondeterministic test", "unstable test"), which keeps it below the comprehensive anchor 5.

4 / 5

Distinctiveness Conflict Risk

"flaky test" is a distinct niche trigger with minimal conflict risk against unrelated skills. There is minor overlap risk with general test-running/verification skills, so it sits at anchor 4 rather than 5.

4 / 5

Total

14

/

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

QwenLM/qwen-code

Path

.qwen/skills/deflake/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.