Conciseness

Most sections carry non-obvious, dense guidance — 'in-memory counters silently become max × instances', the DNS-rebinding TOCTOU gap, 'trust follows who *wrote* a value, not which channel delivered it' — so it largely assumes Claude's competence. It is not anchor 5 because some space goes to concepts Claude already knows: the six-row STRIDE table with standard mitigations, the basic header/cookie lists, and the Common Rationalizations table (12 rows) restate familiar security platitudes alongside genuinely sharp entries ('The audit passed, so the dependency is safe').

Actionability

For an instruction-only skill, the guidance is fully concrete and executable: 'bcrypt (≥12 rounds)', 'about 10 attempts per 15 minutes', 'CSP starts from default-src 'self'', 'resolve **all** DNS records and reject any private or reserved address (loopback, link-local 169.254.169.254…)', 'grep the staged diff before committing', and a three-condition test for destructive paths (allowlisted root, minimum depth, ownership evidence). Per the rubric's code-vs-instruction note, the absence of code is not penalized when guidance is this specific.

Workflow Clarity

Multiple processes are clearly sequenced with checkpoints: the threat-model-first steps, the 4-step dependency process with explicit stops ('stop on disagreement or competing lockfiles', 'Never blanket-approve'), the Review Checklist, and the terminal Verification checklist with item-level acceptance criteria. It falls short of anchor 5 because there is no validate→fix→retry feedback loop — verification is a one-shot final checklist, and the destructive-path rule says 'log the rejected target and stop' without a recovery path.

Progressive Disclosure

The split is genuinely good: the body holds the rules, references/hardening-patterns.md holds implementations, every one of the 15 anchored links resolves to a real section in that file, and it is one level deep with a clear instruction ('Open the section you need when you reach that code, not before'). It is not anchor 5 because the body references '../../references/security-checklist.md' three times — including the entire Review Checklist section — yet no such file exists in the bundle's references/ directory; that path escapes the skill directory and does not resolve.

Specificity

The opening 'Hardens code against vulnerabilities' is broad, but the description names several concrete activities — 'auditing an input handler for vulnerabilities', 'checking a login flow is safe against the OWASP Top Ten', 'triaging package-manager audit findings', 'assessing supply-chain risk in a new package'. This matches anchor 4 (several specific actions, minor gaps); it is not anchor 5 because the core 'what' is a single general statement and hardening sub-activities the skill actually covers (secrets, headers, SSRF, LLM output) go unmentioned.

Completeness

Both parts are explicit: the 'what' ('Hardens code against vulnerabilities') and four 'Use when…' clauses with concrete trigger phrases spanning input handling, auth flows, dependency audits, and privacy compliance. The 'when' is far more explicit than the anchor-4 example ('Use when working with PDF files'), matching the anchor-5 pattern of what + when with concrete triggers; the single-sentence 'what' is clear and unambiguous.

Trigger Term Quality

Natural user phrasing is well covered: 'user input', 'authentication', 'login flow', 'untrusted data', 'user sessions', 'third-party services', 'supply-chain risk', 'GDPR, CCPA', 'package-manager audit'. Not anchor 5 because common synonyms a user would say are missing — 'secrets', 'XSS', 'injection', 'sanitize', 'hardening' beyond the verb form.

Distinctiveness Conflict Risk

Clear niche with distinct triggers: 'OWASP Top Ten', 'supply-chain risk', 'GDPR, CCPA', 'package-manager audit findings' would not plausibly fire a non-security skill. It is above anchor 4 because overlap risk is minimal — only 'building any feature that accepts untrusted data' is mildly broad, and even that is security-framed ('untrusted').