Findings

1. 01

   78.7% of repositories that use AI coding tools configure only one of them.

   Their developers do not stop at one. Most run two to four AI tools, so every other assistant is left working that codebase with nothing to go on.

2. 02

   AGENTS.md was built to bridge tools. Only 18.3% of the repositories that use it or CLAUDE.md use both.

   The one cross-vendor standard is being adopted as a replacement, not a bridge. It moves the split, it does not close it.

3. 03

   Nine in ten repositories that ship both CLAUDE.md and AGENTS.md never connect them, so the second file is never read.

   The team maintains two contracts and gets the coverage of one, then blames the model for ignoring rules it was never handed.

4. 04

   26.3% of CLAUDE.md files run past the 200-line guideline Anthropic publishes in its own docs.

   Past that length a file does not just waste context. A 2026 study found it lowers the rate at which the agent finishes the job.

5. 05

   55.8% of instruction-file repositories grant no usable right to redistribute the file.

   The year gave these files install commands, directories, and marketplaces. The majority of what they distribute, nobody granted permission to distribute.

6. 06

   Signing adoption in the open corpus is zero: of 986 probed repositories, none sign their instruction files.

   The trust layer the industry built this year exists where a distributor requires it, and so far nowhere else. Trust is becoming a property of the channel, not the file.

7. 07

   5.0% of 219,024 scanned instruction files carry at least one deterministic safety finding.

   ClawHavoc was the loud version. This is the quiet base rate, in files agents load by default with no scan at all.

The bottom line. The world around the instruction file grew up this year: governed standards, an install command, a trust stack, a threat model. The files themselves have not caught up. They serve one tool in a multi-tool world, they are unlicensed for the distribution they are getting, and the trust layer built for them is, in the open corpus, used by nobody.

The instruction file stopped being a private convention between a developer and one tool. Over nine months it picked up neutral governance, a package-manager-style distribution layer, vendor catalogues, security taxonomies, and an incident record. The dates below are the spine of that story; the rest of Part I walks the three that matter most.

1. 9 Dec 2025

   The Linux Foundation forms the Agentic AI Foundation, with Anthropic’s Model Context Protocol, Block’s goose, and OpenAI’s AGENTS.md as founding projects. The instruction-file standard now has a neutral home.

2. Dec 2025

   Anthropic releases Agent Skills as an open standard (agentskills.io): a folder with a SKILL.md that packages instructions for any agent that loads it.

3. 15 Jan 2026

   The first large-scale audit of the new format posts to arXiv. Of 31,132 skills analysed, 26.1% contain at least one vulnerability pattern.

4. 20 Jan 2026

   Vercel ships the skills CLI and skills.sh, a directory and leaderboard for skill packages. Instructions get an install command.

5. 1 Feb 2026

   Koi Security discloses ClawHavoc: 341 malicious skills on ClawHub, the marketplace serving the OpenClaw agent. The format’s first documented poisoning campaign.

6. 17 Feb 2026

   skills.sh adds automated security audits from three vendors (Gen Digital, Socket, Snyk); skills flagged malicious are hidden from search and leaderboards.

7. Feb 2026

   ETH Zurich publishes the first controlled study of context files: over-specified files reduce agent success and add more than 20% cost. Lean beats long.

8. 13–26 Mar 2026

   A community RFC asks the Agent Skills spec to absorb cryptographic signing. The spec maintainer declines, pointing to the distribution layer instead.

9. 16 Apr 2026

   GitHub ships gh skill in public preview: install, search, publish, with version pinning and content-addressed change detection, deliberately not centralised verification.

10. 22 Apr 2026

    Google launches its official skills repository on the open Agent Skills format, announced on Day 1 of Cloud Next.

11. 19 May 2026

    NVIDIA announces Verified Agent Skills: scan, skill card, detached signature, verify at install, on the open spec. The same day, Google’s enterprise Skill Registry enters public preview.

12. 3 Jun 2026

    Andrew Nesbitt, who built Libraries.io and runs Ecosyste.ms, publishes the gap plainly: the trust machinery package registries spent a decade building mostly does not exist for skills.

The two formats that matter most ended the year under neutral governance or open specification, with the largest vendors publishing into them.

AGENTS.md spent its first year as an OpenAI repository convention. On 9 December 2025 it became a founding project of the Agentic AI Foundation, a directed fund under the Linux Foundation, alongside the Model Context Protocol and goose. By late February the foundation counted 146 member organisations. One caution for anyone citing this as settled: as of that date the foundation itself described the formal governance models for its three projects as still being defined, so AGENTS.md has a neutral home and a membership, not yet a finished constitution.

The Agent Skills format ran the same arc faster. Released by Anthropic as an open standard in December, it ended the spring as the format Google ships its official skills in, the format GitHub’s gh skillvalidates against, and the format NVIDIA chose for its verified catalogue. Google’s Gemini CLI documentation states it directly: a skill is “based on the Agent Skills open standard.” When the largest vendors publish into a competitor-originated format rather than forking it, the format has stopped being anyone’s product.

The one asymmetry worth recording sits inside Google. Its public repository is openly on the standard; its enterprise Skill Registry, in public preview since 19 May, requires the SKILL.md package structure but nowhere names the open specification, and describes itself as a secure, private repository. The format travels; the catalogue is the product. That split, open format underneath and proprietary distribution on top, is the shape most of the year’s vendor moves share.

Why it matters. Teams standardising their instruction files in 2026 are no longer betting on a vendor’s whim. The formats are governed or open, and the year’s entrants built on them rather than around them. The open question has moved up a layer: not what the file looks like, but who vouches for it. That is the next section.

The year’s defining argument was about where trust should live. The spec said: not here.

In March, a community RFC proposed building cryptographic signing into the Agent Skills specification itself: an ed25519 signature block in SKILL.md frontmatter, with publisher keys discoverable at a well-known URL. The spec maintainer declined to absorb it. His position, stated on 16 March, was that signing is “better implemented at the distribution layer”; on 25 March he added that it is “unlikely that we’d make it an official part of the spec.” The discussion remains open, so this is a stated maintainer position rather than a closed ruling, but the spec has held: as of 11 June its frontmatter defines no signing, verification, or trust fields at all. The companion implementation tells the same story from the tooling side. A pull request addingskills verify to the distribution CLI was opened on 15 March and remains unmerged; no released version of the CLI carries a verify command.

Then in May, NVIDIA shipped exactly what the maintainer had pointed at. Its Verified Agent Skills programme is a trust stack built entirely at the distribution layer, on the open spec: an open-source scanner the company says checks for both conventional risks and agent-specific ones, a machine-readable skill card per skill, a detached signature in the OpenSSF Model Signing format, and verification at install or in CI. Every one of the 207 skills in its catalogue ships the full set: SKILL.md, skill card, signature. And the catalogue distributes through skills.sh, a competitor’s registry, with a plain npx skills add nvidia/skills.

The community asked the spec for trust. The spec pointed at the distributors. NVIDIA built it there two months later.

The rest of the trust layer is assembling around the same point. skills.sh added three-vendor automated audits in February, grading every listed skill and hiding the ones flagged malicious. OWASP opened an Agentic Skills Top 10 project in the spring, an incubator-stage proposal with ten draft risk categories and a 1.0 release targeted for the fourth quarter of 2026 on its own roadmap. And the academic record arrived in January: the first large-scale audit of skills in the wild found 26.1% of the 31,132 it analysed carrying at least one vulnerability pattern, with skills that bundle executable scripts twice as likely to be affected.

One more entry belongs in this chronicle, and it is ours, so the interest gets declared rather than implied. Each trust stack above vouches only for its own shelf: NVIDIA verifies what NVIDIA publishes, Google’s registry holds what an enterprise stores inside it, skills.sh audits what it lists. Nothing in the buildout vouches across registries, and little of it reaches the developer outside an enterprise gate. That neutral corner is the one TomeVault works from: the same scans and grades applied across every major format and every source, free for individuals and teams alike, and the corpus they produce is the one Part II measures. Judge our numbers with that interest in view.

Andrew Nesbitt, whose Libraries.io and Ecosyste.ms spent a decade mapping package ecosystems, closed the season with the sentence the whole year had been spelling out: “trusted-publishing and provenance attestations are the answers package registries arrived at; the equivalents for skills are mostly absent.”

Why it matters. The market has decided where trust attaches: to catalogues, registries, and install tools, not to the file format. Whoever distributes the file is being asked to vouch for it. Part II measures how far that ambition has reached into the open corpus. The short answer is: it has not.

The threat the trust layer exists for stopped being hypothetical on 1 February.

ClawHub is the skill marketplace serving OpenClaw, one of the fastest-growing open agents of the winter. On 1 February, Koi Security disclosed that of the 2,857 skills then on the marketplace, 341 were malicious, 335 of them from a single campaign it named ClawHavoc. The mechanism was social engineering embedded in the instruction file itself: a SKILL.md telling the user that installation required a companion utility, fetched from a link, sometimes inside a password-protected archive. The payloads were a macOS credential stealer, reverse shells, and environment exfiltration. By Koi’s 16 February update its count had more than doubled, to 824.

Antiy CERT’s follow-on analysis five days later credited Koi’s discovery and added its own telemetry: at least 1,184 malicious skills had appeared on the marketplace historically, twelve uploader identities were involved, and one account alone had published 677 packages. The marketplace responded inside the week, removing the reported skills, shipping a user-reporting mechanism that auto-hides any skill flagged by three distinct users, and appointing a security lead with a public roadmap pledge.

Three numbers circulate for this incident, and they measure different things: 341 is the initial disclosure, 824 is the discoverer’s revised count two weeks on, and 1,184 is one CERT’s cumulative historical estimate. Any of them supports the same conclusion. A marketplace of plain-text instruction files was poisoned at scale, within months of the format appearing, by attackers who needed no exploit beyond the file format’s own credibility.

Why it matters. Every layer of the year’s trust buildout, the scanners, the audits, the signatures, the taxonomies, is a response to exactly this class of attack. ClawHavoc is why the question Part II asks about the open corpus, who scans it, who licenses it, who signs it, stopped being academic.

Every AI coding tool reads its instructions from a file in the repository. Claude Code reads CLAUDE.md. Cursor reads .cursorrules and .cursor/rules. Copilot reads .github/copilot-instructions.md. Gemini, Windsurf, and the cross-vendor AGENTS.md convention each read their own, and the Agent Skills format packages instructions for any agent that loads them. That file is the closest thing a team has to a contract with its AI tools: this is the stack, these are the rules, this is how we work.

Developers no longer settle on one of these tools. Industry surveys throughout 2026 put the typical engineer at two to four AI coding tools at once, commonly one assistant for editing and another for larger agentic work, and the market has no single winner. So the question that matters is not which tool a team picks. It is whether the contracts in their repository serve the several tools their developers actually use.

Sections 06 to 09 measure that gap across 35,830 symmetrically probed repositories: which tools each repository addresses, whether the files connect, and whether their length follows the vendor’s own guidance. Sections 10 to 13 are new to the annual edition and widen the lens to the full 267,228-repository corpus: growth, licensing, safety, and signing, the ground truth under the trust layer Part I chronicled.

One scope note, since it is the first thing a careful reader will want pinned down. This report measures how instruction files are written, connected, licensed, and signed, not whether models obey them. We measure loadability: whether a rule is well formed and positioned to take effect. We do not measure obedience, which happens at runtime inside a model we cannot observe, and we claim nothing about it.

Most repositories configure a single assistant, while the developers behind them run several.

A developer cannot see this from inside one project. Each repository shows its own setup and nothing about anyone else’s. The pattern only appears once you check every format in every repository and count how many tools each one actually addresses. No single developer can run that query across the field. We did.

Single-tool is the norm, by a factor of four. The reading that matters is the distance between this chart and how developers actually work. The same people whose repositories address one tool are, on the evidence of every 2026 survey, using two, three, sometimes four. A setup tuned for Claude Code leaves the Cursor, the Copilot, and the Gemini that the same developer reaches for that afternoon with nothing to go on. The repository has not caught up to the toolkit.

Why it matters. A single-tool setup is not a sign that one tool is enough. It is the point where the effort stopped. Add a teammate who prefers a different assistant, switch tools as nearly half of agencies did this year, or open a second tool for a second job, and the work starts again from a blank file. The investment a team makes in one tool stays stranded where it was written, and earns nothing for the rest of the toolkit around it.

This gap is the one we built TomeVault around, so the interest is declared here as it is in Part I: a vault keeps your instructions as one canonical source, converts them into every format on this chart, and keeps the copies in sync, at no cost whether you are one developer or a team. The rest of this report stays clear of the pitch; section 14 is where the practical advice lives, whichever tools you use to follow it.

AGENTS.md is spreading fast, and mostly as a replacement rather than a bridge.

AGENTS.md is the one format designed to be read by more than one tool, and the industry has rallied behind it. Released by OpenAI in 2025 and now a founding project of the Linux Foundation’s Agentic AI Foundation, the same body that stewards Anthropic’s MCP, it had reached more than 60,000 public repositories by the middle of 2026. In our snapshot it appears in 15,856 of these repositories, 75.7% of CLAUDE.md’s footprint. On an adoption chart, the cross-vendor standard looks like it is winning.

Co-occurrence tells a different story.

AGENTS.md was built to bridge tools. Only 18.3% of the repositories that use it or CLAUDE.md use both.

Of the repositories that ship CLAUDE.md, 67.9% ship nothing else at all. Teams adopt the shared standard the way they adopt a competitor, by migrating onto it and dropping what they had, rather than using it to connect two tools they both run.

Why it matters. An industry that agreed fragmentation was worth a standard is now adopting that standard one tool at a time. Read on its own, the AGENTS.md curve suggests the field is converging. Co-occurrence shows it is not. A standard that replaces one file instead of uniting several does not reduce fragmentation. It relocates it.

Thousands of teams ship two instruction files and believe both tools are covered. One of the two is never read.

Anthropic is explicit in its own documentation: Claude Code reads CLAUDE.md, not AGENTS.md. The two only act as one if the repository deliberately connects them. Where they are not connected, Claude Code never sees the AGENTS.md the team wrote, however carefully it was written.

We looked at the 5,565 repositories that ship both files and that we could fully resolve, symlinks included. In 88.9% of them, the two files are not connected at all.

Just 11.1% connect the two by a route the tool actually follows. Another 42.3% name AGENTS.md inside the CLAUDE.md without pulling it in, which looks like a connection and carries nothing. The remaining 46.6% are two separate files with no reference between them, free to contradict each other with nobody watching.

In nearly nine of ten repositories that ship both files, the second one is never read.

Why it matters. Developers complain constantly that their AI tools ignore the rules they wrote. Some of that is the model. A large share of it, on this evidence, is simpler: the rule sat in a file the tool never loaded. The team carries the cost of maintaining two contracts and gets the coverage of one, and never finds out which half is live.

Even the instructions teams do write are drifting past the length their own tools recommend, and the length where they start to backfire.

Which files a repository ships is one question. What is inside them is another. We re-fetched the live contents of 20,606 root CLAUDE.md files, measured their length, and discarded the text.

Anthropic sets the target in plain words: “target under 200 lines per CLAUDE.md file. Longer files consume more context and reduce adherence.” The median CLAUDE.md runs 111 lines, well inside the target. The tail is where it breaks down.

One in four CLAUDE.md files runs past the 200-line guideline Anthropic publishes in its own docs.

26.3% pass 200 lines, 5.6% pass 500, and the longest stretch beyond 900. These are mainstream files that grew, the way documents grow, past the point their own tool says they start to work less well.

The cost of that growth is no longer a matter of guidance alone. In February 2026, researchers at ETH Zurich ran the first controlled test of these files across a standard set of software-engineering tasks, and found that over-specified context files reduce an agent’s success rate and raise its cost by more than 20% against giving it no file at all. Their conclusion was blunt: an instruction file should describe only the minimal requirements. A longer file is not a more helpful one. Past a point it is a file that quietly makes the tool worse, and the team that wrote it has no way to see the damage.

Why it matters. The instinct is to write more: more rules, more context, more coverage. The evidence runs the other way. A short, well-formed instruction file is not a lesser version of a long one. On the only measure that counts, the work the agent actually finishes, it is the better one.

Across ten weeks of continuous discovery, the corpus added thousands of instruction-file repositories every week, and the flow has not slowed.

This section reads differently from the others, and the difference is the point. The dates here are when our pipeline first observed each repository, not when its instruction file was created, so the curve describes the assembly of the corpus inside an explicit measurement window, 2026-04-02 to 2026-06-11. The first week is the bootstrap, 178,919 repositories found by the initial sweep, and weeks after it are steady-state discovery: what a fixed set of queries keeps surfacing once the backlog is drained.

Steady state averages 9,721 newly observed repositories a week, and the mix is consistent: the CLAUDE.md and AGENTS.md pair dominates new arrivals, per-tool configuration formats keep flowing, and skills arrive in bursts that track the discovery sources rather than a calendar trend. We publish this series for a narrower reason than the other sections: it is the baseline the 2027 edition will diff against, with the same frozen definitions, where a year-over-year shape will mean something a ten-week one cannot.

Why it matters. Every number in Part II is a ratio over this corpus, so the corpus itself has to be auditable: how big, gathered when, growing how. This is that disclosure, published as data rather than as a methods footnote.

The year gave instruction files an install command. More than half of them grant no right to redistribute.

Part I described an ecosystem racing to treat instruction files as packages: directories, install CLIs, vendor catalogues. Packages get copied, mirrored, and redistributed, and that is a licensing question nobody in the distribution race is asking out loud. We checked the licence of every instruction-file repository in the corpus, all 267,228 of them, against the licence field GitHub itself reports.

55.8% of instruction-file repositories offer no usable right to redistribute the file the ecosystem is busy distributing.

Just 36.3% of repositories carry a recognised permissive licence. 56.1% carry no licence at all, which under default copyright means all rights reserved, however public the repository looks. The rest split between explicitly restrictive licences and LICENSE files too custom to classify. The figure is structural, not a corner case: it is the majority of the corpus.

Why it matters. Every directory, mirror, and marketplace in Part I inherits this number. An ecosystem built on installing other people’s instruction files is, in the majority case, installing files whose authors never granted that permission. Until licensing becomes part of the trust conversation alongside scanning and signing, the distribution layer is scaling on rights it does not have.

One in twenty instruction files trips a deterministic safety pattern, and the field now has a draft vocabulary for saying which kind.

Safety is the dimension where the easy figure misleads. Measured over only the files an index accepts, the safe rate climbs towards 100%, because files that fail a scan are blocked before they reach the index; that is the filter’s pass rate wearing a safety label. Our denominator is the discovered corpus, blocked files included: 219,024 instruction files put through the same deterministic pattern scanner, of which 5.0% carry at least one finding and 3,678 were blocked from distribution outright.

The 47,393 individual findings inside those files skew heavily towards low-severity signals, obfuscation markers like long encoded blobs and mixed-script text that warrant a look rather than an alarm. The tail is the part that matters: 13,605 findings, about 28.7% of the total, are high or critical severity, the embedded credentials, exfiltration routes, and destructive commands.

New this year is a shared way to say which kind of risk. OWASP’s Agentic Skills Top 10, the incubator project from Part I, proposes ten draft categories for exactly this surface. Mapping our scanner findings onto that draft gives the first corpus-scale view through the field’s own forming lens, and a caveat comes with it: the taxonomy is unreleased and our mapping is editorial, so the table below is a projection, versioned and revisable, not a standard applied.

The shape says most flagged content looks like malicious or obfuscated instruction material rather than sloppy hygiene, with embedded credentials a clear second. Read it as a first sighting, not a ranking: when OWASP ships its 1.0, this section reruns against the released categories, and the projection map is versioned so the 2027 numbers stay comparable.

Why it matters. ClawHavoc made the threat concrete; this is its base rate in the open corpus. A five-percent flag rate over two hundred thousand files is tens of thousands of files worth a closer look, sitting in repositories that agents load with no scan at all in the default case.

The year built signing pipelines, formats, and catalogues. In the open corpus, signing adoption rounds to zero.

Part I ended with the trust layer’s ambition; this is its reach. We probed a deterministic sample of distributed repositories from the corpus, 986of them reachable, listing each repository’s full file tree and looking for any signature or attestation artefact under a definition frozen before the probe ran: detached OMS signatures, GPG and minisign signatures, Sigstore bundles, in-toto attestations, provenance files.

Three repositories matched the filename patterns, and manual inspection dissolves all three: a build cache manifest, an application’s template fixtures, and a stray signature file in an unrelated project. Not one repository in the sample signs its instruction files, and not one ships a skill card. Against Part I’s chronicle the contrast is exact: NVIDIA signs 207 of 207 skills in its own catalogue, and the open corpus signs nothing.

Why it matters. Signing exists where a distributor requires it and nowhere else, which is precisely the maintainer’s March position playing out in the data: trust is becoming a property of the channel, not of the file. Whatever closes the gap between a signed vendor catalogue and an unsigned open corpus, it will not be authors signing files spontaneously. The zero is the baseline the 2027 edition measures against.

Three readings, depending on where you sit.

Methodology & limits

Two kinds of claim, one seam

This report makes two kinds of claim and keeps the seam between them visible. Part I is editorial: a chronicle assembled from primary sources, each load-bearing claim verified against the original document with its access date recorded in the References block, and adversarially checked before printing. Part II is empirical: measurements of our own corpus, generated by versioned scripts with frozen metric definitions. Where Part I reports what someone said, we date the statement; where Part II reports a number, we name its denominator. Neither half borrows the other’s authority. And where the publisher itself appears, in sections 03 and 06, the interest is declared in place rather than left to the colophon.

How Part II was measured

Two populations, each named where used. The fragmentation sections (06 to 09) use 35,830 repositories probed symmetrically: one directory listing per repository, checked for all six tool families in a single pass, so a format that is absent is genuinely absent. Those facts are frozen and hash-stamped at 2026-06-04. The annual-edition sections (10 to 13) use the full discovered corpus, 267,228 repositories across every discovery source, snapshotted 2026-06-11; it is broader and includes the skills ecosystem, and it is the corpus the 2027 edition will diff against.

Generated, not queried. Every figure in sections 10 to 13 is produced by a checked-in generator with frozen metric definitions, run against a read-only database snapshot, with output hashes recorded in a manifest. Population definitions travel inside the output files themselves, and the headline aggregates are downloadable above. Nothing in this report comes from an ad-hoc query that cannot be rerun.

The probe behind the zero. The signing figure comes from a deterministic 1,000-repository sample of the distributed corpus, 986 reachable, each repository’s full file tree listed and matched against a signature-artefact definition frozen before the probe ran. Filename matching overcounts if anything: the three nominal matches it produced dissolve on inspection, which is why the effective rate is zero and the nominal rate is published alongside it.

What we structurally cannot see. Public GitHub only, through a discovery method subject to the platform’s 1,000-results-per-query cap. Private repositories, enterprise installations, and the vendor registries’ server sides are invisible to us, and every claim here should be read with that boundary in mind. Discovery dates are our ingestion dates, not file creation dates, which is why section 10 is framed as a window and not a trend.

Tool versus format. Cursor ships two formats; we count them as one tool, which is why the fragmentation count is six tools across seven formats. We do not probe nested CLAUDE.md files or path-scoped Copilot files there. The content findings re-fetch each file live, measure line count and connection, discard the text, and report raw distributions against Anthropic’s stated guidance. No quality grade is applied.

What we did not measure, and why

We held back every figure our own instruments could not support honestly.

We do not publish a conversion-fidelity rate. The internal flag we would have used was true by construction, so it measured nothing, and we cut it rather than dress it up.

We do not publish a single quality score. Several of the checks that would feed one are unimplemented or skewed towards mainstream web stacks, which would mark a precise data or systems file as vague for naming tools the check does not recognise. A composite built on that would be confident and wrong.

We do not publish the OWASP projection as if the taxonomy were released. It is a draft mapped by us onto a draft, both versioned, and labelled that way everywhere it appears.

We do not publish a safety rate over only the indexed files, for the survivor reason given in section 12. The honest denominator is the discovered set, and that is the one we used.

Stating these limits is what earns the rest of the numbers.

Prior work

Several tools already check one repository at a time: agnix, ctxlint, cursor-doctor, and agentlinter each lint or grade a single project. Several studies measure populations of these files, among them Agent READMEs (arXiv 2511.12884), Beyond the Prompt (arXiv 2512.18925), and Agent Skills in the Wild (arXiv 2601.10338), which track adoption, score quality, or audit security one format at a time. This report adds the parts none of them cover: the per-repository intersection of every major format, and the licensing and signing ground truth under the year’s trust buildout, across hundreds of thousands of repositories at once. That is the only novelty we claim.

References

Part I sources are primary and were accessed 2026-06-10 or 2026-06-11; statuses they support are snapshots as of those dates.

• Agentic AI Foundation formation and membership: Linux Foundation press release (9 Dec 2025); membership update (24 Feb 2026); MCP project announcement.
• Agent Skills open standard: agentskills.io specification; signing RFC and maintainer position: discussion #252 (opened as issue #247); unmerged verification PR #643.
• Distribution layer: Vercel skills CLI and skills.sh launch (20 Jan 2026); automated security audits (17 Feb 2026); GitHub gh skill (16 Apr 2026).
• NVIDIA Verified Agent Skills: announcement blog (19 May 2026) and docs.nvidia.com/skills; catalogue parity checked independently via the GitHub trees API.
• Google: official skills repository announcement (22 Apr 2026); Gemini Enterprise Skill Registry docs (preview 19 May 2026); Gemini CLI skills documentation.
• OWASP Agentic Skills Top 10 (incubator draft): project page.
• ClawHavoc: Koi Security disclosure (1 Feb 2026, updated 16 Feb); Antiy CERT analysis (6 Feb 2026).
• Threat-model analysis: Andrew Nesbitt, Skills Registry Threat Models (3 Jun 2026).
• Academic: ETH Zurich, “Evaluating AGENTS.md”, arXiv:2602.11988 (Feb 2026); “Agent Skills in the Wild”, arXiv:2601.10338 (15 Jan 2026).
• Multi-tool usage and the split market: Stack Overflow 2025 Developer Survey and JetBrains, which AI coding tools developers use at work (2026).
• Vendor guidance quoted throughout: Anthropic Claude Code documentation.

Corrections & revisions

This page is versioned. If a published figure or claim turns out to be wrong, the correction appears here, dated, with the original wording preserved; silent edits are not made. Claims about in-motion projects (an unmerged pull request, an unreleased taxonomy, a product in preview) are snapshots as of their stated access dates and are re-verified before each revision.

• r2 · 2026-06-11 Annual edition. Added Part I (the year in instructions) and four corpus analyses (discovery window, licensing, safety through the draft OWASP lens, signing). One prior figure moved: the safety section’s population widened from the 52,985-file instruction-file scan to the full 219,024-file corpus, taking its flag rate from 3.9% to 5.0%, with both denominators stated in place. No other figure changed.
• r1 · 2026-06-08 Initial publication: the fragmentation measurement, sections 05 to 09.

The gap this report measures is now a two-layer gap. At the file layer, developers are adding tools faster than their repositories are learning to serve them, and the standard that could close that gap is being absorbed into it. At the trust layer, the industry built scanners, signatures, and taxonomies this year, and the open corpus has adopted none of it: unlicensed in the majority, unsigned in its entirety, flagged at a steady five percent.

Nothing here is hard to fix, and that is the strange part. Connecting two instruction files is a symlink. Licensing a repository is a file. Signing is a command the vendor catalogues already run on every skill they ship. It is just, for now, almost universally undone.

Every file behind these numbers is public, the checks run on a single repository, the aggregates are downloadable above, and the definitions are frozen. The data is the contribution. The 2027 edition reruns the same instruments and reports the deltas: whether the multi-tool gap closed, whether the licences appeared, and whether the signing zero budged.

Citation and reuse

The Part II figures are published as machine-readable data under CC BY 4.0, and described in the structured dataset metadata embedded on this page. Reuse the numbers with attribution.