Design system prompts, templates, and guardrails

Key points

1. 1

   The system prompt is the operator channel: role, scope, standing boundaries, output format and, for every boundary, the behaviour to use instead (redirect, decline politely, ask a clarifying question). Even a one-sentence role changes tone and focus.

2. 2

   Write at the right altitude. Hardcoded if/else logic is brittle, breaks when a rule is added and encourages over-refusal; vague guidance gives no direction. Aim for concise principles, strong heuristics and a few canonical examples.

3. 3

   Be clear and direct: replace adjectives such as 'short' or 'professional' with checkable criteria (sentence limits, register, required closing), and explain why a rule exists. Current models follow instructions literally and respond strongly to the system prompt, so dial back emphatic 'MUST' and capitals, which cause over-triggering rather than precision.

4. 4

   Structure with XML tags: separate <instructions>, <context>, <examples> and <input> so the model knows what each block is for. Wrap examples in <example> tags so they are not mistaken for data.

5. 5

   Templates keep static instructions in the system prompt and put variable, user-supplied content in the user turn inside delimited tags, with a statement that the tagged content is data to process, not instructions. Interpolating raw user text into the instructions invites prompt injection.

6. 6

   Render templates in a fixed order with the static parts first so the prefix is stable and cacheable; put timestamps, user names and per-request values after the static block or in the user turn.

7. 7

   Split guardrails by the strength of guarantee needed. Prompt instructions shape probabilistic behaviour (tone, style, refusal wording). Anything that must hold every time (pattern blocking, verbatim disclaimers, schema validity, identity verification, authorisation) is enforced by code: output filters, structured outputs, tool-handler gates and permission-aware retrieval.

8. 8

   Not controls: repeating a rule, moving it to the user turn, keyword stripping of inputs, temperature zero, self-reported confidence, or a second LLM reviewer as the only check. Each reduces risk at best and none makes a requirement guaranteed.

9. 9

   Assistant prefill on the last turn is not supported on current models; use structured outputs, strict tool schemas, 'respond without preamble' instructions or XML output tags instead.

10. 10

    Mid-conversation operator instructions are appended as a system-role message in messages on models that support it, rather than editing the top-level system prompt, which would invalidate the cached prefix.

11. 11

    Treat prompts as code: version them, compose them from modules, and cover every rule with an eval so a change to wording is measured rather than assumed.

Read the source

• Prompting best practices
• Prompt engineering overview
• Mitigate jailbreaks and prompt injections
• Effective context engineering for AI agents