CtrlK
BlogDocsLog inGet started
Tessl Logo
PluginPublic

testland/ai-spec-coverage-mapper

Use when a spec and a test suite both exist but nobody can say which requirements are covered, before a release sign-off, an audit or planning test effort. Uses an LLM to map existing tests to spec sections, outputs a coverage matrix per spec ID and names the gaps. It does not write new tests.

Quality

84%

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

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

Well-structured content with a strong worked example (input config, mapper prompt, output matrix, action items, trend) and an explicit verification loop that avoids the hallucination-trust anti-pattern. The main weakness is actionability: the central script is partly pseudocode with undefined helper functions and no config wiring, so it cannot actually produce the promised coverage matrix.

Suggestions

Make scripts/ai-coverage.py fully executable: define read(), extract_acs(), and read_all() (e.g., glob + regex extraction per the ac_extraction pattern) and wire the YAML config keys (spec_path, test_globs, ac_extraction.pattern) into the script via CLI args or a config loader.

Add the output-parsing/formatting step that turns the raw LLM response into the structured coverage matrix (per-AC tier, covering test names, action items, trend vs. prior run) shown in the worked example, or state explicitly that Claude must render the matrix from the raw response.

Trim duplication: the 'When to use' section restates the frontmatter description, and the Limitations/'reads code, doesn't run it' point plus the anti-patterns verification rows repeat guidance already covered in references/continuous-coverage-and-verification.md.

DimensionReasoningScore

Conciseness

The body is dense and example-driven with no conceptual padding Claude already knows — the Overview's line-vs-spec-section distinction is skill-specific framing, and the worked example demonstrates the deliverable rather than explaining trivia. Not 5: "When to use" repeats the frontmatter description almost verbatim, and Limitations ("The LLM reads code; doesn't run it") plus the anti-patterns table duplicate verification guidance already detailed in the reference file; not 3 because these are minor trim opportunities, not several padded sections.

4 / 5

Actionability

Concrete elements exist — the YAML config ("pattern: 'AC-(\\d+\\.\\d+):'"), a real openai.chat.completions call with a complete system prompt, and a fully specified output format — but the script is partially pseudocode: "spec_text = read(spec_path)", "ac_list = extract_acs(spec_text)", and "read_all(test_globs)" are undefined, the YAML config keys are never wired into the script, and "print(response.choices[0].message.content)" only dumps the raw response, so the code cannot produce the structured matrix shown. Not 4: these are missing key details rather than minor gaps; not 2 because the LLM-call core, prompt, and input/output formats are genuinely concrete.

3 / 5

Workflow Clarity

"How to use" gives a clear five-step sequence ("Point the mapper at the spec doc + the test globs" → "Run the LLM mapper" → "Read the coverage matrix" → "File one action item per gap" → "Schedule it weekly and verify the LLM's claims") with explicit validation for this batch operation, a feedback loop via the trend comparison ("Compare with prior run"), and an anti-patterns checklist ("Spot-check + cross-reference every high-priority AC"). Not 4: validation checkpoints are explicitly present inline and elaborated one level deep in the reference, satisfying the top anchor.

5 / 5

Progressive Disclosure

The bundle has a single, real, one-level-deep reference (references/continuous-coverage-and-verification.md) that is clearly signaled in three places with a description of its contents ("weekly CI scheduling and how to verify the LLM's coverage claims"), and the SKILL.md appropriately keeps the methodology and worked example inline while deferring cadence/verification detail. Not 5: the body's code comment "# scripts/ai-coverage.py" and the reference's CI step "run: python scripts/ai-coverage.py" both invoke a scripts/ path that does not exist in the bundle — a minor organization gap in the file structure.

4 / 5

Total

16

/

20

Passed

Description

88%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: it explicitly answers both what (LLM-based test-to-spec mapping, per-spec-ID coverage matrix, named gaps) and when (spec + test suite exist, release sign-off, audit, AC drift), with a concrete negative scope boundary. Weaknesses are minor — missing natural synonyms like "traceability"/"requirements coverage" and residual ambiguity around the broadly-used term "coverage".

DimensionReasoningScore

Specificity

Quotes: "Uses an LLM to map existing tests to spec sections", "outputs a coverage matrix per spec ID", "names the gaps", "It does not write new tests" — multiple specific concrete actions plus an explicit scope boundary, comprehensively covering the skill's capability. Not 4: no meaningful capability of the skill is left unnamed, matching the 'comprehensive coverage' anchor rather than 'minor gaps in coverage'.

5 / 5

Completeness

Quotes: "Use when a spec and a test suite both exist but nobody can say which requirements are covered, before a release sign-off, an audit" — an explicit 'Use when' clause with three concrete trigger scenarios, paired with a clear, concrete 'what' (map tests to spec sections, coverage matrix per spec ID, name gaps). Not 4: both what and when are explicit with concrete trigger phrases, satisfying the top anchor even though the trailing "or planning test effort" phrase is awkwardly worded.

5 / 5

Trigger Term Quality

Quotes: "spec", "test suite", "which requirements are covered", "release sign-off", "an audit" — good coverage of natural phrases a user would say. Not 5: common synonyms and variations such as "traceability", "requirements coverage", or "spec coverage" are absent; not 3 because several genuinely natural user phrases are present, not just generic keywords.

4 / 5

Distinctiveness Conflict Risk

Quotes: "coverage matrix per spec ID", "names the gaps", "It does not write new tests" — a mostly distinct niche with an explicit boundary against test-generation skills. Not 5: the keyword "coverage" is contested in QA ecosystems (line coverage vs. spec coverage tools), leaving minor overlap risk with closely related coverage-reporting skills; not 3 because the spec/requirements framing keeps the niche far clearer than a generic skill.

4 / 5

Total

18

/

20

Passed

Validation

93%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

referenced_paths_exist

Referenced path issues: 1 missing

Warning

Total

15

/

16

Passed

Reviewed

On this page