CtrlK
BlogDocsLog inGet started
Tessl Logo

dependency-audit

Use when reviewing a project's security posture, setting up CI pipelines, or responding to a reported vulnerability in a dependency.

44

Quality

44%

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

Fix and improve this skill with Tessl

tessl review fix ./skills/dependency-audit/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

57%

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

The content is well-structured for progressive disclosure: a lean overview that points to a real, one-level-deep reference file. Its weaknesses are conceptual padding Claude doesn't need, vague Check/Fix instructions, and the absence of a validation checkpoint after upgrading vulnerable dependencies.

Suggestions

Trim the Log4Shell/node-ipc background paragraph and the "Explain how supply-chain attacks work" directive; assume Claude's knowledge of supply-chain risk.

Make the Check/Fix sections concrete with the actual commands (e.g., `pnpm audit --audit-level=high`) instead of describing them in prose, or surface one minimal executable example inline.

Add an explicit verification step to the workflow, e.g. "After upgrading, re-run `pnpm audit` and run the test suite to confirm the CVE is resolved and nothing broke."

DimensionReasoningScore

Conciseness

The body is short, but the intro paragraph re-explains the Log4Shell/node-ipc supply-chain background and the "Explain" section directs Claude to explain how supply-chain attacks work — concepts Claude already knows, so it is mostly efficient but padded.

2 / 3

Actionability

The Quick Reference gives concrete guidance ("Run pnpm audit (or npm audit)", Dependabot/Snyk, committed lock file), but the Check/Fix sections are vague descriptions ("Check the project's dependencies... using the package manager audit command") and full executable examples are deferred to rule.md.

2 / 3

Workflow Clarity

Check, Fix, Explain, and Code Review form a loose sequence, but there is no validation/verification checkpoint (e.g., re-run audit or run tests after upgrading a dependency), which caps workflow clarity at 2 for a batch/risky operation.

2 / 3

Progressive Disclosure

The body is a concise overview with a clearly signaled, one-level-deep pointer — "For full implementation details, code examples, and framework-specific guidance, see references/rule.md" — and that reference file is real (209 lines), giving easy navigation.

3 / 3

Total

9

/

12

Passed

Description

32%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description has an explicit, naturally worded "Use when..." trigger clause covering several scenarios, but it never states what the skill actually does (audit dependencies for CVEs) and omits the most direct trigger terms like "audit" and "CVE". It is distinguishable in its dependency-vulnerability niche but the broader security-posture and CI triggers risk overlap.

Suggestions

Lead with an explicit capability statement, e.g. "Audit a project's dependencies for known vulnerabilities (CVEs) using package-manager audit commands." before the "Use when" clause, so both what and when are stated.

Add the direct trigger terms users would say — "audit dependencies", "check for CVEs", "vulnerability scan", "supply chain" — to improve trigger coverage.

Narrow the broad triggers ("reviewing a project's security posture", "setting up CI pipelines") to dependency-specific contexts to reduce overlap with general security and CI/CD skills.

DimensionReasoningScore

Specificity

Phrases like "reviewing a project's security posture, setting up CI pipelines, or responding to a reported vulnerability" name the domain and some actions, but frame them as situations rather than listing concrete capabilities; the skill never explicitly states it audits dependencies.

2 / 3

Completeness

The "when" is explicit and strong ("Use when reviewing... setting up... or responding to..."), but the "what does this skill do" is never explicitly stated; per the guideline to score only what is explicitly stated, the what is absent.

1 / 3

Trigger Term Quality

Natural phrases are present ("reviewing a project's security posture", "setting up CI pipelines", "vulnerability in a dependency"), but the most direct user terms — "audit", "CVE", "scan", "supply chain" — are missing even though the skill is named dependency-audit.

2 / 3

Distinctiveness Conflict Risk

"responding to a reported vulnerability in a dependency" is a distinct niche, but "reviewing a project's security posture" and "setting up CI pipelines" are broad enough to overlap with general security or CI/CD skills.

2 / 3

Total

7

/

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

metadata_version

'metadata.version' is missing

Warning

Total

15

/

16

Passed

Repository
thedaviddias/Front-End-Checklist
Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.