Negative instructions fail for a mundane reason: a bare prohibition carries almost no information. "Do not mention competitors" doesn't say what to do when a user asks about one directly, whether naming a competitor's product category counts, or why the rule exists. The model is left to guess at the boundary — and boundary guesses are exactly where "do not" clauses break. The patterns below turn thin prohibitions into rules Claude can actually execute.
Pattern 1: say why — the documented fix
Anthropic's prompting best practices make this explicit with a memorable example: instead of "never use ellipses," write that the output "will be read aloud by a text-to-speech engine, so never use ellipses" — because Claude generalizes from the explanation. The reason is what lets the rule extend to cases you didn't list: a model that knows the TTS constraint will also avoid other unpronounceable typography, not just the one character you banned.
Apply the same move to business rules. "Do not quote delivery dates, because dates are set by the fulfillment system and a wrong promise creates a contractual issue" gives Claude both the boundary and the stakes — enough to handle the paraphrase, the hypothetical, and the indirect question the literal clause never covered.
Pattern 2: pair every "don't" with a "do instead"
A prohibition alone leaves a hole where behavior should be. Fill it: "Do not provide legal interpretations. Instead, summarize the clause factually and direct the user to the legal team's intake form." This follows straight from Anthropic's golden rule — a colleague with minimal context, told only what not to do, would be confused about what to do; so will Claude. As a bonus, the replacement behavior converts an awkward mid-response swerve into a designed one.
Pattern 3: state the positive form first
Where a rule can be expressed as a positive requirement, lead with that and keep the negative as reinforcement: "Answer using only the provided policy documents. Do not draw on outside knowledge." The positive sentence defines the behavior; the negative sentence marks the boundary. Anthropic's "be clear and direct" guidance favors telling the model exactly what you want — prohibitions work best as fences around a clearly described field, not as a substitute for describing it.
Pattern 4: show the refusal in an example
The official guidance recommends 3–5 relevant, diverse examples wrapped in <example> tags. Spend at least one on the negative rule firing: a user asks the forbidden thing, and the example response declines gracefully and pivots to the "instead" behavior. A demonstrated boundary is far more robust than a described one, and it also fixes the tone of the refusal — which otherwise tends to come out either preachy or apologetic.
Pattern 5: know when prose is the wrong enforcement layer
Some "do not" rules shouldn't be prompt rules at all. Format prohibitions — no extra keys, no prose around the JSON, no markdown — are guaranteed mechanically by structured outputs: pass a JSON Schema via output_config with additionalProperties: false and the shape is constrained by the API rather than requested by the prompt. (Note the older trick of prefilling the assistant's reply to suppress preamble is gone: per Anthropic's docs, prefilled responses return a 400 error from the Claude 4.6 generation onward, with structured outputs and direct instructions as the named migrations.) Likewise, "never call the delete tool" is better enforced by not offering that tool in the request — or restricting it with tool_choice — than by asking nicely. Prose rules are for judgment; mechanical constraints are for invariants.
Keep the list short and tested
Negative instructions accumulate like scar tissue — each incident adds one, and nobody deletes. A system prompt with forty prohibitions dilutes the five that matter. Periodically consolidate overlapping clauses, promote mechanical ones to schema or tool constraints, and keep a small regression set of inputs that historically triggered violations so you notice when a rewrite weakens a fence. Anthropic's prompt-engineering overview puts empirical tests against clear success criteria ahead of all prompt tuning; "the do-not rules still hold" is one of the cheapest evals you can run.
Where to go next
Negative rules are one layer of a defense; see guardrail design and refusal handling for the rest. For which rules belong in prose versus schema, read output format control, and for rule precedence, instruction hierarchy.