CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

fix-learn-guards

Turn every verified fix into durable prevention — recipe library entry, shared helper or guard rule that fails CI on the bug class, a new static-scan rule and seeded bug for the tester — and prove the guard catches a fresh instance. Use after each VERIFIED verdict and at the end of each run.

68

Quality

85%

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

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

An exemplary instruction-only skill body: terse, sequenced, and validated, with explicit proof-of-guard, recurrence feedback, and exit criteria. The only improvement space is naming concrete locations for the recipe library and saved evidence, which keeps actionability at 4 rather than 5.

DimensionReasoningScore

Conciseness

The body is lean and imperative — each step compresses concrete content into a single line ('Add the recipe: class, root cause, correct fix, wrong fixes seen, tests, guard') with no concept explanations Claude already knows. The one anecdote ('one guard could never fire until this test exposed it') is a single line that directly justifies step 3's validation, so every token earns its place.

5 / 5

Actionability

Guidance is concrete and directive: named recipe fields, three guard mechanisms ('a shared helper or middleware... a lint/semgrep rule, or a type that makes the bad state impossible'), a scratch-branch proof procedure, and a calibration benchmark with a measurable target ('zero fake "done" claims'). Per the instruction-only scoring note the absence of code is not penalized, but minor gaps remain — the recipe library's location and where evidence is saved are unspecified.

4 / 5

Workflow Clarity

Six clearly sequenced steps with an explicit validation checkpoint (step 3: 'add a fresh instance of the class on a scratch branch; the guard must flag it'), feedback loops for error recovery (step 5: 'a recurring class means the guard is too weak'; step 6's calibration loop), and a closing checklist ('## Exit criteria' requiring saved evidence).

5 / 5

Progressive Disclosure

The skill is under 50 lines, self-contained, and needs no external references; sections (Procedure, Exit criteria, counterpart note) are well organized, satisfying the simple-skill exception for progressive disclosure. No bundle files exist, so there is nothing to misplace or bury.

5 / 5

Total

19

/

20

Passed

Description

71%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, specific description in third person with an explicit usage clause and a clearly distinct niche. Its main weakness is trigger-term coverage: the phrasing is internal-pipeline jargon rather than natural language a user would say when needing this skill, and it omits two procedure steps covered in the body.

Suggestions

Add natural trigger phrases users would actually say, e.g. 'Use when the user asks to prevent a fixed bug class from recurring, harden a fix, or build a regression guard' — this would raise trigger_term_quality from 3.

Mention the recurrence-tracking and fixer-calibration outcomes from the body (e.g. 'track recurrence per bug class and calibrate the fixer against a false-done benchmark') to close the coverage gap in specificity.

Clarify the trigger context slightly for users outside the pipeline, e.g. 'Use after each VERIFIED fix verdict (or whenever a fix is confirmed) and at the end of each run', making the when-clause user-recognizable as well as explicit.

DimensionReasoningScore

Specificity

The description lists several concrete deliverables — 'recipe library entry', 'shared helper or guard rule that fails CI on the bug class', 'static-scan rule and seeded bug for the tester', 'prove the guard catches a fresh instance' — but omits the recurrence-tracking and fixer-calibration steps present in the body, leaving minor coverage gaps.

4 / 5

Completeness

Both 'what' and 'when' are present — the what is a concrete set of deliverables and the when is explicit ('Use after each VERIFIED verdict and at the end of each run'). Not a 5 because the trigger phrase is internal pipeline jargon rather than a user-recognizable trigger like 'Use when the user asks to prevent this bug class from recurring'.

4 / 5

Trigger Term Quality

Terms like 'verified fix', 'guard rule', 'CI', and 'bug class' are relevant domain keywords, but the description misses natural user-facing variations such as 'prevent regressions', 'learn from this bug', or 'make sure it never happens again', so common synonyms are absent.

3 / 5

Distinctiveness Conflict Risk

The description carves a clear niche — converting verified fixes into CI-failing guards, static-scan rules, and seeded bugs — with triggers ('fails CI on the bug class', 'seeded bug for the tester') that no closely related skill would fire on, giving minimal conflict risk.

5 / 5

Total

16

/

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

itsablabla/qa-bug-agent-skills

Path

skills/fix-learn-guards/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.