CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/risk-coverage-mapper

Build-an-X workflow that produces a risk-to-test-coverage matrix - maps each risk in the product/release register to the tests / cases / monitoring that mitigate it. Walks the author through ingesting risks (from risk-matrix / product-risk-register-builder), inventorying test coverage (test cases via traceability-matrix-builder, automated tests via repo scan, production monitoring via observability dashboards), and computing per-risk coverage depth + identifying orphan risks (no coverage) + orphan tests (not linked to risks). Output is a Markdown matrix + executive summary. Use before a release sign-off or compliance audit, when the team must show which tests, cases, or monitors back each registered risk and which risks have nothing behind them.

79

Quality

99%

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

100%

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

A well-structured 7-step workflow with concrete, executable code, a worked end-to-end example, and clean one-level-deep progressive disclosure into a real reference file. It is lean, assumes Claude's competence, and keeps validation (CI gate, coverage-depth verdicts) where it matters.

DimensionReasoningScore

Conciseness

Lean and code-forward — seven steps are each backed by short code/tables rather than prose, and it assumes Claude's competence (no 'what a test case is' padding). Not below 3 because the overview, worked example, anti-patterns, and limitations each earn their tokens by being concrete rather than explanatory filler.

3 / 3

Actionability

Provides executable artifacts — a real `grep -r` scan, the `build_coverage_matrix` / `find_orphan_tests` functions, monitor YAML, and a CI workflow block. Not below 3 despite undefined adapter helpers (`load_matrix`, `testrail_search`) because the core matrix and orphan logic is complete and the helpers are clearly external integration seams rather than pseudocode standing in for real logic.

3 / 3

Workflow Clarity

Seven explicitly numbered steps (Ingest → Inventory → Build matrix → Emit → Orphan tests → Executive summary → CI) with a coverage-depth verdict table and a worked example tracing the same steps. Not below 2 because this is an analysis/reporting workflow (not destructive or batch-mutating), so the missing-feedback-loop cap does not apply, and the CI gate supplies a fail-on-uncovered-critical checkpoint.

3 / 3

Progressive Disclosure

SKILL.md is an overview that offloads the full output skeletons to references/risk-coverage-output-templates.md (verified to exist), referenced twice via clear markdown links and exactly one level deep. Not below 3 because the split is appropriate — the steps stay inline while bulky templates move to the reference file.

3 / 3

Total

12

/

12

Passed

Description

100%

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 that states concrete actions, an explicit 'Use when...' trigger tied to release sign-off / compliance audits, and a clear niche distinct from sibling traceability skills. Voice is third-person throughout, matching the rubric's requirement.

DimensionReasoningScore

Specificity

Lists multiple concrete actions — 'ingesting risks', 'inventorying test coverage', 'computing per-risk coverage depth', 'identifying orphan risks + orphan tests', and 'Output is a Markdown matrix + executive summary'. Not below 3 because the actions are specific and comprehensive, not just a domain label; the 'Build-an-X workflow' prefix is meta-noise but does not erase the concrete action list.

3 / 3

Completeness

Explicitly answers both what ('produces a risk-to-test-coverage matrix ... maps each risk ... to the tests / cases / monitoring that mitigate it') and when ('Use before a release sign-off or compliance audit, when the team must show which tests, cases, or monitors back each registered risk'). Not below 3 because a clear 'Use ...' trigger clause is present rather than only implied.

3 / 3

Trigger Term Quality

Natural domain triggers a user would actually say — 'release sign-off', 'compliance audit', 'which risks have nothing behind them'. Not below 3 because the 'Use before a release sign-off or compliance audit' clause covers the common ways this need surfaces.

3 / 3

Distinctiveness Conflict Risk

Clear niche — risk-to-test-coverage mapping — explicitly distinguished from the requirements-side 'traceability-matrix-builder'. Not below 3 because the triggers are specific enough that this would not fire for a generic test or risk skill.

3 / 3

Total

12

/

12

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.

Validation15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

referenced_paths_exist

Referenced path issues: 1 missing

Warning

Total

15

/

16

Passed

Reviewed

Table of Contents