When the Best Instruction Is a List of Things Not to Do

A few days ago NVIDIA shipped SkillSpector, a security scanner for AI agent "skills." Read that again. Not a scanner for binaries or container images. A scanner for Markdown instruction files. It checks for prompt injection, data exfiltration, privilege escalation, 64 patterns across 16 categories, and reports a 0-100 risk score before you let a skill near your agent. Their cited research, drawn from a dataset of 42,447 skills, says 26.1% carry at least one vulnerability and 5.2% look outright malicious.

Meanwhile Addy Osmani's agent-skills, "production-grade engineering skills for AI coding agents," has pulled in tens of thousands of GitHub stars. Two dozen Markdown files mapping the software lifecycle, and people are starring it like it's a framework.

So here's the field as of June 2026: we write plain-text files that tell a model how to behave, and those files now need a CVE scanner and a leaderboard. That's the anomaly worth sitting with.

And it lines up with something I noticed in my own setup. My most reliable agent isn't the one with the cleverest instructions. It's the one that's mostly a list of words it's forbidden to use.

The thesis

A good skill is mostly negative space. The leverage is in the constraints you impose and the context you force the agent to pull in, not in the capability instructions you write. The instructions barely move the needle. The guardrails are the product.

The artifact

I have an agent called ghostwriter. It writes in my voice, or close enough that I ship its drafts. The whole thing is about 100 lines of Markdown, and if you scanned it you'd assume I'd gotten the ratio backwards. The majority of the file is restrictions. The part that actually says "here's how to write" is short.

The single biggest section is a banned-words list. Around 25 of them: delve, leverage, utilize, harness, streamline, robust, pivotal, seamless, cutting-edge, innovative, keen, dynamic, realm, landscape, tapestry, synergy, testament, underpinnings, navigate (the figurative kind), unlock, elevate, foster, embark, vibrant, bustling. Then a list of banned transitions, the connective tissue that makes a paragraph smell like a model: moreover, furthermore, consequently, notably, indeed, "it's worth noting." Then banned openers and closers, your "In today's fast-paced world" and "Let's dive in" and "In conclusion."

But word lists are the easy part. The teeth are in the structural bans.

No "it's not just X, it's Y." No rule-of-three, the tic where every list and every sentence arrives in tidy triplets. No em-dash as a crutch, capped at roughly one per piece. No perfectly parallel bullet points where every item is the same length and shape. No hedging: "may," "might," "could potentially" are out, because a model hedges to avoid being wrong and a writer commits. And no summary paragraph at the end that restates what you just read.

Here's the thing I want to be honest about. I tried writing the positive version first. "Write engagingly." "Be specific and concrete." "Sound like a human." Every one of those did approximately nothing. The model already believes it's being engaging. Telling it to be specific produces specific-flavored vagueness. The output got noticeably better only when I stopped describing the destination and started naming the exact potholes: don't use that word, don't build that sentence, don't end that way.

There's one more piece doing quiet work. The file ends with a mandatory self-edit pass. After drafting, the agent has to reread its own output and hunt for its own tells against that ban list. Not "review for quality." Specifically: find the em-dashes you overused, find the triplet you fell into, find the word you were told to kill. The instruction that improved my drafts most wasn't about writing at all. It was forcing a second look at known failure modes.

I built a companion to it, a /write command, and its first phase is a mandatory human interview. The agent is forbidden from drafting until it extracts real specifics from me. The exact numbers, the actual debugging story, the opinion I'll defend. The constraint is blunt: you may not proceed. Funny enough, this article was supposed to run through that interview and I wasn't around to answer it. Which is the whole argument in one bruise. The model's missing ingredient is almost never capability. It's the specific thing only I know.

What's actually going on

The model isn't short on ability. It can write a clean sentence in any register you want. What it lacks is judgment about what not to do, and judgment about which context to ignore versus drag in. Left alone it reaches for the statistically average phrasing, which is exactly the phrasing that reads as machine-made, because it is the average of the machine's training.

This is what "context engineering" looks like in practice once you get past the slides. The 2026 framing, the move everyone's been making from "prompt engineering" to "context engineering" (see LangChain's State of Agent Engineering and Anthropic's 2026 Agentic Coding Trends report), is mostly described as feeding the agent more and better context. In my experience it's the opposite motion. It's subtraction. Strip the average responses the model wants to give, and force in the one input it can't generate on its own. You're not stacking instructions. You're carving them away and replacing the gap with something real.

Where this breaks

I don't want to oversell it, because constraint-first has clear failure modes.

It's useless on genuinely novel work. You can't ban what you haven't watched break. The first time I point an agent at an unfamiliar problem, I have no list, because I don't yet know how it'll fail. The ban list is a fossil record. It only exists after the mistakes do.

Over-constrain and you strangle the thing. I've written skills so tight the agent had no room left to be useful, refusing reasonable phrasings because they brushed against a rule. There's a real line between guardrail and straitjacket, and I've crossed it.

It also leans on a capable model. A big model holds 40 simultaneous constraints and mostly respects them. A smaller or older one starts dropping rules silently around constraint 15, and you won't know which ones. And every line of bans eats context budget you could've spent on the actual task. A 100-line skill isn't free.

The objections

Two fair hits.

First: "this is just prompt engineering wearing a new hat." Partly true, and I won't pretend the line is crisp. The difference that matters to me is durability. A prompt is something you type and discard. A skill is a versioned artifact you maintain, that compounds, that survives the session. Naming it differently is marketing. Treating it as code you maintain is not.

Second, and stronger: "smarter models will make these guardrails obsolete." Some of them, yes. The day the base model stops reaching for "delve," that line in my file becomes dead weight and I'll delete it. I fully expect to retire a chunk of the ban list over the next year. But the discipline outlives any single rule. The act of catching a failure, naming it precisely, and encoding it so it can't recur is not a model-version problem. That's just engineering. The specific words age out. The practice of writing down what you learned the hard way does not.

A skill file isn't a manual for what the agent should do. It's a written record of every mistake you've already made, kept so the agent can't make them again.