CtrlK
BlogDocsLog inGet started
Tessl Logo
PluginPublic

testland/reachability-analyzer

Runs dead-dependency analysis across JS, Python, and Rust projects using ecosystem-native static tools (`depcheck`/`knip` for JS, `vulture` for Python, `cargo-machete` for Rust), then cross-references the unused-dependency list against SCA findings to downrank vulns in code that is never loaded. Use when SCA output (from `osv-scanner`, `snyk-test`, or `npm-pip-maven-audit`) is too noisy to triage and the team needs to separate unreachable CVEs from exploitable ones before sprint planning; sibling cve-exploitability-triage ranks by EPSS/KEV exploitation signal, not code reachability.

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

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

A strong, well-structured skill body: executable commands for all three ecosystems, a complete cross-reference script, an explicit verification step with error-recovery guidance, and proper use of a single one-level-deep reference file. The only deductions are minor: repeated statements of the Fix-Backlog routing rule and a CI block that references a script path the bundle does not actually provide.

Suggestions

Consolidate the 'reachable: false routes to Fix-Backlog unless KEV' rule into a single authoritative statement — it currently appears in step 6, after the cross-reference script, and in the worked example.

Make the CI integration self-contained: either note that ci/annotate-reachability.py is the inline Python script saved at that path, or add it to a scripts/ directory in the bundle so the YAML block is copy-paste ready.

Give step 5's verification a concrete check (e.g., a one-line shell/Python assert for the non-empty file and populated reachable fields) so the checkpoint is as executable as the rest of the workflow.

DimensionReasoningScore

Conciseness

The body is dense and actionable with no padding that explains concepts Claude wouldn't know, matching 'Efficient; minor instances of over-explanation that could be trimmed'. Minor trims exist: the 'reachable: false routes to Fix-Backlog unless KEV' routing rule is stated three times (step 6, after the cross-reference script, and in the worked example), and the dead-dependency commands from step 2 are repeated in the CI integration block. Not 3 because every section carries unique actionable content; not 5 because the duplication is real and could be consolidated.

4 / 5

Actionability

Guidance is almost fully copy-paste ready: exact commands with flags per ecosystem ('npx knip --reporter json | jq -r \'.dependencies[].name\'', 'vulture src/ --min-confidence 90'), a complete executable Python cross-reference script, a worked example with a real CVE ID, and CI YAML. Two minor gaps keep it from 5: the CI block invokes 'python3 ci/annotate-reachability.py osv.json unused-deps.txt', a script path not present in the bundle (the reader must save the inline script there themselves), and step 5's verification ('assert unused-deps.txt is non-empty') gives no concrete assert command. Clearly above the anchor-3 pseudocode/incomplete level.

4 / 5

Workflow Clarity

The 7-step sequence is explicit and includes a dedicated validation checkpoint with an error-recovery feedback loop: step 5 says 'assert `unused-deps.txt` is non-empty and every finding... carries a populated `reachable` field... If the file is empty or a finding lacks the field, re-run the dead-dependency tool (a silent tool failure or the wrong workspace root is the usual cause) and re-annotate before proceeding.' This matches the anchor 'Clear sequence with explicit validation steps; feedback loops for error recovery' — it even diagnoses the likely failure cause for a batch-annotation operation.

5 / 5

Progressive Disclosure

SKILL.md is a well-structured overview (When to use / How to use / worked example / anti-patterns / limitations / references) that pushes per-tool detail — config files, exit codes, false-positive suppression — into exactly one one-level-deep, well-signaled reference: 'Full config, flags, exit codes, and suppression per tool: [references/dead-dependency-tools.md]'. The referenced file exists in the bundle and carries that detail, and the split is appropriate (quick-start commands inline, per-tool depth in the reference). Matches the anchor-5 pattern of clear overview with one-level-deep references and easy navigation.

5 / 5

Total

18

/

20

Passed

Description

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

An exemplary description: it names the concrete actions and per-ecosystem tools, states an explicit 'Use when' trigger tied to a real workflow moment (SCA output too noisy to triage before sprint planning), and proactively disambiguates from a sibling triage skill. No vagueness, over-claims, or voice violations detected.

DimensionReasoningScore

Specificity

The description lists multiple concrete actions with named tools per ecosystem: 'Runs dead-dependency analysis across JS, Python, and Rust projects using ecosystem-native static tools (`depcheck`/`knip` for JS, `vulture` for Python, `cargo-machete` for Rust), then cross-references the unused-dependency list against SCA findings to downrank vulns'. This matches the anchor 'Lists multiple specific concrete actions; comprehensive coverage' — run analysis, cross-reference, and downrank are all explicit. Not 4 because there is no coverage gap: the full pipeline from analysis to prioritization outcome is stated.

5 / 5

Completeness

Both 'what' and 'when' are explicit. What: 'Runs dead-dependency analysis... then cross-references the unused-dependency list against SCA findings to downrank vulns in code that is never loaded.' When: an explicit 'Use when SCA output... is too noisy to triage and the team needs to separate unreachable CVEs from exploitable ones before sprint planning' clause with concrete trigger conditions. This is the anchor-5 pattern of clearly answering both with concrete trigger phrases.

5 / 5

Trigger Term Quality

Natural trigger terms and synonyms are comprehensively covered: 'dead-dependency analysis', 'unused-dependency', 'SCA output', 'CVEs', 'vulns', 'too noisy to triage', 'code reachability', plus concrete tool names users would mention ('osv-scanner', 'snyk-test', 'depcheck', 'knip', 'vulture', 'cargo-machete'). This matches the anchor for comprehensive natural-term coverage including synonyms; nothing common is missing.

5 / 5

Distinctiveness Conflict Risk

The niche is distinct (reachability filtering of SCA findings via dead-dependency analysis) and it explicitly disambiguates from a sibling skill: 'sibling cve-exploitability-triage ranks by EPSS/KEV exploitation signal, not code reachability.' That active disambiguation exceeds the anchor-5 example, which merely has distinct triggers with no explicit sibling boundary.

5 / 5

Total

20

/

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