How do you write a prompt for a production LLM feature?

Write it like a brief for a capable new colleague: say who the output is for and why, give clear, specific instructions, separate instructions from data with clear structure (for example XML tags), show 3 to 5 varied examples of good output, and state the format you need. Then treat the prompt as code: version it, test it against an evaluation set, and change it only when the numbers say so.

The parts of a good prompt

1. Role and context. What the product is, who the user is, what the output will be used for. Anthropic's prompting guide notes that explaining why an instruction matters helps the model apply it sensibly to cases you did not foresee.
2. The task, clearly. Specific and explicit. If you want thoroughness, say so; current models follow instructions closely rather than guessing at hidden intentions.
3. Rules and boundaries. What to do when information is missing ("say you don't know and offer a hand-off"), what is out of scope, the tone.
4. Examples. Few-shot examples are the most reliable way to show format and style. Make them varied, so the model does not copy one example's details, and mark them clearly as examples.
5. Input data, clearly separated. Wrap documents, user messages and variables in tags such as <context>, <document> and <input>, so the model never confuses data with instructions.
6. Output format. A schema (better: structured outputs), a template, or a length limit.

A skeleton

You draft replies for the support team at an online shop. Agents edit and send them.
<instructions>
Answer only from the policy and order data below. If they don't cover the question,
say so and suggest a hand-off. Keep replies under 120 words, friendly and plain.
</instructions>
<examples> ... 3 varied examples ... </examples>
<policy> {policy} </policy>
<order> {order_json} </order>
<customer_message> {message} </customer_message>

Production habits

• Keep the stable parts at the start and the variable parts at the end, which also lets prompt caching work.
• Store prompts as versioned templates, not strings scattered through code.
• Run the evaluation set before every change, and log which prompt version produced each output.
• Remove instructions that no longer help. Prompts grow by patching; prune them.

What not to rely on

The prompt is not a security boundary. Rules that must never break (permissions, limits) belong in code.

A strong closing line: "I write the prompt for clarity, then let the evaluation set tell me whether each change helped."