Getting to a good prompt: structure, role, example, and output format

Target audience: technical + engaged non-technical | Prerequisites: 1.3 Prompt fundamentals

What you'll learn

After this document you will be able to:

• turn a properly written prompt (the instruction given to the model) into the basis of a reusable prompt template (a reusable frame of instructions — fixed parts + placeholders);
• distinguish the template's fixed parts from the variable ones and write placeholders clearly as [NAME_IN_CAPITALS];
• take a prompt through the test cycle: test cases, a variant comparison table, and acceptance criteria;
• steer the answer's tone and depth with the role's wording, and demand a consistent output every time.

In plain terms

The good prompt written in document 1.3 is a successful dinner. A prompt template is the recipe: the same food arrives at the table tomorrow too, and even when someone else is in the kitchen. The unchanging part — the measurements and the oven temperature — is the tested, fixed wording of the instructions; the variable part — carrots today, pumpkin tomorrow — is the placeholders, where you paste in each run's data.

From a weak prompt to a template

Document 1.3 showed that a reliable prompt consists of five parts. That works well for one single run. But business-valuable tasks repeat: invoice questions come every day, summaries every week. If you write the prompt from scratch each time, time is wasted and every version is a little different — the result fluctuates along with the instructions.

A prompt template solves this: work done well once is put into a frame in which the fixed parts always stay the same and the changing spots are marked with a placeholder [NAME_IN_CAPITALS] — a spot in square brackets, in capital letters, and named with underscores, into which each run pastes new data. The template becomes a tool the whole team uses: the same input produces a result of the same quality.

One realistic cost nuance: the fixed wording spends a few tokens each time (a token — roughly one word or part of a word), but as long as everything fits into the AI model's context window (the amount of text an AI model can see at once), that is a cheap price for a consistent result.

The parts of a template: fixed and variable (placeholders)

Fixed parts are the fixed wording that must always be exactly as tested: the role, the task description, the rules, the output format requirements, and the examples. Changing them is not “a small fix along the way” but a new version of the template, which must be tested again.

Variable parts are the placeholders. Three rules keep them clear:

1. The name says what goes there. [CLIENT_LETTER] means the entire text of the letter, not just the client's name — [CLIENT_NAME] would be a separate placeholder.
2. Every variable spot is marked. The basic pattern is always the same: fixed instruction on top, a clear delimiter, and the data below.
3. An empty placeholder has a rule. An instruction like “if there is no data, write 'missing'” stops the model from guessing at gaps.

The template's skeleton can be written down like this:

[ROLE — fixed part]
[TASK — fixed part]
[RULES — fixed part]
[OUTPUT FORMAT — fixed part]
[EXAMPLES — fixed part]

CLIENT_LETTER:
[CLIENT_LETTER]   ← variable part

In plain terms: the fixed parts are the recipe's measurements and the placeholders are where you add today's ingredients. You change the recipe only after you have tried the new version through — the same goes for the template.

The test cycle: how to know a prompt is good

A new prompt is not approved on the basis of one successful attempt. The test cycle is a repeatable procedure that makes the quality decision on evidence, not feelings:

1. Pick 3–5 test cases with different inputs: a typical case; a case where the data is sparse or unclear; an exceptional case; and one that contains something that must not be answered. The best ones are real old cases (client data anonymized).
2. Run the template on every case and save the outputs.
3. Compare the outputs against acceptance criteria — agreed requirements which, when met, make the result count as good. For an invoice transaction summary, for example:

1. Make one change at a time and give the version a name (A, B, C). Run the new version through all the same test cases and put the results into a comparison table:

When is it enough, and when to go back? When every test case passes every criterion and a couple of days of real use pass without a fix, the template is approved. If some case breaks one criterion, go back: one change, a new version, a new round. Side rule: don't make several changes at once — otherwise you no longer know which change helped. The outputs and the version history are kept in a fixed place — where and how, 2.6 teaches.

Role and output format in more depth

Document 1.3 introduced the role as one line: from whose angle the answer is given. In practice, the role's wording steers much more than tone — the precision of the vocabulary, the level of detail, and what the model undertakes at all. The same task, three roles:

The content designer's job is to pick a role from the strictness scale: the more costly a possible mistake, the stricter the role.

In plain terms: the role is a job description given to the model. The same “employee” behaves completely differently depending on whether you tell it “be kind and help with everything” or “you are not allowed to add anything”. With an unbounded job description, everything is allowed — and the model adds what you didn't ask for, too.

Output format every time. The secret of consistent output is the precision of the format requirement:

• describe the shape concretely: field names, order, length;
• state what to do with missing information;
• forbid extras you didn't order: introductions, commentary, phrases like “here is your answer”;
• if the output goes on to a program, require a machine-readable form — 2.2 teaches that technique.

The output is only three lines with the headings QUESTION, DEADLINE, REQUIRED ACTION.
If there is no data, write “missing” — don't guess.
Don't add an introduction, a conclusion, or sentences like “here is your answer”.

A step-by-step example: the Number Bureau's invoice transaction summary template

The Number Bureau (1.6) again: clients write in with invoice questions and the accountant needs a consistent summary of every letter, visible within seconds — the question, the deadline, the required action. As the content designer, the accountant puts the template together; the reviewer still checks the results, because a human stays in the loop (human-in-the-loop — a workflow where a human approves the result before it is used).

Step 1 — the initial version (version A):

You are an accounting firm assistant. Read the client's letter and summarize:
what the question is, what the deadline is, and what needs to be done.
CLIENT_LETTER: [CLIENT_LETTER]

Step 2 — three test cases:

1. Typical: “Hello! Is invoice no. 1421 still unpaid, and by what deadline?”
2. Unclear: the letter talks about two topics, no deadline is mentioned, the amount is mentioned in a subordinate clause.
3. Extreme: the client writes that the invoice “seems wrong” and asks for advice on what to do — there is little data.

Result: case 1 passed. Case 2 exposed a weakness — the model wrote “30 days” as the deadline even though it wasn't stated anywhere: a hallucination (a confidently stated but wrong answer from the model). Case 3: the answer started with the words “Of course, happy to help!” and gave advice, even though the task is only a summary; the headings wobbled (“Time” vs “Deadline”).

The weaknesses: (1) guessing at missing information; (2) extras nobody ordered and an unstable format; (3) the role doesn't forbid advising.

Step 3 — version B: one change for every weakness — the added rule “missing information stays 'missing'”, a stricter role (summary only, not advising), and the format set in stone together with the forbidden extras. Every weakness got its own row in the comparison table, so every change's effect is still separately traceable — with several changes at once, the requirement is that each one must have its own traceable criterion.

Step 4 — the comparison table:

Version B passed every case.

Step 5 — the approved final template:

You are an accounting firm data processor. Your only task is to summarize
the invoice question in a client's letter. You do NOT give advice and do NOT
reply to the client — a colleague reads your output.

Rules:
- Use only the facts stated in the letter.
- If information is missing, write “missing” where that field belongs — don't guess.
- Don't add an introduction, don't comment, and don't end with a courtesy phrase.

Format (always exactly like this):
QUESTION: [one sentence]
DEADLINE: [a date or “missing”]
REQUIRED ACTION: [one sentence]

CLIENT_LETTER:
[CLIENT_LETTER]

The check remains: the accountant reviews every summary before acting on it — the template reduces work, not responsibility (see 1.6). The template is written down together with its version number and test cases; where and how, 2.6 teaches.

Summary

• A prompt template is a reusable frame of instructions: the fixed parts (role, task, rules, format, examples) always stay the same, and the variable data is pasted into the [NAME_IN_CAPITALS] placeholder.
• Fixed parts are not changed without new testing — every change is a new version that goes through the same cycle.
• The test cycle is 3–5 test cases, acceptance criteria, and a variant comparison table — “good” is not a feeling, but meeting the criteria on every case.
• The role steers tone, depth, and boundaries — in data processing, a stricter role is usually better than a “helpful assistant”.
• The format's precision guarantees consistency: field names and order set in stone, missing information marked, extras nobody ordered forbidden.

What's next?

• previous → 1.6 Roles and responsibility in a project
• next → 2.2 Structured output: lists, tables, and JSON
• Where to keep and version prompts → 2.6 Prompt management as an asset
• Multi-part processes where the template is one step → 2.3 Basic workflows: steps and conditions
• back → handbook index