claude-red at 8,489 Stars: Its Own CONTRIBUTING.md Says Skills Without Frontmatter Won't Load — 28 of 79 Don't Have It, and They Hold 77% of the Bytes

SnailSploit/Claude-Red describes itself as “a curated library of offensive security skills for the Claude Skills system,” and 8,489 people have starred it. Its CONTRIBUTING.md states the format rule the whole library depends on, in plain words:

“YAML frontmatter is required. Skills without it won’t load via the Claude Skills system.”

Twenty-eight of the repository’s 79 SKILL.md files have no YAML frontmatter. They do not start with ---; they start with # SKILL: followed by a markdown ## Metadata block. Those 28 files account for 2,753,891 of the repository’s 3,565,194 bytes of skill text — 77.2%. The five largest files in the library are all in that set, including one at 567,484 bytes and 15,151 lines.

That single number is the article: a library where the majority of the content sits in files its own contribution guide declares non-loading, and where the marketing count (78, on the badge) disagrees with the disk (79) and with the generated manifest (78 entries, 28 of them with an empty description).

There is a second number that matters just as much. SECURITY.md says: “This repository is signed by SnailSploit. Verify commit signatures with: git log --show-signature”. I ran it. All 45 commits report N — not signed. Zero.

Everything below was measured on 24 October 2026 against a full git clone of main (HEAD a8de813, dated 2026-10-12), the GitHub REST API, and the repository’s own tooling executed locally. Nothing was installed into any Claude environment, no skill was ever loaded by a model, and no offensive technique from the library was executed. The counts come from parsing files with Python, so every figure is reproducible with git clone and a script. Where I quote Anthropic’s documentation, the quote is from the live docs pages and the sentence is reproduced as written.

What the platform actually requires

Before the audit findings make sense, the mechanics matter, because “skill” is not a synonym for “markdown file with a nice title.” Anthropic’s Agent Skills documentation lists the required fields explicitly:

Required fields: name and description name: Maximum 64 characters · Must contain only lowercase letters, numbers, and hyphens · Cannot contain XML tags · Cannot contain reserved words: “anthropic”, “claude” description: Must be non-empty · Maximum 1,024 characters · Cannot contain XML tags “The description must include both what the Skill does and when Claude should use it.”

And it describes three loading levels, which is the part every “skills are free until you need them” pitch depends on:

Two more documented behaviours matter here. First, authoring guidance is explicit: “Keep SKILL.md under 500 lines. Move detailed reference material to separate files.” Second, on persistence: “When you or Claude invoke a skill, the rendered SKILL.md content enters the conversation as a single message and stays there across later turns,” and after auto-compaction “Claude Code re-attaches the most recent invocation of each skill after the summary, keeping the first 5,000 tokens of each. Re-attached skills share a combined budget of 25,000 tokens.”

So: metadata is cheap, the body is not, and the body’s cost is paid on every later turn of the session.

Now the repository’s numbers.

78, 79, and 28

The README carries a badge reading skills-78 and categories-23. The categories table sums to 78. claude-skills.json, generated by the repository’s own tools/build_manifest.py, reports "skill_count": 78. The filesystem has 79 SKILL.md files across 23 categories.

The missing one is Skills/active-directory/offensive-netexec/SKILL.md, created on 2026-09-14; the manifest was last regenerated on 2026-08-26 and never since. The README’s Active Directory row says 1 skill; the directory contains 2. Re-running python3 tools/build_manifest.py prints “Wrote … with 79 skills across 23 categories” — the tool works, it just was not run after the last skill was added. That is a small thing, but it tells you the manifest is not part of any release process: it is a file that was regenerated by hand when someone remembered.

Then the bigger split:

Distribution of the 28 by category:

The ai category is 1/1: the only AI-security skill in an AI-security library has no metadata. Web — the largest category, 16 skills and the one the README leads with — is 11 of 16 without frontmatter. Wireless is the cleanest: 14 of 14 fully formed.

The 77% is not just bigger, it is different content

It would be easy to assume the 28 files are simply older or lower-effort. They are the opposite: they are the largest files in the repository.

Those byte-to-token conversions are estimates at four bytes per token — the same convention GitHub’s own size heuristics imply — and they are large enough that the estimate’s error bar does not change the conclusion. A single skill at 567 KB is roughly 142,000 tokens. Anthropic’s own Level-2 guidance is “under 5k tokens,” and the entire post-compaction re-attachment budget for all skills in a session is 25,000 tokens. One file in this library is 5.7× that combined budget before compaction and 28× the per-skill 5,000-token slice after it.

Library-wide:

This is where the README sentence deserves scrutiny: “Skills load on demand based on conversational triggers — you don’t pay context for skills you aren’t using.” The first half is correct and is what the platform promises. The second half is true only at Level 1. When one of these files is triggered, the whole body enters the conversation as a single message and stays there: for the four largest files, that is 88,000 to 142,000 tokens in one turn, on a model whose context window is a fraction of the library’s aggregate. Nothing in the repository splits those bodies into Level-3 reference files, which is exactly the pattern the authoring guide recommends.

There is a perverse consequence worth naming plainly: the frontmatter-less files are the ones Claude Code will still try to load. Per the Claude Code documentation, “All fields are optional. Only description is recommended… If omitted, uses the first non-empty line of the markdown content,” and “Claude Code reads the frontmatter only when the opening --- is the file’s first line. Otherwise it treats the whole file, --- markers included, as skill content.”

So on the Claude Code path — the one the README recommends, git clone … ~/.claude/skills/claude-red — those 28 skills do load, with a description derived from their H1:

• # SKILL: Week 5: Basic Exploitation (Linux with Mitigations Disabled)
• # SKILL: Week 4: Crash Analysis and Exploitability Assessment
• # SKILL: OSINT Methodology

A course-week heading becomes the trigger description. That is not a description of what the skill does and when to use it; it is a syllabus label. And it is attached to a 354 KB body. On the API/claude.ai upload path, where name and description are required fields, those same 28 are simply invalid. Both readings of the repo’s own sentence — “won’t load” — are defensible; the uncomfortable part is that “loads badly, with a syllabus title and 142,000 tokens behind it” is the more likely outcome for most users.

Even among the 51 files that do have frontmatter, 18 descriptions exceed the platform’s 1,024-character maximum (longest: 1,525 characters, privesc/offensive-windows-privesc). In Claude Code the combined description is truncated at 1,536 characters in the skill listing, so those 18 survive there by 11 characters of margin; anywhere the required-field rule is enforced, they fail validation. Name hygiene, at least, is clean: in all 51, name equals the directory name, and no name exceeds 64 characters.

Where the 28 files came from

The frontmatter-less files share a house style, and it is not the style of the rest of the library:

# SKILL: Week 5: Basic Exploitation (Linux with Mitigations Disabled)

## Metadata
- **Skill Name**: basic-exploitation
- **Folder**: offensive-basic-exploitation
- **Source**: https://github.com/SnailSploit/offensive-checklist/blob/main/5-basic-exploitation.md

## Description

They are a different artifact: long-form course material, one file per week or per topic, copied in from the author’s offensive-checklist repository, with the source URL kept as a **Source** line. The intended pipeline to turn them into skills is convert_skills.py, which parses exactly this ## Metadata / # SKILL: structure and emits YAML frontmatter. It has never been run over these 28 files — or, if it was, the output was not committed.

That converter is worth reading, because it explains a lot about the state of the repo:

• INPUT_DIR = Path("skills") — lowercase. The directory in the repository is Skills/. On a case-insensitive filesystem (macOS, the author’s platform, judging by the .DS_Store in the first commit) this works. On Linux it does not. I ran it: ❌ Carpeta no encontrada: …/Claude-Red/skills.
• When it fails, it prints that error and exits 0. There is no non-zero exit code path in main(); the failure is invisible to any script that checks $?.
• Its fallbacks are Spanish strings: meta['description'] = 'Sin descripción disponible.' and meta['body'] = '# Instructions for Claude\n[Contenido no parseado]'. If the parser misses both the description section and the body, the generated skill ships with the literal description “No description available.” — which is the kind of thing you find out at trigger time, not at build time.

Five of the frontmatter-less files also carry a provenance comment that appears nowhere in the repository’s documentation:

<!-- Written by AnotherOne from @Pwn3rzs Telegram channel -->

The five: exploit-dev/offensive-basic-exploitation, exploit-dev/offensive-crash-analysis, infrastructure/offensive-windows-mitigations, fuzzing/offensive-fuzzing-course, fuzzing/offensive-vuln-classes. Together, 1.44 MB of the repository. The README’s Acknowledgements section credits “Original Checklists: Sahar Shlichov — the offensive checklist collection that many of these skills build on,” and that credit is real and specific. Neither “AnotherOne” nor “Pwn3rzs” appears in README.md, CONTRIBUTING.md or CHANGELOG.md. Under an MIT license this is legally comfortable and journalistically worth flagging: the largest single block of content in the library is attributed inside an HTML comment, invisible in rendered markdown, to a Telegram channel handle.

The signature claim, checked

SECURITY.md has a section titled Supply Chain Integrity. Its first sentence is a factual claim about this repository: “This repository is signed by SnailSploit.” Its second is an instruction: “Verify commit signatures with: git log --show-signature”.

$ git log --pretty='%h %G?' | awk '{print $2}' | sort | uniq -c
     45 N

Every commit reports N: no signature present. There is no gpgsig header in any commit object. The instruction is not merely advisory — it is the supply-chain control the repository offers, and it verifies to nothing. A reader who follows it sees 45 commits with no signature, which is at least a clear signal; a reader who trusts the sentence keeps believing in a signature chain that does not exist.

The commit authors are also worth laying out, because they qualify the phrase “curated library”:

Thirteen of 45 commits are authored by Claude itself, with Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> and, in some cases, a Claude-Session: trailer pointing at a session_… URL. That is 29% of the history, making the model the second-largest committer in a library whose product is instructions to a model. It is not a scandal — an agent-assisted workflow is normal in 2026, and the commits are readable in the log — but it does mean that “curated” here describes an outcome, not a human review process that anyone has documented. The CONTRIBUTING.md review process is described in prose; there is no CI check that enforces any of it, as the frontmatter count shows.

Commit rhythm, by month: March 5, April 4, May 13, June 0, July 0, August 14, September 8, October 1. Two silent months in the middle of the year, then the burst that coincides with the repository appearing on trending lists.

And the initial commit explains a pattern that the copyright line and changelog corroborate. 86d1449, dated 2026-03-04, contains 43 files and 83,322 inserted lines, including 38 SKILL.md files. The LICENSE reads “Copyright (c) 2024-2025 SnailSploit / Kai Aizen”; the CHANGELOG entries are dated “0.2.0 — 2025-05” and “0.3.0 — 2025-08”, both months before the repository existed on GitHub. This is not a project that grew on GitHub: it is roughly two years of private checklist and course material published in one push, then expanded in phases. Which is a legitimate way to release work — and it also predicts the maintenance shape you should expect: no tags beyond two (Snail, v0.3.0), no roadmap obligations, and a manifest that drifts because publishing the archive was the event, not starting a project.

The manifest tells you what the code paths see

claude-skills.json is the machine-readable index. It is generated by tools/build_manifest.py, which parses frontmatter and falls back to the directory name when parsing yields nothing:

entry = {
    "name": fm.get("name", skill_dir.name),
    "category": category,
    "path": str(skill_md.relative_to(ROOT)),
    "description": fm.get("description", ""),
}

The fallback is the whole story. In the committed manifest, 28 of 78 entries have "description": "" — exactly the 28 frontmatter-less files:

{
  "name": "offensive-windows-boundaries",
  "category": "infrastructure",
  "path": "Skills/infrastructure/offensive-windows-boundaries/SKILL.md",
  "description": ""
}

A 567 KB skill, indexed by the project’s own tooling, with an empty description. Anyone building on this manifest — a router, a registry, an index page, an evaluation harness — gets a name and a path and nothing to match against. Description lengths across the 50 non-empty entries: minimum 322 characters, median 825, maximum 1,525.

What is genuinely fine

An audit that only lists defects is not an audit; it is a prosecution. So, measured the same way:

That last row deserves emphasis because it is the check the repo’s own SECURITY.md invites (“a typosquat-prone install path, or an unsafe shell command in install.sh”): the installer is a plain copy. It is honest work. I ran it into a scratch directory and it reported “Installed 79 skill(s)” and then said, “Claude should now auto-discover them on next session start” — which is where the honesty stops, because 28 of those 79 have no discovery metadata and one category (ai) has none at all.

Hazard patterns in the bodies, for completeness, with the caveat that in an offensive-security library these are the product, not a defect: reverse-shell constructs appear in 5 of 79 skills, curl … | sh install snippets in 7, a base64-decode pipeline in 1 (web/offensive-rce), and IPv4 literals in 36 files (359 occurrences — mostly RFC1918 lab addresses and example targets). Code blocks: 2,531 opening fences, of which 226 (8.9%) carry no language tag, against the repo’s own CONTRIBUTING.md rule 5.

The distribution of safety language is the one asymmetry I would raise with the maintainer. SECURITY.md restricts the library to “Authorized penetration testing engagements with documented scope and rules of engagement,” “Bug bounty programs with explicit written permission,” and similar. Inside the files, 18 of 79 contain no authorization, scope, legality or consent wording at all — including web/offensive-xss, web/offensive-waf-bypass, wireless/offensive-evil-twin and infrastructure/offensive-shellcode. A 19th (wireless/offensive-bluetooth-classic) mentions scope only in its frontmatter description, which the model reads at discovery time but does not carry as an instruction. Exactly 1 contains an explicit “written permission” clause (forensics/offensive-anti-forensics). When a skill is pasted into a project’s system prompt, SECURITY.md does not travel with it: the file is the whole instruction set, and the policy lives one level up in a document the model never reads.

The vendor in the CI, and the score that measured parsing

Two workflows come from a vendor: skill-preview.yml runs tesslio/skill-review-and-optimize on every PR that touches a SKILL.md with optimize: true and a TESSL_API_TOKEN secret, and skill-optimize-apply.yml runs the same action in mode: apply when someone comments on a PR.

The gate on the second one is this, verbatim:

on:
  issue_comment:
    types: [created]
jobs:
  apply:
    if: >
      github.event.issue.pull_request &&
      contains(github.event.comment.body, '/apply-optimize')
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write
      contents: write

It checks that the comment is on a pull request and that the body contains the string /apply-optimize. It does not check github.event.comment.author_association, and there is no github.actor allowlist. Issue comments on public repositories are open to any GitHub account. I did not test this — triggering an external action with contents: write on a repository I do not own would be exactly the behaviour SECURITY.md prohibits — but the condition is readable, and its shape is “anyone who can comment can summon the vendor action with write permission.” Whether the action itself is safe is a question about the action, whose pinned SHA (90e919d50ecb…) is at least a good practice.

The same vendor’s employees appear in the commit log. The April 2026 commit 4e21414 by Yogesh Rao is titled “feat: improve skill scores for Claude-Red” and contains the most useful diagnostic document in the repository. Its body:

“I ran your skills through tessl skill review at work and found some targeted improvements.”

Skill	Before	After	Change
offensive-fuzzing	5%	97%	+92%
offensive-sqli	5%	86%	+81%
offensive-shellcode	5%	83%	+78%
offensive-jwt	10%	86%	+76%
offensive-osint	10%	65%	+55%

“All five skills were scoring 5–10% because they lacked YAML frontmatter — the review tool couldn’t even run the LLM judge. The main change across the board was adding proper --- frontmatter with kebab-case name and a quoted description containing trigger terms and a ‘Use when…’ clause.”

Read that carefully. A 5% score here was not a judgment about content quality; it was the scorer reporting that it could not evaluate the file. The “+92%” headline is a parsability fix. That is a genuinely useful thing to know about skill-scoring tools in general, and it is stated plainly by the person who ran it — in a commit message body rather than the README.

It also means the fix existed, in-repo, six months ago, for five files. Four of the five still have their frontmatter. One does not: recon/offensive-osint-methodology had --- / name: offensive-osint on 2026-04-15 and reads # SKILL: OSINT Methodology today, because the May 2026 “Reorganize skills into 13 categories” commit 70e0c89 replaced the file body wholesale and dropped the header. A bulk reorganization silently reverted a vendor’s improvement to one skill, and nothing in CI notices, because nothing in CI validates frontmatter — the vendor action only runs on PRs.

What the roadmap says, and what to do with it

The roadmap table lists nine phases: three Complete, five Planned (+16 AD/Windows split, +10 cloud identity, +10 IoT, +8 web fundamentals, +10 web advanced), one Complete for “Documentation and tooling polish,” and a target of “~130 skills across 23+ categories.” Present: 79. So the headline number has 51 skills of planned growth in front of it, while 28 of the current 79 are in a format the repo’s own guide says does not load and the converter that would fix them cannot run on Linux.

If you are evaluating this library for authorized work, these are the checks, each with its pass/fail signal. All of them are cheap and none require installing anything into a Claude environment:

Predicted results on today’s main: check 1 → 28, check 2 → 45 unsigned, check 3 → one new entry (offensive-netexec), check 4 → 43 files over 20 KB, check 5 → 18 files with zero matches. I ran all five; those are the outputs.

What none of these checks can tell you — and what the repository cannot tell you at all — is whether the content is good. Whether the ADCS ESC1–ESC15 coverage is accurate, whether the fuzzing harnesses compile, whether the shellcode notes reflect current mitigations: that requires a human with domain expertise reading 3.5 MB of markdown, and no star count, score badge or badge count substitutes for it. The documentation is blunt about the stakes: “Use Skills only from trusted sources: those you created yourself or obtained from Anthropic… a malicious Skill can direct Claude to call tools or run code in ways that don’t match the Skill’s stated purpose.” For a library this size, from a publisher with two releases, 45 commits and a security policy whose one verifiable claim verifies to nothing, “audit thoroughly” is not a formality.

FAQ

Does a SKILL.md without frontmatter fail to load? It depends which surface you mean, and the repository’s CONTRIBUTING.md overstates it in one direction while understating the danger in the other. In Claude Code, the file still loads: the docs say description is recommended, not required, and “If omitted, uses the first non-empty line of the markdown content.” So the trigger description becomes # SKILL: Week 5: Basic Exploitation (Linux with Mitigations Disabled). In the Agent Skills platform spec, name and description are required fields, so the same file does not validate. Either way you lose the thing frontmatter exists for: a description that says what the skill does and when to use it.

Is 567 KB in one SKILL.md actually a problem? Yes, and it is mechanical rather than stylistic. The body enters the conversation as a single message when the skill triggers and stays for the rest of the session; the authoring guidance is “under 5k tokens” and “keep SKILL.md under 500 lines”; the post-compaction re-attachment budget is 5,000 tokens per skill and 25,000 combined. A 567 KB body is roughly 142,000 tokens — 28× the per-skill slice — and its safety framing, if any, sits wherever the author put it, possibly past the point where compaction clips.

Is the library malicious? Nothing I measured suggests it. Zero allowed-tools grants, zero dynamic-context ! lines outside code fences, zero credentials, zero private keys, and an installer that only copies files. The risks here are organisational: undiscoverable content, undisclosed provenance, an unenforceable safety policy, a false supply-chain claim, and automated write access triggered by a comment string. Those are real but they are not the same as a payload.

Why do the star and watcher numbers matter? 8,489 stars against 58 watchers is 0.68% — the star count says the repository was seen, the watcher count says almost nobody wants to be notified about it. 1,100 forks (13%) says people are copying rather than following. For a library whose value is in the files, that ratio is expected; it also means the repository’s social proof is a measure of reach, not of maintenance or of anyone having validated the content.

Who wrote the content? The README credits author Kai Aizen (SnailSploit) and “Original Checklists: Sahar Shlichov.” Within the files, five of the largest carry <!-- Written by AnotherOne from @Pwn3rzs Telegram channel -->, a credit that appears nowhere in the documentation. 28 skills are converted from the author’s own offensive-checklist repository, per the **Source** lines. Techniques across the library cite HackTricks (6 skills), PortSwigger (11), PayloadsAllTheThings (4), GTFOBins (1) and MITRE ATT&CK identifiers (28 skills), which is a reasonable citation habit for material like this.

Would I install it? Not as-is, and not by cloning the whole thing into ~/.claude/skills. If you need a specific technique, take the single file, check that it starts with ---, rewrite the description yourself so the trigger matches how you actually talk about the task, cut the body to what you will use in the next hour, and put the rest in a reference file the skill points at. That is 20 minutes per skill and it produces something the platform’s loading model was designed for. What you should not do is accept the badge count as an inventory: the gap between 78 advertised and 51 usable is the whole lesson.

The number to remember

Not 8,489 stars. Not 78 skills. The number is 28 of 79 — and specifically that those 28 files hold 77.2% of the bytes, that the largest of them is worth about 142,000 tokens against a documented 5,000-token guidance, and that the repository’s own contribution guide names the defect before any auditor does.

A skill library is not measured by how much methodology it contains. It is measured by how much of that methodology the model can actually reach, describe, and safely load — and by whether the publisher’s verifiable claims survive being verified. Here, the frontmatter count, the manifest’s empty strings, the unsigned commits and the /apply-optimize gate all point the same direction: this is a large, genuinely researched body of material published as an archive, not operated as a system. That is a fine thing to publish. It is a different thing from what the badge implies.