How it started: a phone call we did not expect
It was a Wednesday in late April. A long-standing client got in touch, brief, urgent, mildly panicked: his WordPress site had been behaving strangely for the past few hours. We took a look, pulled the first thread, and three hours later we knew: not one site but 30 of 37 WordPress installations on the same hosting account were compromised. A webshell family that has been circulating for years under the name "Sid Gifari" had propagated across the entire account.
The signature was clear and embarrassingly predictable. Three holes, the same ones every time: an unpatched theme from a marketplace with a known RCE issue from 14 months ago. No login lockout, so brute-force over XML-RPC. No file integrity monitoring, so the webshell sat in the plugin root disguised as wp-cache.php and nobody noticed for weeks.
What kept us busy the following week was not the cleanup work itself. That part is routine: locate webshells, hash them, restore originals from WP-Core source trees, forensically inspect database content, rotate passwords, roll out the defense pack across all 37 subs, set up cron jobs for Wordfence and file integrity, validate backups.
What really kept us busy was this: we had already written down the steps for exactly this scenario, three times. Once after a comparable incident two years ago, once as internal best-practice doc, once as a guide for a junior colleague. Every time we had the knowledge. But it was sitting on three different Notion pages, an old Confluence wiki, and a Markdown file in an internal repo.
The week after, the realisation hit: we have the knowledge, we just never made it consumable. Not for our own team under time pressure, and not for the coding agents we and our clients now work with daily.
Today we are releasing the library that came out of that.
What the library is
claude-security-skills is an open-source collection of 34 defensive security playbooks for LLM-based coding agents. Works with Claude Code, Cursor, GitHub Copilot, Codex CLI, Cline, Gemini CLI. Anywhere the agent can read structured prompts from the workspace.
Each skill is a Markdown file with a YAML frontmatter (name, description). The coding agent matches the description semantically against what is being discussed and pulls the matching playbook into context automatically. You do not type a command. The agent recognises on its own "ah, this is about WordPress hardening" and follows the corresponding steps.
13 domains, 34 skills, MIT licence, v1.0.0 ships today.
The engagements behind the library
We did not want to build a theoretical library. Every skill in the repo comes from a concrete client engagement over the last twelve months. Here are the four engagements that form the backbone.
Engagement 1: hosting account consolidation after a webshell incident
The incident described above. What turned the cleanup into a library was the realisation that WordPress security on shared hosting is not solved at site level, but at account level. A single compromised sub-domain is enough to enable lateral movement via cross-account file permissions or shared database users.
Three skills came out of this engagement: wordpress-hardening (site level), shared-hosting-isolation (account-level defense pack with file-integrity cron, mu-plugin audit backdoor, and automated plugin patch status report), and incident-response-wordpress (forensics order, what logs to preserve, when to inform the host).
A coding agent with these three skills in context cannot "just install" a WordPress site. It first checks the hosting setup, looks at account-level file permissions, proposes the defense pack, and implements it.
Engagement 2: greenfield VPS hardening for a SaaS backend
A client spun up a new Hetzner Cloud VPS, Debian 12, planning a NestJS backend service with Postgres for production. Classic greenfield, no legacy. We were asked to run the setup once with full defensive standards before any apps landed on it.
What we delivered in the end were eight progressive configuration steps: UFW ruleset, SSH key-only with fail2ban, automatic security updates without automatic reboot, Postgres with listen address on localhost and connection-pool limits, backup strategy with off-site encryption via restic on B2, Cloudflare origin IP protection with Authenticated Origin Pulls (so no direct-IP bypass is possible), secrets management via systemd environment files with 600 permissions and a Vault read-only user for the app, plus monitoring with fail2ban webhooks into a private Slack channel.
These exact eight steps had been implemented in the same order in three previous VPS hardenings. Out of this engagement came the skills vps-hardening-debian, cloudflare-origin-protection, postgres-listen-hardening, secrets-management-systemd, backup-strategy-restic and fail2ban-monitoring: six skills from one engagement.
Engagement 3: security audit of a distributed agent platform
A client runs their own LLM agent platform: a server cluster orchestrating tasks, plus worker clients running in isolated containers, plus a NATS message bus between them. We were brought in to run a security audit before they went into a wider beta.
The findings that surprised us most:
- NATS was running without ACLs. Every worker could subscribe to all subjects, including those meant for other workers. A compromised worker could have read the entire task queue.
- Tool calls from the agent to the server had no auth re-validation. The agent received a JWT at initial connection and reused it for every subsequent tool call, without refresh, without scope narrowing per call.
- MCP servers trusted the agent fully. The MCP tools assumed the agent would responsibly validate inputs. Which the agent does not do, of course, when the inputs come from prompt-injection-capable sources.
Out of this audit came the skills nats-acl-patterns, mcp-server-hardening, prompt-injection-defense and agent-jwt-rotation. Plus a longer skill distributed-agent-architecture-review documenting the audit methodology.
Engagement 4: inheritance audit of a 12-month-old NestJS codebase
A client had taken over a backend service from a previous vendor: 12 months of code, around 40,000 lines, no documentation, the former lead unreachable. The brief: "give us a report on what is in here and where it burns".
We ran a reproducible audit process in this order: gitleaks first (three seconds, catches forgotten API keys in git history; we found seven, two of them still active). Then semgrep with the auto ruleset (two minutes, catches 80 percent of OWASP Top 10 patterns; 23 findings, four of them critical). Then CodeQL for data-flow analysis (half an hour, catches what semgrep does not; three additional findings, all three actually exploitable). Then a manual architecture review along the auth and data-flow paths.
Total: three hours wall-time, 18 actionable findings, a 14-page report with severity, reproducibility, and fix proposal per finding.
Out of this engagement came the skill codebase-audit: the order, the tool selection, what belongs in which output report, when manual review steps are unavoidable.
How it works technically
Each skill is a Markdown file with two required fields in the frontmatter:
---
name: wordpress-hardening
description: Use this skill when working on WordPress sites,
addressing security vulnerabilities, hardening shared hosting
environments, or responding to webshell incidents.
---The body contains the playbook in prose: diagnostic steps, concrete commands, common mistakes, verification checklist. Plain language, no cross-reference tables per line. The agent understands the semantic context better when reading normal instructions than when parsing a mapping matrix.
The coding agent loads the skills at startup from the .claude/skills/ directory (or its platform equivalent) and matches the description semantically against what is being discussed in the conversation. When you say "I am migrating an Express server to Cloudflare Workers", it pulls the relevant skills (origin hardening, secrets management, Worker-specific caveats) into context automatically. You do not type a command.
For programmatic use there is an index.json. Anyone building tooling around it, for example an MCP server that serves the skills as resources or a CI system that boots the agent before each PR with the matching subset, can read the full catalogue from there.
Installation is git clone into the project root or into ~/.claude/skills/ for global use. No npm dependencies, no build steps, no runtime. Just Markdown files.
Five skills worth highlighting
From 34, here are the five we would have most often needed reactively, and which now live proactively in your agent's toolbox.
wordpress-hardening
Anchor of the entire library. Three-layer approach: account level (isolate all subs on a hosting account, set up the defense-pack cron), site level (Wordfence plus 2FA plus login lockout plus file-integrity monitor), forensics (mu-plugin as read-only audit backdoor logging hashes of wp-config.php, .htaccess, and all plugin roots hourly). When the agent works on a WordPress codebase and proposes file mutations, it first checks whether the site is still in a clean state.
ai-agent-guardrails
Answer to the question "what happens when the agent triggers a bulk operation it cannot undo?". Pattern: dry-run-first, plus confirm threshold (--apply from the Nth write onward, default N=1 for destructive operations). Plus logging of all mutations into an append-only file, against which the agent must check before each --apply whether it has not already run the same operation. Prevents the class "agent accidentally deletes 10,000 database rows because it misunderstood the idempotency guarantee".
codebase-audit
Methodology for inheriting unfamiliar codebases (see Engagement 4 above). Order, tool selection, output format. A coding agent loaded with this skill builds an AUDIT-FINDINGS.md in the repo root for each new project on first contact, and works against that report from then on, instead of starting from zero each session.
prompt-injection-defense
Pattern we call "untrusted-since-confirm". When the agent processes foreign input (Markdown from a user submission, contents of an email, output of a tool that is itself LLM-generated), that input is marked untrusted from the point of receipt and stays so until a human confirm happens. Concretely: no tool calls, no sub-agent spawns, no API writes based on untrusted content without explicit approval. Prevents the class "PDF with hidden instructions gets executed by the agent".
dach-compliance
Anchor for our local market. Imprint, privacy policy, terms under AT/DE/CH law; cookie consent under TTDSG/DSG; data processing agreements when using US subprocessors. When the agent builds a new page for a DACH client, it checks whether the three required pages exist and are correctly linked before signalling production-ready.
Plus 29 more: postgres hardening, backend architecture patterns, email security with DMARC/DKIM/SPF, mobile app security, secrets management, session/auth patterns, origin IP protection, et cetera. Full list in the repo.
Deliberate design choices
Three decisions we made explicitly because they are not self-evident:
Defensive only. No red-team material, no exploit PoCs, no skills that teach agents how to break through a WAF. We address teams that ship production code, not pen-testers. This decision excludes a whole class of possible skills, which makes the library smaller. That is intentional.
Experience over completeness. Every skill in the library comes from a concrete engagement we worked on. No theoretical material, no skills for topics where we have no first-hand practice. We would rather publish 34 skills in full depth than 200 in half.
Multi-platform format. Skills are pure Markdown with YAML frontmatter, no tool-specific code. We test primarily against Claude Code, but Cursor, Copilot, Codex CLI and Gemini CLI load them just the same. Pull requests for platform specifics are welcome. Compliance mapping (OWASP, PCI-DSS, ISO 27001) is deliberately not part of the library: that is the auditor's job, not the coding agent's. What the agent needs is clear instruction in readable language.
What is next
The next batch of skills is in progress, all from current or recently completed engagements:
- postgres-hardening (RLS patterns, connection-pool limits, pgaudit setup), from a multi-tenant SaaS engagement
- terraform-iac-security (provider auth, state-file encryption, drift detection), from a Q1 cloud migration for a client
- threat-modeling-with-agent (STRIDE-based, guided through the agent), from two architecture reviews where we used the agent as a structured interview partner for threat modelling
- kubernetes-cluster-hardening (PodSecurityStandards, NetworkPolicies, PSA migration), from a cluster audit currently in progress
Alongside that, we are evaluating an MCP server wrapper that serves the skills as a central resource, so you do not have to clone in every project but your agent pulls live from the index.
More posts in this series are coming. Today's companion article on dev.to covers ten antipatterns we keep seeing in AI-generated code in production, a good entry read before you install the library.
Get involved or work with us
Repo: github.com/GoldenWing-360/claude-security-skills, MIT licence, pull requests welcome. A curated prompt library in the wiki shows how to activate the skills in a live session.
Companion article on dev.to: 10 Security Mistakes Claude Code and Copilot Make in Production.
If you want these patterns applied to your stack, whether that is a WordPress conglomerate after an incident, a greenfield VPS setup with Cloudflare origin protection, an audit of your LLM-integrated backend services, or taking over an unknown codebase, get in touch. We do this professionally.
