Conciseness

The body is efficient and tool-specific — config JSON, commands, and tables with no explanations of concepts Claude already knows (the "Entry vs project" note is genuinely non-obvious Knip semantics). Minor trimmable redundancy keeps it below a 5: "Per the [Knip docs]." appears after Step 1, Step 5, and again in References, and the "When to use" section largely restates the frontmatter description.

Actionability

Fully executable, copy-paste-ready guidance covering the common cases: "npm init @knip/config", "npm install -D knip typescript @types/node", a complete knip.json, "npx knip --max-show-issues 5", the baseline command "npx knip --no-exit-code > knip-baseline.txt", GitHub Actions YAML, and a per-issue triage table with concrete actions. The only terse spot ("tags: [\"public\"]" config) is a minor edge-case detail, not a common-case gap.

Workflow Clarity

Seven clearly sequenced steps (install → configure entry → first run → plugins → limit output → CI gate → triage) with checkpoints present in the form of the Step 7 triage table ("Sometimes (public API)") and the anti-pattern guidance "Manual review first; --fix after baseline clean", so the destructive/batch cap at 3 does not bind. It falls short of a 5 because there is no explicit post-cleanup verification step (e.g., re-run knip to confirm a clean exit after deletions or npm uninstall).

Progressive Disclosure

No bundle files exist and none are needed: the skill is well-organized into short numbered sections and tables, and both references ([Knip docs], [Knip plugins page]) are external URLs that are one level deep and clearly signaled both inline and in a dedicated References section. Nothing inlined here belongs in a separate file, and the plugin list is correctly delegated to the external plugins page rather than duplicated.

Specificity

The description enumerates Knip's complete reporting scope — "to find unused files, dependencies, exports and class or enum members, aware of test entry points through its framework plugins" — plus the concrete action "Runs Knip on a JS/TS project". This is comprehensive coverage of concrete actions with no gaps, matching the top anchor rather than the "minor gaps in coverage" of a 4.

Completeness

Both questions are answered explicitly: "what" via "Runs Knip on a JS/TS project to find unused files, dependencies, exports and class or enum members", and "when" via the concrete trigger clause "Use after a feature or route is deleted and the project still compiles, or when package.json has dependencies nobody can explain". The explicit trigger guidance means the completeness cap of 3 does not apply.

Trigger Term Quality

Natural user phrasings are present — "after a feature or route is deleted", "the project still compiles", "package.json has dependencies nobody can explain", "unused exports" — giving good keyword coverage. However the headline terms "dead code" and "orphaned" never appear in the description itself (dead-code only surfaces in metadata keywords), so it falls short of the synonym-level coverage of a 5.

Distinctiveness Conflict Risk

It names the specific tool (Knip), the ecosystem (JS/TS), and distinct post-deletion/unexplained-dependency scenarios, creating a clear niche with minimal overlap risk. It is written in third person ("Runs Knip"), so no voice penalty applies to specificity.