Say What To Do

"Don't use var" makes the model hold a forbidden thing in mind. "Use const and let" gives it a target. The framing changes how often the rule sticks.

Why this, for you: two levers hide inside every rule's wording — its polarity (do this vs. don't do that) and its negative space (the goal vs. the boundary). Both move compliance, and most people set them by accident. This lesson makes them deliberate.

Same rule, two framings. "Avoid long functions" and "Keep functions under 30 lines" forbid the same thing — but one names a target the model can execute, and the other leaves the correct behaviour implicit. Implicit is less reliable.

1 Positive beats negative — usually

A negative instruction demands suppression: the model holds the prohibited action in mind while choosing not to take it. A positive instruction demands execution: it names the target and performs it. Token generation favours selection over avoidance.

The gap is small with a handful of rules and compounds as instruction count grows. Negative rules degrade first under a large set — the suppression signal competes with a rising tide of execution targets.

Anthropic's guidance puts it plainly: "Tell Claude what to do instead of what not to do." Most prohibitions reframe cleanly:

Negative	Positive
Do not use `var`	Use `const` and `let` only
Avoid long functions	Keep functions under 30 lines
Never hardcode secrets	Store all secrets in environment variables

The pink-elephant trap

Negation isn't a solved capability. A "don't think about a pink elephant" effect can make the banned concept a stronger prior, raising the rate of prohibited output instead of lowering it (Truhn et al., 2025). It varies by model size and language — another reason the positive form is the safer default.

2 When to keep it negative

Polarity is a default, not a law. Keep the negative form — and move it toward the top of the set, where primacy attention is strong — when:

The acceptable space is too large to enumerate — "Do not modify infrastructure files" beats listing every allowed file.
The ban is absolute and the positive form is ambiguous — "Never push directly to main" vs. "Push to a feature branch" (which branch? which repo?).
You're naming one specific banned item — "No console.log in production code."

3 Negative space: goal and boundary

Polarity asks "how do I frame this rule?" Negative space asks a different question: "should I state the goal, or the boundary?" The answer is usually both. A negative constraint is binary and greppable — the agent either produced the banned phrase or it didn't, no judgement required.

# positive directive sets the goal… Be direct and information-dense. # …negative constraint closes off the common wrong reading — and it's checkable: No filler: "in this guide", "let's explore", "as you may know"

"Write concisely" needs a human or a second model to evaluate. "No 'in this guide'" needs a grep. If a constraint can't be expressed as a deterministic check, it probably belongs in the positive half instead. Palantir's guidance documents the same point: banning specific undesired outputs is more reliable than describing desired characteristics.

If failure is unacceptable, it's not an instruction

When you catch yourself writing "never" or "must not," ask whether it should be a hook. A pre-commit hook that rejects var enforces deterministically. An instruction asks; a hook requires. Instructions are probabilistic — reserve them for what tolerates the occasional miss.

↪ Your win: frame for execution, close with a greppable boundary

Default to positive — name the target behaviour; the gain grows with rule count.
Keep negatives for absolutes — huge acceptable spaces, hard bans, specific banned items — and front-load them.
Pair goal with boundary — positive directive for direction, negative constraint to close the common wrong path.
Design for greppability — if you can't check it automatically, it's probably positive guidance.
Promote must-never-fail rules to hooks — instructions ask, hooks require.

Retrieval practice — recall, don't peek

Question 1Positive instructions tend to win because they ask the model to…

Question 2The polarity gain between positive and negative forms…

Question 3A keep-it-negative case is when the acceptable space is…

Question 4The design criterion for a good negative constraint is that it's…

Question 5 · spaced recall from Lesson 1The right "altitude" for an instruction describes…

Ask me anything. Want a pass over your instruction file flipping negatives to positives, or help deciding which "never" rules should become hooks? Next in Part 2: Top and Tail — placing the one rule that must not be missed.