Anthropic-Cybersecurity-Skills: 818 agent skills mapped to six security frameworks

The gap this library fills: an agent that does not know which plugin to run

A language model asked to triage a suspicious memory dump will produce something plausible. A senior analyst will reach for a specific Volatility3 plugin, then pivot to a specific Sigma rule set for Kerberoasting, then scope a cloud breach across three providers. The README frames the project around exactly that gap: the agent "doesn't [have those skills] unless you give it these skills."

The audience is narrow and specific. This is for people who already point an agent at security work and want it to produce framework-anchored procedure instead of generic advice. The README lists compatibility with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI and what it calls 20+ platforms, following the agentskills.io open standard. Each skill is a structured document rather than a prompt fragment, which is what makes the framework mapping possible at all.

One naming caveat matters before anything else. The README carries an explicit notice that this is an independent, community-created project and is "Not affiliated with Anthropic PBC." The name borrows Anthropic's brand; the maintenance does not. Anyone searching for an official Anthropic security product has landed in the wrong place.

How a skill is structured and where the framework mappings live

The unit of distribution is a skill directory under skills/, and the framework mappings are frontmatter keys inside each one. The README shows two keys by name: mitre_attack and mitre_f3. The F3 mappings are described as living in each skill's mitre_f3 frontmatter block, with all 123 F3 v1.1 technique IDs verified against the upstream STIX bundle.

The design principle is selective mapping rather than blanket coverage. A forensics skill carries ATT&CK and CSF; an AI-security skill adds ATLAS and AI RMF. The README gives a worked example: analyzing-network-traffic-of-malware maps to T1071, DE.CM, AML.T0047, D3-NTA and MEASURE-2.6, with no F3 entry. detecting-business-email-compromise maps to T1566, DE.AE and F1005.006 under monetization, with no ATLAS, D3FEND or AI RMF entry. That asymmetry is the honest part of the design. A skill about memory forensics has nothing useful to say about AI risk management, and the schema does not pretend otherwise.

The framework coverage counts the README publishes are uneven, and the unevenness is informative. MITRE ATT&CK covers 805 of the skills, NIST CSF 2.0 covers 804, MITRE D3FEND 139, NIST AI RMF 97, MITRE F3 94, MITRE ATLAS 93. ATT&CK and CSF are near-universal; the other four apply where relevant. If your program is built on D3FEND defensive countermeasures, roughly five sixths of this library will not carry a D3FEND mapping.

Installing it and running a first lookup

The README gives two install paths. The first is npx, which it marks as recommended:

npx skills add mukul975/Anthropic-Cybersecurity-Skills

That command installs the skill set through the skills CLI rather than cloning the tree. The second path is a plain clone, which is what you want if you intend to read or edit the skills:

git clone https://github.com/mukul975/Anthropic-Cybersecurity-Skills.git

After cloning, the skills themselves are under skills/, and the repository root also carries index.json, mappings/, docs/, tools/ and ATTACK_COVERAGE.md.

For a first real use, pick a domain you can verify. The README's own example skill, analyzing-network-traffic-of-malware, is a reasonable starting point because its mappings are published in the table. List the repository contents to confirm the layout on your checkout, then open the skill whose name matches your task and read its frontmatter. The mitre_attack list is what you would hand to an agent as grounding, and the ATTACK_COVERAGE.md file at the root is where the aggregate mapping claim is documented. What you should see is a directory per skill with the framework IDs in frontmatter, not a monolithic prompt file.

Offensive content, dual-use skills and the SCOPE.md question

The README is unusually direct about this. It states that the library includes offensive and dual-use techniques, naming red-team C2, phishing simulation and exploitation, and restricts intended use to authorized penetration testing, security research, defense and education. It points to SECURITY.md and CODE_OF_CONDUCT.md, and the repository root carries a separate SCOPE.md.

That is the right disclosure to make, and it is also the constraint that decides many adoption questions. A library containing phishing simulation and C2 material is not something every organization can drop into an agent's context without a review. The licence is Apache-2.0, which is permissive, but a permissive licence says nothing about whether your employer's acceptable-use policy permits the content. The README puts responsibility for lawful use on the user, which is the only position an open library can take and also means you get no gatekeeping.

The practical consequence: this is not a library you enable globally for every engineer. Scope it to the people doing the work it describes, and treat SCOPE.md as required reading before that decision rather than after.

What the framework counts do not tell you

The headline numbers are large and the README is careful about them in one place and loose in another. The badge area says 818 skills and 34 domains; the framework coverage line says "across the 817 skills"; the F3 section says 94 fraud-relevant skills. Those three figures do not agree, and the repository is the only authority on which is current. Before you build a coverage argument on the count, run a directory listing against skills/ and reconcile it yourself.

The second thing the counts do not tell you is depth. A skill mapped to T1071 and D3-NTA could be a two-page procedure or a paragraph. The README publishes mapping breadth, not content length, and nothing available describes how much procedural detail a typical skill carries. If your evaluation depends on whether the agent gets step-level guidance or a pointer, you have to open a sample and look.

The third is that mapping is not validation. The README states the ATT&CK IDs were validated against v19.1 using the official mitreattack-python library, with zero revoked or deprecated IDs, and that the F3 IDs were verified against the upstream STIX bundle. That is a real quality signal for identifier correctness. It says nothing about whether the procedure attached to an identifier is good advice.

How it compares with writing your own skill files

The obvious alternative is not another library. It is the skill format itself. Claude Code, Codex CLI and the other listed platforms all accept project or user level instruction files, so a team can write its own procedures and get the same mechanism without the dependency.

The difference is in what you inherit. A hand-written skill file gives you your own runbook in your own words, with no framework frontmatter and no upstream to track. This library gives you 805 ATT&CK-mapped entries, 94 F3-mapped entries and a documented schema in docs/mitre-f3-mapping.md, at the cost of adopting someone else's taxonomy and someone else's phrasing.

For a team with an existing runbook corpus, the second option is probably the wrong trade: you would be maintaining a parallel copy of procedures you already own. For a team that has no runbooks and needs framework-anchored coverage quickly, the mapping work is the part you are buying, and it is the part that would take the longest to reproduce. The F3 coverage is the clearest case of that, since F3 v1.1 was released on 2026-04-09 and the mapping is recent enough that few teams will have done it themselves.

Maintenance, licence and what upgrading costs you

The repository is not archived and the last push was on 2026-06-22, which is the same date as the v1.3.0 release. Before that, v1.2.0 landed on 2026-04-06 and v1.1.0 on 2026-03-21. Three releases in roughly three months, then nothing recorded after June. The README does not document a release cadence, a support window or a deprecation policy, and SUPPORT.md exists at the root but its contents are not available here.

The upgrade cost is real because the framework versions move underneath you. ATT&CK v19.1 restructured Defense Evasion into Stealth and Defense Impairment, and the README's tactic table reflects that split with TA0005 and TA0112 as separate rows. Any mapping you build on top of this library inherits those framework revisions. When ATT&CK, ATLAS or F3 publish a new version, the frontmatter IDs are only as current as the last commit, and there is no stated process for how quickly they are revalidated.

On licensing, the repository is Apache-2.0, which permits commercial use, modification and redistribution with attribution and the usual patent grant. That is the permissive end of the spectrum and imposes no copyleft obligation on your own skill files. It is not legal advice, and the offensive-content question sits outside the licence entirely: Apache-2.0 grants copyright permissions, not authorization to test systems you do not own.

Editorial conclusion

Adopt it if you already run an agent on security work and want framework-mapped procedures rather than freeform model output; the ATT&CK and F3 frontmatter is the part worth the setup. Skip it if your environment cannot sanction dual-use content, or if you need vendor-backed support and a stable namespace. Before rollout, verify the actual skill count in skills/ against the headline 818, decide whether you need the mitre_f3 and mitre_atlas frontmatter blocks, and read SCOPE.md and SECURITY.md in full. The repository is not archived and the last push was on 2026-06-22.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes