The Untold Truth

Spoke 6 of 6 in the spec-driven development series. Previous: The Audit.

TL;DR. The discipline is free and needs no tool: every artefact in this series is a markdown file you could write yourself. The tools people reach for to automate it, agent skills, are a real supply-chain problem that already went off in February 2026, not a future risk. Skills can act through your agent’s permissions and steer its reasoning by prompt injection, and scanning them is a floor, not a verdict. So read any skill before you run it; if it wants more than its job needs, that gap is the finding. Every skill in this pack is pure markdown you can audit in five minutes, which is the whole point.

Everything in the five posts before this one runs on markdown files and paying attention. No CLI. No subscription. No skill. I want to be blunt about that before I do anything else, because the entire rest of the internet writing about spec-driven development has a commercial reason not to be, and you should hear it plainly from someone who isn’t selling the tool.

And then I want to talk about the tools anyway, specifically the agent skills you were probably about to install to automate this, because they are a genuine security problem, the problem already went off once this year, and almost nobody outside the security press noticed.

Two arguments, then. The discipline is free. And the convenience is more dangerous than you think.

A note on the second one before I start: everything I claim about skills security below is sourced, and the sources are named inline and listed at the foot with dates and exactly what each one established. This is a fast-moving area and most of what gets written about it is either vendor marketing or secondhand panic. I’d rather you could check every number than take my word for it. That’s the whole ethic of this series, and it would be a poor look to abandon it in the post about not trusting things you can’t check.

The discipline is free

Go back through the series and look at what each stage actually required.

Forming the spec: a problem brief and a spec document, both markdown, both just structured thinking written down. Decomposing: a task list. Building without drift: a rules file and a not-building list, compared against a diff by a human being reading. Proving it: tests, which you were already writing, pointed at criteria instead of at code. The audit: a table, and ninety minutes, and someone who didn’t build the thing.

None of that is a product. All of it is discipline, the willingness to be specific before you build, and to check afterwards. That willingness is the entire method, and it is precisely the part no tool can install for you.

There are good tools in the space. GitHub’s Spec Kit, Amazon’s Kiro, OpenSpec, BMAD, a dozen others, and some are genuinely well made. They give you file structures, slash commands, a place to put things, a bit of automation around the edges. What they cannot give you is the thing that makes spec-driven development work, because that thing is a habit, and habits don’t come in a package. It’s the gym membership again: the membership is not the exercise, and the person already running every morning gets no fitter for buying one.

My experience, and I’ll flag it as experience, not a measured result, is that a team with a spec file, a not-building list, and the habit of checking their work against both tends to outbuild a team with the entire toolchain and no habit. I’ve watched it go that way more often than not. The reason, when it does, is that the toolchain was never the constraint. Your own precision was.

So if you take one thing from six posts: you do not need to buy or install anything to start doing this. You need a text editor and the discipline to be specific. Everything else is convenience, and now I want to talk about what one particular convenience costs, because the bill is steeper than the marketing suggests.

The convenience already exploded

Here’s the framing I want to correct, because I’ve used it myself and it’s wrong in an important way. People say agent skills are “the next npm,” the next big supply-chain disaster waiting to happen.

They’re not the next anything. Something already went off. It happened in February 2026, in the public skill registries, and it stayed almost entirely inside the security press while everyone else kept installing.

A note on the numbers below. Every figure in this section is stated as it was reported at the time of publication, and it’s accurate as of then. This is a fast-moving area, the figures will date, and I am not going to keep them updated. Treat them as a dated snapshot with sources, not a live count. If it matters to you now, check the primary sources in the ledger at the foot.

On the 5th of February 2026, Snyk published what it called the first comprehensive security audit of the agent-skills ecosystem, under the name ToxicSkills. The scope matters, so hold onto it: they scanned 3,984 skills from two specific registries, ClawHub and skills.sh, as they stood on that date. Within that corpus, Snyk reported that 36.82% (1,467 skills) contained at least one security flaw, 13.4% (534) carried at least one critical-level issue, and human review confirmed 76 skills with active malicious payloads, of which, Snyk said, 8 were still live and installable on ClawHub the day they published.

Read those as what they are: one vendor’s findings about one snapshot of two registries. They are not a measured prevalence rate for “skills” in the abstract, and Snyk is not a disinterested party, they sell security tooling. That doesn’t make the numbers wrong; it makes them a named claim you can go and check, which is exactly how I’d want you to treat any number in this post, including the ones that support my argument.

Snyk also framed the risk to an individual installer directly. Their line was that if you’d installed a skill from that corpus in the preceding month, there was roughly a one-in-eight chance it carried a critical-level issue. I’d treat that as rhetorical rather than statistical: a corpus-wide proportion isn’t a given person’s odds unless their installs were a random draw from the corpus, which yours weren’t. The honest version is the plain one, Snyk classified 13.4% of the skills in its February sample as containing at least one critical-level issue. That’s alarming enough without converting it into a personal betting line.

That wasn’t a lone finding. Around the same time, Antiy CERT and others documented a coordinated campaign, ClawHavoc, against the ClawHub registry specifically; Antiy put the number of poisoned skills above a thousand, while other trackers counted a few hundred confirmed malicious. Either way it was a deliberate, organised poisoning of a single ecosystem’s registry, not a stray bad upload. And Snyk credited researchers at OpenSourceMalware.com with documenting, in the same window, the first coordinated campaign specifically aimed at Claude Code and OpenClaw users, using 30-plus malicious skills on ClawHub.

Then, in late April 2026, OWASP launched an Agentic Skills Top 10, a dedicated project cataloguing the top security risks in agent skills across the OpenClaw, Claude Code, Cursor and VS Code ecosystems. I’ll be careful about what that does and doesn’t prove: it’s a project that launched, authored and peer-reviewed by security people, and at the time of writing it’s an incubating effort still filling out its ten entries rather than a finished, ratified standard. Its existence tells you serious people think this surface is worth a dedicated framework. It doesn’t, on its own, prove maturity, the thing that shows maturity is the incident record above, which is why I led with that and not with the project.

Why it’s worse than npm in one specific way

The npm comparison gets reached for constantly, and it’s useful as long as you don’t let it flatten the actual difference. Let me be fair to npm first, because the lazy version of this argument isn’t true.

A malicious npm package is not harmless-until-runtime. Install scripts run on npm install; a compromised transitive dependency can read your environment, your source and your files, execute arbitrary commands, and phone home, and npm’s reach into real production systems is enormous. So “npm just steals a token, skills do everything” is wrong, and I’ve seen people argue it. Don’t.

The real difference is narrower and it’s this: a malicious skill can act through whatever tools and permissions its host agent has been granted, and for a coding agent, that’s typically the filesystem, the shell, whatever credentials are in the environment, and the network, while also steering the agent’s own reasoning through natural-language prompt injection. That second channel is the genuinely new thing. It isn’t just running code in your environment; it’s manipulating the thing you trusted to decide what code to run. npm malware has to hide from tools. Skill malware can additionally argue with the operator’s assistant, in English, and win.

How far that actually reaches depends on the agent, the sandbox, the approval policy, what credentials are lying around, and the network configuration. A skill run inside a locked-down, no-network, no-credentials sandbox can do far less than one run by an agent with your shell and your cloud keys. The threat is real; the reach is configuration-dependent, and anyone who tells you a skill always has your keys is overselling. What’s fair to say is: a skill can do whatever its host agent can do, and most people run their agent with rather a lot of latitude.

On the barrier to entry the picture is genuinely bad, and here the scoping helps rather than softens. On ClawHub, publishing a skill took a markdown file and an account, no code signing, no security review, no sandbox by default on the registry side. Snyk reported daily submissions to ClawHub going from under 50 in mid-January 2026 to over 500 by early February, a tenfold jump in weeks, with vetting capacity nowhere near it. That’s the specific registry the campaigns targeted, and the specific reason they could.

The sharpest detail, scoped honestly

There’s a finding that gets repeated as a universal law of skills, and it isn’t one, but the true, scoped version is bad enough.

Check Point Research disclosed two vulnerabilities in Claude Code specifically, CVE-2025-59536 (CVSS 8.7) and CVE-2026-21852 (CVSS 5.3), made public on 25 February 2026, showing that repository-controlled configuration files, the project’s .claude/settings.json hook entries and project-level settings, could trigger arbitrary command execution and API-key exfiltration at project-open time, before any user-consent dialog appeared. So: simply cloning and opening an untrusted project could run attacker code before you were asked to trust anything.

That is the concrete basis for the scary general claim you’ll see, “skill instructions run before the agent’s safety reasoning engages.” It’s true, and it’s serious, but as demonstrated it’s a property of specific Claude Code project-configuration mechanisms with specific CVEs and patches, not an inherent law of every skill format everywhere. Cite it as what it is. The lesson survives being scoped: on at least one major agent, untrusted repository files have been shown to execute ahead of any consent prompt, which means “the model will notice something’s off” cannot be your defence, on that path, the thing was done before the model, or you, got a vote.

“I’ll just scan them” is not the answer

The obvious response is to scan skills before installing. Run them past a detector. Scanning helps, there are decent tools now, but it’s a floor, not a verdict, and the reason is built into what these attacks are.

Much of the malicious behaviour is prompt injection: natural-language instruction manipulation, not a code signature. A malware scanner looks for malware. It does not reliably catch a paragraph of plain English that talks your agent into something, because that paragraph isn’t malware in any form a signature matches, and researchers have shown injected instructions hidden in invisible Unicode characters, so what a scanner (or you) sees isn’t even what the agent reads. Snyk itself published a follow-up arguing a skill scanner can become false security, or be the malware. And separately, a proof-of-concept documented via the OWASP project, the “Story of Skills” work, bypassed scanners by serving its payload from an external URL the scanners never fetched, and projected a possible reach of around 26,000 agents. Those are two different results from two different sources; I’m not merging them into one study, and neither should you.

So scanning catches the lazy stuff and misses the stuff built to be missed. If your whole defence is a green badge from a scanner, your defence is that the attacker wasn’t trying. Some of them are trying.

The audit takes five minutes. Do it.

Here’s the thing that actually works, and it’s not sophisticated: read the skill before you run it. All of it. And most of the time you’ll find you didn’t need it.

The checklist, it’s in the action pack as a template, is short. Who publishes it, and does the account have any history, or was it created last week? Can you read the source before installing, or does installing come first? Does it bundle scripts, or is it just instructions? Does it use any load-time command execution, the mechanism the Check Point CVEs abused? Does it make network calls, and where to? Does it read your environment, your credentials, anything outside the repo you’re working in? Does it match its own description, or does the markdown-formatter also want to read your git remotes? Is anything obfuscated, invisible characters, encoded blobs, because there is no innocent reason for an obfuscated markdown file?

If you can’t read the whole thing in five minutes, it’s too big to audit, which means you won’t, which means you’ll trust it blind, so don’t run it. If it ships code you don’t understand, don’t run it. If it phones home, don’t run it. If it wants your environment and it’s supposed to format your CSS, that gap between what it asks for and what it needs is the finding, and there’s rarely a second more obvious one.

The sum nobody does

Now the argument that makes all of this matter, because it’s the one that turns “be careful” into “mostly, don’t bother.”

Every dependency is a trade: capability in, risk in, and the only question worth asking is whether the capability is worth the risk. For npm the trade is often close to forced, a lot of production JavaScript depends materially on npm packages, and vendoring or hand-rolling everything isn’t realistic, so you accept a large supply-chain exposure because the alternative is not shipping. It’s not literally unavoidable, you can ship browser JavaScript with no package manager, vendor dependencies, or lean on platform APIs, but for most real projects it’s load-bearing enough that “just don’t use npm” isn’t an answer.

Skills are not usually like that. A skill is, most of the time, a convenience. And when you install one to help you do spec-driven development, a method whose every artefact is a markdown file you could write yourself in twenty minutes, you’re accepting a serious class of risk (arbitrary action through your agent’s permissions, plus a channel straight into its reasoning) to save yourself twenty minutes of typing.

Nobody runs that sum. The install is one command, the twenty minutes feels like a lot when you’re busy, and the risk lands on future-you, or on the client, or on nobody until it lands on everyone. So the trade gets made without anyone doing the arithmetic, and the arithmetic is usually damning: you took real supply-chain risk to avoid writing a file.

That’s the asymmetry, and it’s the one control here that actually scales. npm you’re often stuck with. A skill you can almost always simply decline, and declining is free, total, and needs no scanner.

Which is why this pack ships skills you can read in five minutes

There’s an obvious objection sitting under all of this. I’ve spent a series telling you to be specific and check your work, I’m handing you an action pack, and the pack contains skills. Having told you to be wary of skills, I’m giving you some.

That’s only a contradiction if mine ask for your trust blindly, so they don’t. Every skill in this pack is pure markdown, no bundled scripts, no executables, nothing to compile. None use load-time command execution, the mechanism the Check Point CVEs abused; the pack’s own audit template explains why you shouldn’t accept skills that do. None make a network call. None read your environment, your credentials, or anything outside the repository you point them at, and the one that reads a repo to document it, spec-recover, explicitly skips secret files and never copies a secret into its output. Every one opens by stating, in plain English, what it touches and what it doesn’t, so you can audit it without reading to the end. Each is short enough to read in a few minutes.

But I want to be honest about what that does and doesn’t buy, because the alternative would be the exact overclaim this post warns about. Stripping a skill back to markdown removes the script and network attack surface. It does not make the instructions inside it automatically trustworthy, a pure-markdown skill can still carry a prompt injection, or steer an agent into destructive action through the agent’s own legitimate tools. That’s the whole reason the checklist’s real instruction isn’t “check it’s markdown,” it’s “read it yourself, and ideally have someone who didn’t write it read it too.” Mine are built to make that read fast and to survive it. They are not asking you to skip it. The right posture towards any skill, including these, is the one this series has argued for throughout: don’t trust it because it looks fine, check, then decide.

The demonstration underneath all this is the actual last lesson of the series: a skill that does a genuinely useful job needs almost none of the capabilities that make skills dangerous. Most of the red marks on a malicious skill come from a capability it never needed for the thing it claimed to do, the environment-reader that only had to format markdown, the CSS linter that wanted your git config. When a skill asks for more than its job requires, that gap is the finding.

You don’t need any of this. That’s the point of the whole post, and it’s the most honest thing I can tell you about a topic everyone else is trying to sell you. The discipline is free. The tools are optional. And the specific tools people reach for to automate the discipline sit on a supply-chain attack surface that has already been exploited at least once this year, so if you do reach for one, read it first, and notice how often, once you’ve read it, you find you could have just written the file.

That’s the series. The action pack has all eleven templates, including the Skill Audit Checklist from this post, with a worked example that audits a plausible, useful, five-star skill and finds it reading the environment into a variable called context, plus the spec-driven skills themselves, built to pass their own checklist. Free, ungated, markdown, because that is all this ever needed to be.

Claim ledger

Every factual claim above, its source, and exactly what the source established. Figures are named claims from the cited parties, not independently verified prevalence, and they are correct as of publication and not maintained after it. Where sources disagree, that’s noted rather than smoothed over.

• 3,984 skills scanned; 36.82% (1,467) with a flaw; 13.4% (534) critical; 76 confirmed malicious; 8 still live at publication. Source: Snyk, ToxicSkills (5 Feb 2026). Scope: ClawHub and skills.sh, as of 5 Feb 2026. These are Snyk’s findings about that corpus, not an independent prevalence rate.
• “Roughly one-in-eight if you installed one recently.” Source: Snyk’s own framing in the same post. Treated above as rhetorical, not statistical, a corpus proportion is not an individual’s odds. The defensible restatement is the 13.4%-critical figure.
• “Under 50 to over 500 daily submissions, Jan to Feb 2026.” Source: Snyk, ToxicSkills. Scope: ClawHub submission rate specifically.
• ClawHavoc: a coordinated poisoning of the ClawHub registry, 1,000+ skills (Antiy) / a few hundred confirmed malicious (other trackers). Sources: Antiy CERT and other security trackers, Feb 2026. Scope: the ClawHub and OpenClaw ecosystem. The count varies by source; the fact of a coordinated campaign does not.
• First coordinated campaign against Claude Code / OpenClaw users, 30+ malicious skills. Source: OpenSourceMalware.com, credited by Snyk (Feb 2026). Scope: ClawHub.
• OWASP Agentic Skills Top 10. Source: OWASP, project launched late April 2026. Status: an incubating project cataloguing agent-skill risks across OpenClaw, Claude Code, Cursor and VS Code, not, at time of writing, a finished ratified standard. Used above as evidence of attention, not of maturity.
• A skill inherits its host agent’s permissions and can also inject into its reasoning. Source: the general characterisation in Snyk’s report and the OWASP project. Caveat stated inline: actual reach is agent- and sandbox-dependent.
• Execution before the consent dialog: CVE-2025-59536 (CVSS 8.7), CVE-2026-21852 (CVSS 5.3). Source: Check Point Research, publicly disclosed 25 Feb 2026. Scope: Claude Code project configuration files (.claude/settings.json hooks, project settings), RCE and API-key exfiltration at project-open time. Not a universal property of all skill formats.
• Scanners can be evaded, or can themselves be false security. Sources: (a) Snyk follow-up on scanner false-security; (b) separately, the “Story of Skills” proof-of-concept documented via the OWASP project, which bypassed scanners via an external-URL payload and projected reach of ~26,000 agents; (c) invisible-Unicode concealment demonstrated by researchers. Three distinct results, kept distinct.

These figures are a snapshot as of publication and are not updated. If any of this matters to you now, check the primary sources before repeating the number. That instruction applies to me as much as to you.