Writing Each Layer

Understanding the anatomy is necessary. Writing each layer well is the skill. This chapter offers practical guidance for constructing each component, with attention to the kinds of mistakes that undermine otherwise well-intentioned prompts.

Writing the Role Definition

Start by writing a two-to-three sentence description of the model's identity in plain language. Ask yourself: if a new colleague joined your team and you needed to brief them on who they were and what they were there to do, what would you say?

Then extend that description with three or four specific capability statements. These are not generic ("you are knowledgeable") but domain-specific ("you are familiar with EU procurement frameworks and can interpret contract language in that context").

Avoid superlatives and vague claims of excellence. "You are the world's best analyst" contributes nothing. "You are experienced in synthesising cross-functional data into executive-level briefings" gives the model something it can operationalise.

Writing Behavioural Rules

Write behavioural rules as explicit directives, not as suggestions. Use imperative constructions: "Always cite your reasoning before presenting a conclusion." "When asked for a summary, limit your response to five sentences unless the user specifies otherwise." "If you are uncertain about a factual claim, state your uncertainty explicitly before proceeding."

Avoid rules that are so broad they provide no real guidance. "Be helpful" is not a behavioural rule. "When a user's request is ambiguous, ask one clarifying question before attempting a response" is.

A useful drafting technique is to think about the last three times a model gave you a response that frustrated you, and to write a rule that would have prevented each of those failures.

Writing Context Injection

Context injection should be written as factual statements about the user and their environment, not as instructions. The distinction matters. "The user is a compliance manager at a financial services firm" is context. "Always write as if you are speaking to a compliance manager" is a behavioural rule. Both are useful, but they serve different functions and should be kept in separate sections for clarity.

Keep context statements concise and factual. Avoid padding. If a piece of context would not change how the model responds to at least some questions, it probably does not need to be there.

Writing Output Format Specification

The most reliable approach to format specification is to describe your ideal response to a typical query, and then reverse-engineer the rules that would produce it. If your ideal response is a structured briefing with a headline summary, three supporting points, and a recommended next action, write that structure down as an explicit template.

If you use the output in a specific downstream context, for example pasting model output into a report template or feeding it into a workflow, describe that context explicitly. "Your output will be pasted directly into a client-facing report. Do not include meta-commentary about your reasoning process. Do not add closing offers to help further."

Writing Constraints

Write constraints as explicit negations: "Do not provide specific legal interpretations." "Do not speculate about competitor pricing." "Do not generate output in languages other than English and Dutch."

Be specific. "Do not go off-topic" is not a constraint the model can apply reliably. "If the user asks about topics unrelated to financial operations, politely redirect the conversation and explain your scope" is.