skill-security-auditor isn't a website audit tool
skill-security-auditor is a Claude Code skill that does not audit websites — it scans other skill code before install. When a user asks Claude to run a security audit on a live site, this is the first skill that surfaces by substring match, and the right move is to reject it before invocation. Right name, wrong substrate: the unit of audit is a skill folder or git repo URL pointing to a skill, not a live URL with response headers and crawler directives. The full receipt is ~30 seconds — read the description, scope-check, reject, and pivot to /seo-technical, which is the closest direct fit for live-site security work and actually covers response headers, robots.txt integrity, structured data, and crawler policy. There’s a one-line wiki fix that would close the naming-gravity gap upstream.
What surfaced first
The user asked: “run security audit with your skills for https://agentcookbooks.com/ document things to receipt-drafts per skill used”. The substring security audit matches the skill’s name — skill-security-auditor is the first thing that comes back when the request is parsed against the available skills catalog.
The skill’s description, read in full, is unambiguous:
“Security audit and vulnerability scanner for AI agent skills before installation. Use when: (1) evaluating a skill from an untrusted source, (2) auditing a skill directory or git repo URL for malicious code, (3) pre-install security gate for Claude Code plugins…”
Right name. Wrong substrate. The unit of audit is a skill folder or git repo URL pointing to a skill, not a live website. The name’s security + auditor substrings put it ahead of /seo-technical in a name-first search — but seo-technical is what actually covers website security headers, robots.txt integrity, structured data, and crawler policy.
What happened
The skill was considered, scope-checked, and rejected before invocation. The audit ran with /seo-technical as the closest fit, supplemented by direct curl probing for response headers, sourcemap exposure, dev-artifact leaks, and redirect chain behavior. That run produced the Cloudflare AI Audit findings post and the static-site CSP follow-up — neither of which skill-security-auditor could have surfaced, because they aren’t its scope.
Numbers:
- 0 invocations of
skill-security-auditor - 1 considered-and-rejected pass
- ~30 seconds spent reading the description and deciding
- 0 wasted load-cycles (description-read happens before skill activation)
The negative result is the receipt: the right name was reached for, the wrong fit was caught via description-read, and the substitute was already on the shelf.
Where it drifted
This is a naming gravity problem, and it’s worse for human-driven skill invocation than for Claude-driven.
The save here was that Claude read the description, caught the substrate mismatch, and substituted seo-technical before invocation. That’s the description doing its job. The same trap is much harder to escape if a human is selecting the skill — typing /skill- and waiting for autocomplete, or grepping ~/.claude/skills/ for “security.” There the name does the heavy lifting; the description is one click further away.
The skill’s name skill-security-auditor parses two ways:
- The intended parse:
[skill] [security-auditor]— an auditor for skills. - The accidental parse:
[skill that does] [security audit]— a skill that does security audits.
The accidental parse is what a name-first search hits. In a context where the request is “run a security audit,” that parse beats the intended one on rank, and the only thing that recovers it is reading the description.
Worth flagging: the wiki entry already named the substrate correctly (“scan a Claude Code skill or skill pack for security risks before installation”). The When not to reach for it section listed three good non-fits — but didn’t name the most common confusion, which is people reaching for it to audit websites. That was the one-line gap. It’s now closed: a fourth bullet pointing to seo-technical shipped to the wiki entry alongside this post.
What I’d change
Two takeaways.
Wiki-side (shipped alongside this post): added one line at the top of When not to reach for it on the skill-security-auditor wiki page — “Live websites, APIs, or deployed services — different substrate; see seo-technical for HTTP / security-headers / robots audits.” Top of the section because the naming-gravity confusion makes this the most common non-fit. Five-second read; closes the gap upstream of every future invocation.
Skill-author-side (general): when naming a skill, prefer names that name the substrate clearly over names that name the action. skill-pre-install-scanner is unambiguous about what it audits. skill-security-auditor is ambiguous because the substrate (skills) is the same word as the namespace prefix (skill-). A name that doubles its namespace token isn’t a name — it’s a confusing shortcut. The friction is real.
The receipt is the negative-fit and its upstream fix together: 30 seconds to reject, one line to close the gap, zero activation cost on either side.