817 Cybersecurity Skills, Six Frameworks, and a Coverage Table That Contradicts the Headline
A look at mukul975/Anthropic-Cybersecurity-Skills, the largest open security skill pack on GitHub, and why the mapping metadata is worth more than the skill count.
The repo's own numbers are the most interesting thing in it. Anthropic-Cybersecurity-Skills advertises 817 cybersecurity skills mapped to six frameworks. Then, further down the README, it publishes the actual per-framework coverage:
MITRE ATT&CK, 805 skills. NIST CSF 2.0, 804. MITRE D3FEND, 139. NIST AI RMF, 97. MITRE F3, 94. MITRE ATLAS, 93.
Two frameworks cover almost everything. The other four cover roughly one skill in eight each. So "six frameworks" describes the library, not any skill you are about to load, and the README says so in a sentence most projects would have deleted: each skill maps only to the frameworks that apply to it.
I went in expecting a star-farming prompt dump. What I found was a security knowledge base with better metadata discipline than most internal wikis, wrapped around a distribution model nobody has solved.
Why the mapping matters more than the skills
The repo has 28,000 stars and 3,400 forks as of today, which puts it in the top tier of the skills boom. Skill count is not why it deserves attention.
Here is the position I will defend. Prose in a SKILL.md is the cheapest part of any skill pack. A capable model already knows roughly which Volatility3 plugin dumps process memory. What it does not know is the vocabulary your organization is required to answer in. When an agent finishes a memory analysis and reports "found credential dumping," that finding is a paragraph. When it reports T1003 with a DE.CM-01 detection mapping, that finding is a row in a control matrix your auditor already has open.
That translation layer is where the real work lives, and it is boring, manual, and does not benefit much from being generated. Which is exactly why a hand-built mapping across 817 skills is worth more than the 817 skills.
The newest mapping in the pack makes the point. The MITRE Fight Fraud Framework (F3) v1.1 came out April 9, 2026 from MITRE's Center for Threat-Informed Defense, co-developed with JPMorganChase, Citigroup, and Lloyds Banking Group. It covers 8 tactics and 123 techniques of cyber-enabled financial fraud, which is the ground ATT&CK stops covering right after initial compromise. It has its own tactic, Positioning (FA0001), for what an attacker does after access to set up the actual theft, and its own technique IDs in an F1XXX namespace: F1005.003 Add Beneficiary, F1025.003 Wire Transfer, F1007 Adversary-in-the-Browser. Ninety-four skills in this repo carry those IDs. If you work anywhere near payments, that is a mapping you would otherwise be building yourself this quarter.
What a skill actually looks like here
Each skill is a directory, following the agentskills.io format:
skills/performing-memory-forensics-with-volatility3/
├── SKILL.md ← YAML frontmatter + Markdown body
├── references/
│ ├── standards.md ← ATT&CK, ATLAS, D3FEND, NIST mappings
│ └── workflows.md ← deep technical procedure
├── scripts/
│ └── process.py ← working helper scripts
└── assets/
└── template.md ← report templates and checklists
The frontmatter is where the mapping lives, as ordinary YAML lists:
atlas_techniques: [AML.T0047]
d3fend_techniques: [D3-MA, D3-PSMD]
nist_ai_rmf: [MEASURE-2.6]
nist_csf: [DE.CM-01, RS.AN-03]
The body is four sections, and the discipline in them is what separates this from a link dump: When to Use (the trigger conditions), Prerequisites (tools and access), Workflow (the actual commands and decision points), and Verification (how to confirm it worked). That last one is the section almost every skill pack skips, and it is the one that stops an agent from declaring victory on a half-finished investigation.
The economics are published too. About 30 tokens to scan one skill's frontmatter, 500 to 2,000 to load the full workflow. Do the multiplication the README does not: scanning all 817 frontmatters is roughly 24,000 tokens. That is a real bite out of a context window before a single workflow loads, so the claim that an agent can "search all 817 skills in a single pass" is true in the sense that the arithmetic works, and optimistic in the sense that you probably do not want to spend a fifth of your window on an index.
One note on the ATT&CK mapping quality. The maintainer validates technique IDs against v19.1 using the official mitreattack-python library, which catches revoked and deprecated IDs. That checks whether an ID exists. It does not check whether the ID is the right one for that skill. Nobody has audited the second question, including me.
Put this into practice
Do not clone 817 skills into your agent and hope. Here is the ten-minute version.
1. Clone it somewhere your agent cannot read yet.
git clone https://github.com/mukul975/Anthropic-Cybersecurity-Skills.git
cd Anthropic-Cybersecurity-Skills
The README also offers npx skills add mukul975/Anthropic-Cybersecurity-Skills, which installs straight into your agent's skills path. Skip that on the first pass. You want to read before you install.
2. See what you would be handing over.
ls skills | wc -l
find skills -name "*.py" | wc -l
The second number is the one that matters. This pack ships executable helper scripts, not only markdown, so "installing a skill" here means putting code on disk that an agent may decide to run.
3. Take one domain, not the library. The domains are uneven by design: Cloud Security and Threat Hunting carry dozens of skills each, Hardware & Firmware Security carries four. Copy the one domain that matches work you actually do into your skills directory and delete the rest.
mkdir -p ~/.agent-skills/security
cp -r skills/*incident-response* ~/.agent-skills/security/
4. Run one real investigation you already know the answer to. Point your agent at a memory dump or a log bundle from a closed case. You are grading two things: whether the workflow steps are right, and whether the ATT&CK and CSF IDs it emits are ones you would have picked. Bad mappings are worse than no mappings, because they look like compliance evidence.
5. Steal the pattern even if you drop the pack. The move worth copying is putting framework IDs in skill frontmatter so agent output lands pre-tagged. You can do that with six skills of your own and get most of the value.
If you only have ten minutes, do steps one, two, and four on a single skill. That is enough to know whether this pack fits how your team works.
Honest limitations
The name is a problem. It is called Anthropic Cybersecurity Skills, and the README states plainly that it is an independent community project not affiliated with Anthropic PBC. The disclosure is there and it is early in the file, so the maintainer is not hiding anything. A vendor's name in the repo title still does work with people who never scroll.
There is no version to pin. The only tagged release is v1.0.0 from March 11, 2026, which held 734 skills across 26 domains with two framework mappings. main is at 817 skills, 29 domains, six mappings. Everything anyone is running came off an untagged branch, which means no reproducibility, no diff between what you reviewed and what you get on the next pull, and no signature. For a general-purpose skill pack that is a nuisance. For the pack you point at during an incident, it is a gap you should close with a fork and a pinned commit.
The README is inconsistent with itself in small ways. The domain table lists Deception Technology at six skills while the Contributing section, further down, still asks for help with "Deception Technology (2 skills)." Trivial on its own, and a fair signal about how fast the counts move relative to the prose around them. Treat every number in that file, including the ones I have quoted here, as a snapshot.
The content is dual-use and the README says so, flagging red-team C2, phishing simulation, and exploitation techniques as authorized-use-only. That warning is a sentence in a markdown file. It is not a control, and an agent reading these skills does not enforce it.
And the size cuts both ways. Nobody, including the maintainer, has read all 817 skills recently enough to vouch for them line by line. The trust model is the same one the entire skill ecosystem is running on right now: you clone a folder of instructions, your agent reads them as authoritative, and the review step is a thing you promised yourself you would do.
The question I cannot answer yet
Say you adopt this. Six months from now it has 1,400 skills, your incident response runbook effectively lives inside it, and a pull request lands that touches forty files.
Who reviews that? Not your security team, who did not write it. Not the maintainer, who reviews contributions for accuracy in 48 hours and is one person. Not your agent, which will read whatever is in the folder and treat it as expertise.
I do not think the answer is to avoid packs like this. The mapping work in here is genuinely good and I would rather have it than not. I think the answer is that a skill library you rely on operationally needs the same handling as a dependency: pinned, diffed on update, and owned by someone whose name is on it inside your company.
If you have already put a large skill pack into a production security workflow, I want to know what your update process looks like. I have not seen one I would call finished.
Sources: mukul975/Anthropic-Cybersecurity-Skills, README.md, v1.0.0 release, MITRE Fight Fraud Framework, MITRE ATT&CK, MITRE D3FEND, NIST CSF 2.0, agentskills.io.