CtrlK
BlogDocsLog inGet started
Tessl Logo
PluginPublic

testland/spec-testability-heuristics

Use when a user story, acceptance criterion, PRD section, API contract or PR description is about to go to implementation and someone needs to know which sentences can't be verified. Scores each claim as observable, decidable and bounded, rewrites weak ones and gives a BLOCK, REVIEW or OK verdict.

Quality

84%

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

Overview
Quality
Evals
Security
Files

Quality

Content

78%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 highly actionable, well-structured rubric with concrete failure signatures, rewrite tables, deterministic severity and verdict rules, and a clean single-reference bundle layout. Its main weakness is token efficiency: it quotes external glossary definitions of concepts Claude already knows and covers the same exclusions three times across the out-of-scope, Anti-patterns, and Limitations sections.

Suggestions

Trim the four verbatim ISTQB glossary quotations to a one-line citation or drop them entirely - the concepts of test oracles, equivalence partitioning, and boundary value analysis are already familiar, so only the links add value.

Merge the Limitations section into the 'What this skill judges, and what it does not' table (its three bullets repeat the Checking correctness, Assessing risk, and Checking completeness rows almost verbatim), cutting roughly 15 lines of duplication.

Collapse the Anti-patterns rows that restate the out-of-scope table (style-as-testability, typos, non-claims) into a single self-check line, keeping only the 'Make this more testable with no rewrite' row which adds new guidance.

DimensionReasoningScore

Conciseness

The body quotes four ISTQB glossary definitions (testability, expected result, test oracle, equivalence partitioning) whose concepts Claude already knows, and the Limitations and Anti-patterns sections largely restate the earlier out-of-scope table (e.g., "Testable is not correct" repeats "Checking correctness"), so it is mostly efficient but could be tightened.

3 / 5

Actionability

Each heuristic gives a failure signature with specific trigger words, untestable-to-testable rewrite tables, a deterministic severity table, an explicit verdict rule, and a copy-paste-ready output format with worked rows; per the instruction-only scoring note, this is fully executable guidance.

5 / 5

Workflow Clarity

"How to apply the rubric" provides six sequenced steps plus a four-step review workflow with a deterministic verdict computation, but there is no explicit validation checkpoint (e.g., re-checking each emitted finding against the failure signatures before verdicting), matching anchor 4's minor validation gap.

4 / 5

Progressive Disclosure

The single bundle reference ([references/worked-examples.md] under "## Worked examples") is real, one level deep, clearly signaled, and back-links to SKILL.md; the bulk worked-example content is correctly split out of a well-sectioned body.

5 / 5

Total

17

/

20

Passed

Description

83%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 description with an explicit 'Use when' trigger clause, concrete third-person action statements, and specific artifact types that users would naturally name. It clearly communicates both the skill's behavior and its invocation conditions. Its only weaknesses are a few missing natural synonyms and minor trigger overlap with neighboring review-type skills.

DimensionReasoningScore

Specificity

Names the domain and three concrete actions ("Scores each claim as observable, decidable and bounded, rewrites weak ones and gives a BLOCK, REVIEW or OK verdict"), matching anchor 4's several-specific-actions-with-minor-gaps; not 5 because aspects like severity assignment and the findings-table output are not stated.

4 / 5

Completeness

Explicitly answers both: what ("Scores each claim... rewrites weak ones and gives a BLOCK, REVIEW or OK verdict") and when ("Use when a user story, acceptance criterion, PRD section, API contract or PR description is about to go to implementation"), with concrete trigger artifacts.

5 / 5

Trigger Term Quality

"user story, acceptance criterion, PRD section, API contract, PR description" are natural terms users would say, but common synonyms like "spec", "requirements", or "testable" are absent, so it sits at good-but-not-comprehensive keyword coverage.

4 / 5

Distinctiveness Conflict Risk

The niche (verifiability of spec sentences before implementation) is distinct with specific artifact triggers, but "PR description" and general spec-review triggers create minor overlap with adjacent review/requirements skills, matching anchor 4 rather than minimal-conflict anchor 5.

4 / 5

Total

17

/

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