How to Write a "When Not to Use" Clause
The clause is one sentence. Most skills do not have it, and most of the ones that do put it where the router cannot see it.
Only 0.5% of taglines state what a skill will not do. 25.6% of skill bodies state it somewhere. The first number is the problem; the second is the raw material.
The clause belongs in the description
The router reads the description to decide whether to load the skill. A boundary in ## Boundaries is read after that decision. Moving the same sentence into the description changes behaviour; keeping it in the body only documents intent.
Three patterns that work
1. Name the adjacent request and the alternative.
> Not for writing new contracts (use a template library) or for jurisdiction-specific legal advice (use a qualified reviewer).
This is the strongest form. It tells the router both what not to do and where to send the request.
2. Name the precondition that is missing.
> Requires access to the production database. Do not use for schema design or migration planning.
Useful when the exclusion is about capability rather than topic.
3. Name the output that is out of scope.
> Produces copy only. Not for publishing, scheduling, or image generation.
This prevents the skill from being loaded for the last mile of a workflow it only partially covers.
Three patterns that fail
Too broad. "Not for anything outside marketing" excludes almost nothing — every request can be argued into a category. Exclusion needs a concrete adjacent request.
Self-deprecating. "This skill is basic and may not be suitable for complex tasks." The router cannot act on a vibe. Say which tasks.
Buried. A single "not" in a 400-character description, after three paragraphs of capabilities, is easy for a model to under-weight. Put the exclusion in its own short sentence, near the end.
The five-minute test
Write three requests that should not trigger the skill. For each, read only the description and ask: does it contain a reason to decline?
Example for a cold-email skill:
- "Write a landing page for our new product." → Description says copy and sequences for email; does it exclude landing pages?
- "Analyze why our reply rate dropped." → Description says writes and audits; if audits are in scope, this should fire.
- "Send the campaign to 5,000 contacts." → Description should say it produces copy but does not send.
If the description cannot decline request 1, add the clause. If it declines request 2, the trigger is too narrow.
Keep it short
One sentence, maybe two. A description that lists every possible exclusion becomes a specification, and the trigger gets crowded out. The goal is not completeness — it is a clear boundary around the most likely misfire.
The best clauses in this corpus share a tone: confident enough to lose a request on purpose.