Why I Rejected an 817-Skill Security Pack and Wrote a 2-File Threat-Model Skill

Last week someone shared a repository of 817 ready-made cybersecurity skills for coding agents. My first instinct was the obvious one: install it, instantly upgrade my agent fleet's security game. Instead I spent an evening actually reading what those 817 skills do — and then wrote my own skill. It is two markdown files.

Why 817 skills were the wrong 817

The repo wasn't bad. It was mis-aimed. The bulk of it covers SOC work, forensics, incident response — jobs I don't do and my agents don't do. And it was thin exactly where my products live: web and API abuse, bot farms, prompt injection into agent pipelines.

That's the trap with mega-packs of agent skills: coverage looks like capability. But an agent doesn't need a skill for every discipline of security. It needs depth in the one place generic checklists structurally fail.

That place is abuse economics — the ways a product's own business logic pays an attacker or burns its own users. No checklist finds it, because it isn't a property of TLS configs or dependency versions. It's a property of your referral bonus, your reward grant, your free-credit faucet.

The two-sentence core of the skill

The skill I wrote is built around one principle and its mirror image:

The client is the attacker. Every value the server accepts from outside a trust boundary was written by someone trying to get paid. It doesn't matter how obfuscated your app is — the attacker doesn't need your client at all; they replay the HTTP calls. Design as if the app were a published API.

The client is also the victim. Everything the server sends out gets rendered, opened, or executed on a device that trusts you. A landing URL stored as free text and validated nowhere is your product acting as a delivery vehicle for someone else's payload.

Everything else in the skill is machinery for applying those two sentences systematically instead of vibes-based.

Nine lenses, ranked findings, no theater

The skill walks the agent through nine lenses: untrusted client, identity and session, abuse economics, content trust, privacy of held data, resource abuse and cost, blast radius, bots and automation, and agent surfaces. Five of them carry most of the weight; the rest exist so that skipping them is an explicit, recorded decision rather than an oversight.

A few probes, to give the flavor:

Two rules keep the output honest. First: one side alone yields hypotheses, never findings. Client code tells you what the client sends, not what the server demands. The skill forces the agent to locate and read both sides of every boundary, and to label each finding confirmed (every side that could refute it has been read) or assumed (naming the exact check that would settle it). Second: findings are ranked by impact × ease — what one success is worth, times how cheaply it repeats. A scriptable reward farm outranks a theoretical RCE that needs a rooted device and a stolen key.

Fixes that can't be forgotten

The skill also encodes a house preference order for fixes, from most durable to fastest-rotting:

Attestation, obfuscation, and certificate pinning come last: high upkeep, and they only raise the cost of an attack the server should have refused anyway.

This ordering was paid for in production. A case-sensitivity bug in email matching once let a single mailbox — registered twice with different capitalization — spawn several accounts and orphan a user's token balance across two services. No test caught it, because the author's tests shared the author's blind spot. A unique index on the normalized email would have held even while the application code was wrong. That incident is now literally baked into one of the lenses, down to the unicode details: plain lower() is locale-sensitive, and neither it nor NFKC strips zero-width characters — normalize properly at ingest, then pin the result with an index.

Three tools, three jobs

The last design decision was drawing hard boundaries against my other review tools, because blended tools rot into one mushy checklist:

When a threat-model run stumbles onto a hygiene gap, it names it in one line and routes it elsewhere instead of absorbing it. Each tool stays sharp because each tool stays narrow.

The takeaway

If you're building with coding agents, the temptation is to accumulate capabilities — install the 817-skill pack, feel armored. The better move is the opposite: find the one class of problem where your products actually bleed, and encode your hard-won incidents, your fix preferences, and your division of labor into something small enough that the agent reliably loads and follows it.

Two files beat 817 — if the two files know where you live.

Related reading