AI Guides › Skills & Agents
Writing A Skill Nobody Else Can Misuse
By Nigel Guy · 2 min read
You write a skill for the way you use it — the specific tool version, the specific data shape, the specific situation you had in mind. Then someone else picks it up, applies it to a slightly different situation you never considered, and it does something confidently wrong. The skill wasn't broken. It was never scoped to say what it wasn't for.
The rule: a skill that can be misused hasn't been finished — the scope and boundary lines are as much a part of the skill as the steps are, and they need writing down, not assuming.
The mechanism
- State the situation the skill is for, specifically. Not "for scheduling," but "for booking a single internal meeting between two calendars you both have edit access to." The narrower and more concrete the stated situation, the less room there is to stretch the skill somewhere it wasn't built for.
- State the adjacent situation it is not for. Someone reasonable, glancing at what the skill does, will try to use it for the neighbouring task. Naming that neighbouring task explicitly — and saying "not this" — is the single highest-leverage line you can add.
- Name the assumption the skill quietly relies on. Every skill has at least one — a format, a permission level, a starting state — that it never checks, just assumes. Write it down. An assumption that's stated can be checked by whoever's using the skill; one that's silent gets discovered by the failure.
- Put a stop condition in the steps themselves, not only in the guardrails. "If the input doesn't match this shape, stop and flag it" belongs in the procedure, at the point where the mismatch would occur — not buried in a caveat at the bottom that nobody reads mid-task.
- Have someone else try to break it. Hand the skill to a colleague, or imagine a use case slightly outside what you had in mind, and see where it produces a confident wrong answer instead of stopping. Every gap you find here is a boundary you hadn't written down yet.
What to skip
Skip writing a scope statement so broad it covers every possible use — "for general productivity tasks" scopes nothing. And skip assuming good judgement will fill the gaps; the whole point of a written skill is that it doesn't rely on the user independently noticing where it stops applying.
Guardrails
- No amount of scoping makes a skill misuse-proof. It reduces the surface area for the most predictable misapplications; it doesn't anticipate every one.
- A skill's boundaries need revisiting whenever its actual use drifts — if people keep reaching for it just outside the stated scope, that's a signal to either widen the scope properly (with the mechanism re-checked for the new case) or restate the boundary more firmly, not to quietly let the drift continue.
- This is a companion to the guardrails section covered elsewhere in this library, not a replacement for it — scope tells you where the skill applies; guardrails tell you what can go wrong even inside that scope.
All 751 AI guides · JulieMango plans from £17/mo