CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/input-domain-coverage-audit

Audits a test file's input-domain coverage per entry point across three axes: equivalence partitioning (clustering the literal values the tests actually pass, to infer which partitions are exercised), boundary value analysis (recorded n/a when the entry point declares no bound), and error/negative-path coverage (classifying every matcher as positive or negative and computing the negative-assertion ratio). Emits a PASS / SHALLOW / N/A verdict per axis per entry point, with the evidence that produced it. Owns whether the test data spans the input space, not whether an individual assertion is specific enough: matcher specificity belongs to `test-code-conventions`. Use when a test file's cases all look alike - every argument the same shape, every response a success, no thrown-error case - and the suite needs a defensible answer on whether it exercises more than one equivalence class before it is approved.

70

Quality

88%

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

85%

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

A well-structured, highly actionable audit skill: concrete verdict rules, a sequenced workflow with validation guards, and clean one-level-deep references that all resolve to real files. The only drag is conciseness, where repeated grounding-quotation framing adds tokens that could be trimmed without losing clarity.

Suggestions

Tighten the ISTQB grounding prose in Steps 2 and 3 — point once to references/grounding.md and drop the repeated inline framing, since the verbatim quotations already live there.

Consider collapsing the axis-definition paragraph after the three-axes table, which restates the ISTQB definitions already linked, to reclaim tokens.

DimensionReasoningScore

Conciseness

It assumes Claude's competence (no explaining what tests or coverage are) and is mostly efficient, but the repeated ISTQB quotation framing and discursive grounding pointers add tokens that could be tightened, matching the score-2 'mostly efficient but could be tightened' anchor rather than a fully lean 3.

2 / 3

Actionability

It gives fully concrete, executable guidance — a literal-clustering heuristic table, explicit PASS/SHALLOW/n/a verdict rules per axis, a negative_assertion_ratio formula, and a copy-ready output-format template — satisfying the score-3 anchor for specific, actionable instruction.

3 / 3

Workflow Clarity

A clear five-step sequence with explicit checkpoints — 'Score all three axes before deciding anything', n/a-as-validation-guard rules, and the evidence-required rule — provides the feedback loops and guards the score-3 anchor calls for.

3 / 3

Progressive Disclosure

SKILL.md is an overview with verbatim quotations and the full worked example split into one-level-deep, clearly linked references (grounding.md, worked-example.md), both of which exist as real bundle files — matching the score-3 anchor.

3 / 3

Total

11

/

12

Passed

Description

85%

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, third-person description that names concrete actions, an explicit use-when trigger, and a distinctive niche with a deliberate scope boundary. The only weakness is trigger-term breadth: the trigger is stated abstractly rather than as the range of phrasings a user would actually say.

Suggestions

Broaden the 'Use when' clause with the concrete shorthand a user would utter — e.g. 'all my tests pass the same arguments', 'no negative cases', 'tests look identical' — alongside the abstract phrasing.

Consider adding the most common single-word triggers ('shallow tests', 'input coverage', 'equivalence classes') so the description matches how the request is actually phrased.

DimensionReasoningScore

Specificity

Lists multiple concrete actions per axis — "clustering the literal values", "computing the negative-assertion ratio", and "Emits a PASS / SHALLOW / N/A verdict per axis" — matching the score-3 anchor for multiple specific concrete actions.

3 / 3

Completeness

It explicitly answers both what it does (audits three axes, emits verdicts with evidence) and when to use it via a clear "Use when..." clause, satisfying the score-3 anchor.

3 / 3

Trigger Term Quality

It surfaces natural phrasings ("cases all look alike", "every argument the same shape", "every response a success", "no thrown-error case"), but these are framed abstractly rather than as the breadth of shorthand a user would utter, missing common variations — closer to the score-2 anchor than the multi-variant score-3 example.

2 / 3

Distinctiveness Conflict Risk

It carves a clear niche — input-domain coverage — and explicitly hands matcher specificity off to `test-code-conventions`, so it is unlikely to trigger for the wrong skill.

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.

Reviewed

Table of Contents