CtrlK
BlogDocsLog inGet started
Tessl Logo
PluginPublic

testland/test-removal-criteria

Use when a suite has outgrown its value and someone is about to delete tests. Sorts candidates into duplicate, tautology, trivial, dead-signal and orphan, and deletes only when all four gate conditions hold, with a written reason, coverage evidence and a named reviewer.

Quality

94%

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

Overview
Quality
Evals
Security
Files

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.

The body is a well-engineered decision procedure: concrete classification signals, a conjunctive delete gate with missing-input-as-failure semantics, an executable fold example, a worked example, and a complete anti-patterns table, with deep heuristics and report templates correctly pushed to two real, one-level-deep reference files. Its only cost is deliberate redundancy — the gate rules and never-batched/never-remove points are restated across four sections, which could be tightened without losing any decision content.

DimensionReasoningScore

Conciseness

The prose is tight, declarative, and assumes Claude's competence — it never explains what a test suite or coverage tool is, and the Meszaros/Fowler quotes carry decision weight rather than padding (so not the score-3 anchor, which requires unnecessary explanation). It falls short of the lean-every-token anchor because the same rules are restated across sections: 'Never batched' appears in the Step 1 table, Step 2, Step 4, and the anti-patterns table, and the gate conditions recur in the burden-of-proof rules, never-remove list, Step 3, and anti-patterns — deliberate reinforcement that could be trimmed without losing any decision.

4 / 5

Actionability

Guidance is fully executable for an instruction-only skill: the 'normalized (describe-path, normalized-setup, normalized-assertion-arguments)' signature, the four gate conditions with 'A missing input is a failed condition, not a skipped one', the executable test.each fold example, the ledger/kept-table columns, and a seven-row worked example with file:line candidates covering every class. Every rule names exactly how to apply it, matching the fully-executable anchor.

5 / 5

Workflow Clarity

The five-step sequence is explicit and ordered, and for a destructive batch operation the validation is built in: the delete gate is a conjunctive checkpoint where 'any failed or missing-input condition reverts the verdict to keep', the kept table records 'the failing condition named' as the feedback record, and the never-remove list plus the three-question dead-signal checklist act as checklists. This matches the explicit-validation-with-feedback-loops anchor; the worked example's gate-failure rows demonstrate the recovery path.

5 / 5

Progressive Disclosure

The SKILL.md holds the decision core while both referenced files exist and correctly absorb the deeper material: 'the full method per class - normalized signatures, detection heuristics, code examples, the dead-signal thresholds and reviewer checklist' in references/applying-the-removal-classes.md, and 'templates and the confidence-to-action rules' in references/removal-ledger-and-report-format.md. References are one level deep, each link is signaled with a description of its contents, and the split (decision logic in SKILL, method and recording format in references) is appropriate — matching the clear-overview anchor.

5 / 5

Total

19

/

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.

This is a strong description: it states a concrete what (five named removal classes plus a four-condition gate with reason, coverage evidence, and named reviewer) and an explicit when anchored to the natural trigger moment of someone about to delete tests. The only gap is minor keyword breadth — synonyms like 'remove', 'prune', or 'cleanup' would broaden natural-term coverage.

DimensionReasoningScore

Specificity

The description lists multiple concrete actions with named mechanics: 'Sorts candidates into duplicate, tautology, trivial, dead-signal and orphan, and deletes only when all four gate conditions hold, with a written reason, coverage evidence and a named reviewer.' Five named classes plus gate conditions and evidence requirements comprehensively cover the skill's capability, matching the comprehensive-coverage anchor rather than the minor-gaps anchor below it.

5 / 5

Completeness

Both questions are explicitly answered: the when is 'Use when a suite has outgrown its value and someone is about to delete tests', and the what is sorting into five named classes with a four-condition delete gate plus reason/evidence/reviewer requirements. The trigger 'someone is about to delete tests' is a concrete trigger phrase, matching the explicit-both anchor; the score-4 anchor ('when' could be more explicit) does not fit since the when clause names the exact triggering situation.

5 / 5

Trigger Term Quality

Natural trigger phrases are present — 'a suite has outgrown its value', 'someone is about to delete tests', 'suite' — capturing what a user would say at the trigger moment. A few common synonyms are missing (e.g. 'remove tests', 'prune', 'cleanup', 'redundant tests'), which fits the good-coverage-with-a-few-missing-terms anchor rather than the comprehensive-synonyms anchor.

4 / 5

Distinctiveness Conflict Risk

The description carves a clear niche — deleting tests from a suite — with distinct triggers ('delete tests', the five class names) and no plausible confusion with adjacent skills like test selection or flaky-test handling. Minimal conflict risk matches the clear-niche anchor; the score-4 anchor's 'minor overlap risk with closely related skills' is not evidenced.

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.

Reviewed

On this page