6.1 Clear, Direct Instructions and System/User Placement

Imagine handing a new contractor a one-line brief: "make the report better." Better how? Shorter? More formal? With charts? The contractor will guess, and their guess will probably not match what you actually wanted — not because they're careless, but because you never told them. Claude behaves the same way. A vague or terse instruction doesn't make the model cautious; it makes the model fill the gap with its own assumption, and that assumption varies from run to run. Ambiguity is the single biggest cause of poor output, ahead of model choice, temperature, or almost anything else you might tune.

The fix sounds almost too simple to be a "technique": state the task, the constraints, and the desired output explicitly. Don't describe the shape of the problem and trust Claude to infer the shape of the answer — describe the answer directly. Tell Claude what **to** do, not only what to avoid; a system prompt built entirely out of prohibitions still leaves the actual target unstated. "Summarize this contract in three bullet points, each under 20 words, covering the term, the termination clause, and the payment schedule" leaves almost no room to guess wrong. "Summarize this contract" leaves everything to chance.

There's a natural instinct, once you've been burned by a bad output, to bolt on a prohibition: "don't add commentary," "don't use markdown," "don't include extra fields," "don't apologize." Each one feels like it's closing a hole. But a long list of "don'ts" only narrows what's excluded — it never actually describes what the target output looks like. You can forbid a hundred wrong answers and still not have specified the one right one.

A single positive instruction — "respond only with JSON matching this schema" — does more work than a paragraph of negatives, because it tells Claude what the target actually is, not just what it isn't. This is worth internalizing as a reflex: whenever you notice yourself writing "don't," pause and ask whether there's a positive version of the same rule. "Don't add a preamble" becomes "respond with the JSON object and nothing else." "Don't guess if unsure" becomes "if the answer isn't in the provided text, respond with null."

Clarity about the task is only half the job; clarity about the *output* is the other half, and it's easy to leave format to inference even after you've nailed the instruction itself. Output constraints mean spelling out the exact shape you need — "respond only with JSON matching this schema," "no preamble," "exactly three sentences," "under 50 tokens." The more precisely you describe the desired output, the less room the model has to introduce unwanted variance.

• •Shape — JSON against a named schema, a fixed list of allowed fields, a specific document structure.
• •Length — a sentence count, a word ceiling, a token budget; don't leave "how long" to guesswork.
• •Structure — ordering of sections, required vs. optional fields, whether prose or pure data is expected.
• •Absence — explicitly rule out a preamble, an apology, or added commentary when you need the output alone.

Output constraints and clear task instructions solve two different failure modes. A clear task instruction prevents Claude from doing the wrong *thing*; an output constraint prevents Claude from presenting the right thing in the wrong *shape*, which is just as damaging when a downstream parser or a strict word limit is waiting on the other end (Lesson 6.4 goes deep on the machine-readable case).

Every call to Claude has two very different kinds of content mixed into it, whether or not you've thought about the split explicitly: durable rules that should hold true no matter what request comes in, and the one specific request itself. Put durable role, rules, and constraints in the **system** prompt; put the specific request and data in the **user** message. Stable, reusable instruction goes to system; per-request content goes to user.

Think of the system prompt as the standing job description you'd hand a new hire on day one — "you triage support tickets, you only use these four categories, you never promise a refund amount." That description doesn't change ticket to ticket. The user message is the actual ticket that landed in the queue this minute. Keeping the two apart means the standing rules apply identically to every request, instead of being retyped, reworded, or half-forgotten each time.

One placement question trips people up specifically: where do output constraints — the exact shape, length, and structure you want — belong? Since the desired output format is usually a standing requirement rather than something that changes request to request, output constraints typically belong alongside the durable rules, in the system prompt, not re-specified piecemeal in every user message.

Now the trap. It's easy to state the system/user rule correctly in the abstract and still get a concrete scenario backwards: putting per-request data in the system prompt ("today's customer is Jane Doe, account #4471...") and putting stable rules in the user turn ("remember, you should always respond in JSON"). It's the reverse of the rule. Durable behavior belongs in `system`; specific content belongs in the `user` message — every time, regardless of how the scenario is worded.

• 1.Ask: does this piece of content change on every call, or does it hold true across all of them?
• 2.If it holds true across calls — role, rules, output shape — it goes in the system prompt.
• 3.If it's specific to this one request — the data, the question, the record — it goes in the user message.
• 4.Never let a per-request detail leak into the system prompt, and never let a standing rule live only in a user turn.