Security skills for coding agents.
Five open-source skills for Claude Code, Codex, Cursor and the rest: threat model a service, review every change against that model, audit the secrets, gate the release. Read-only by design. MIT.
Why a threat model and not a checklist
In October 2026 a generic review of the code behind Blankitt DMARC passed clean. A review that started from the threat model found that the service's inbound report address, which every customer publishes in public DNS, would accept a report for any domain and create that domain in the customer's account. Anyone who could read DNS could fill a paying customer's account with junk, push them past their plan cap, and put their own HTML into alert emails the service sent.
The code was tidy. The entry point was the hole. A checklist asks “is the input validated”. A threat model asks “who can reach this, and what can they make it do”. The second question found it, and it was fixed and deployed the same week.
These skills write that second question down once per service and ask it again on every change. We built them to run our own engineering. They are published so they can run yours.
The five skills
| Skill | When | What it does | Writes |
|---|---|---|---|
| /threat-model | Before the first review of a service, and again when an entry point is added. | Lists every way input reaches the system, the trust boundary each crosses, who can reach it, and what they can make it do. | docs/security/THREAT-MODEL.md |
| /threat-review | Before merging or deploying a change. | Reviews the diff against the threat model, not a generic checklist. Every finding carries the file and line, the actor, the impact and the smallest fix. | docs/security/reviews/ |
| /secrets-audit | Before a release, after adding a secret, or when a rotation is due. | Where each secret is read, set and could leak; which gates fail open when one is missing; what breaks on rotation. | docs/security/reviews/ |
| /pre-release | When you are about to deploy. | Read-only GO or NO-GO: clean tree, typecheck, tests, pending migrations, secrets present, logging on. Prints the one deploy command if GO. | Nothing. Chat only. |
| /setup-security-skills | Once per repo. | Finds how the repo ships and records it, so the other skills know your deploy command, secret store and health URL. | docs/security/release.md |
A second set for people who run systems (Linux hosts, containers, Microsoft 365) is listed in the repo and will ship one skill at a time, each after it has been run against a real system.
Install
Claude Code, as a plugin that updates itself:
claude plugin marketplace add technologyconsulting/security-skills
claude plugin install security-skills@technologyconsultingAny other agent, as editable files in your project:
npx skills@latest add technologyconsulting/security-skillsThen run /setup-security-skills once in the repo, /threat-model once per service, and /threat-review on your next change.
The rules the pack keeps
- Every skill reads and reports. The only files a skill writes are its own reports. Fixes, deploys and rotations stay with you.
- A finding without a file and line is not reported. The agent quotes the code it is pointing at.
- No company facts inside a skill. Your deploy command and secret store live in your repo, written by the setup skill.
- Same shape as Matt Pocock's skills: one SKILL.md per skill, small, editable, model-agnostic. His pack has no security step. This is the security step.
Found a failure in a real session? Open an issue on the repo with what you ran, what the skill did and what you expected. That is the bar for a change, and it is the only one.