Anatomy of an Operator and a Playbook

Most system prompts fail because they confuse atmosphere with instruction. The model gets a persona, a tone adjective and very little operational guidance, then produces something that reads plausibly and cannot be relied on twice.

A working setup reads more like a contract than a character sheet. In MyPromptVerse that contract is split across two objects: the Operator carries the role and the rules that hold on every job, and the Playbook carries one job's inputs, instruction, output sections and rubric. (If those terms are new, Prompt, Playbook, Operator, Knowledge explains the split.) The same parts apply if you keep everything in one system prompt; the split just makes each part easier to find and change.

The running example below is a setup that drafts customer-facing feature announcements from internal release notes.

Before the parts: is this a recurring job?

Everything in this guide is for work you do again and again. A plain question needs a lean prompt, and we have the numbers to show why.

In October we asked our own app to "say hello in five words". The reply took about 30 seconds and 5,325 tokens on openai/gpt-5-nano. The provider was not slow, at around 177 tokens a second. The cause was ours: when no operator or playbook was chosen, the app quietly attached the first ones in the workspace, which were a Product Spec Operator and a Feature Spec Builder playbook. A five-word greeting was handed to the model as a product-spec task, and a reasoning model with no limit on how hard to think spent thousands of hidden tokens working out how to write a spec for it.

The assembled prompt itself was only around 670 tokens. The damage came from what it told the model the job was. We changed the app so that an empty choice means no operator and no playbook, and plain questions now get a lean prompt with one rule, any context you attached, and your message. The full skeleton below is what you reach for once a job repeats.

The Operator: a job and its standing rules

Name the job, not the persona

"You are a world-class product marketer with a sharp eye for narrative" sets a mood. It does not say what to produce, what to leave out, or when to stop. Replace the title with the recurring job and the audience in a sentence or two:

You write customer-facing feature announcements from internal release notes, for customers who use the product but did not follow its development. An announcement explains what changed, who it affects and what the reader should do next. It never describes unreleased work.

That version is testable. Two people given it would produce comparable work, which is the real bar. A persona cannot be failed; a job can.

Current guidance from Anthropic, OpenAI and Google agrees that a short role helps and an elaborate one narrows the answer, so the role stays at this length.

Standing rules, with their reasons

Rules that hold for every announcement go on the Operator, each with the reason behind it. Models generalise from reasons far better than from bare prohibitions:

• Describe only work the notes mark as shipped, because customers act on announcements and a missing feature costs trust.
• Replace internal codenames with the customer-facing name, because readers have never seen the codenames.
• Write in plain, calm English; the readers are busy, not technical.

Say what to do rather than only what to avoid, and leave out the capital letters. "CRITICAL: you MUST" makes current models rigid and prone to overreacting; a plain sentence with a reason works better.

Escalation: somewhere to go when the input is weak

Models are rewarded for always answering. Real work sometimes needs a question instead, and the Operator is where that permission lives. Be specific about its shape. "Ask if anything is unclear" produces vague requests for more information. This produces something you can route:

If the notes describe two or more significant changes with no indication of priority, return only AMBIGUOUS: which change should lead? followed by the candidates.

A narrow, machine-readable escalation is easier to act on than a paragraph of hedging. Pair it with a general rule for missing information: say what is missing, label any assumption, and do not fill the gap with a guess.

The Playbook: inputs, instruction, output, rubric

Inputs: what may be assumed

Name what arrives and mark what is required. For the announcement:

The rule for absence matters most. Without "do not estimate", a model handed undated notes will usually produce a date, because producing something is the behaviour it was trained towards.

In a reusable prompt each input becomes a variable such as {{release_notes}}, wrapped in its own tag, placed before the instruction that uses it, with the task last. That keeps data apart from instructions and stops a stray line in the notes being read as an order.

Instruction: the outcome and why, not the steps

The old version of this guide asked you to spell out a method: separate shipped from planned work, find the main change, translate terminology, draft, then strip unsupported claims. Current reasoning models from all three providers do that kind of working on their own, and guidance now says to describe the outcome and leave the route to the model unless the order genuinely matters. Prescribed step lists and "think step by step" add tokens and can make answers worse; newer Claude models may decline a request to write their reasoning out.

So the instruction states what good looks like and the constraints that make it hard:

Draft one announcement from the notes. Lead with the most significant shipped change. Translate internal terms into language a customer would use. Every claim must be traceable to the notes.

Each of the old method steps survives as an outcome or a rule. None of them is a step the model is told to perform. If you run a model without built-in reasoning, a single "plan briefly, then answer" line is still worth adding; that is a setting for that model, not part of the job.

Output sections, with a legitimate empty value

If structure matters, fix it before the run rather than repairing it afterwards:

1. Headline, under 70 characters, naming the capability rather than the benefit.
2. Summary, 40 to 60 words.
3. What changed, three to five plain-language bullets.
4. Who this affects, naming plan tiers or user roles.
5. Next step, one concrete action with a link placeholder.
6. Known limitations, or None stated in the source.

That last option matters more than it looks. Give the model a legitimate way to say nothing and it stops inventing content to fill a heading. Concrete numbers beat adjectives everywhere: "40 to 60 words" is followed; "brief" is interpreted.

The rubric is checked after the run

The old version also ended the prompt with a self-check list. On current models that is mostly wasted: reasoning models already review their work as they go, and Anthropic advises removing self-verification instructions on some recent Claude models because they over-check. Keep an in-prompt check only for high-stakes output, and make it one line.

The checks themselves are valuable. They belong in the Playbook's rubric, which you grade the output against once it exists, by eye or with a separate grader:

• every claim traceable to the release notes;
• nothing described as available that the notes call planned;
• headline within 70 characters;
• all six sections present, in order;
• no internal codenames left in the text.

"Be accurate and thoughtful" is not a check. "No internal codenames" is. Each line should be something you could verify yourself in under a minute.

Examples

Examples are the strongest steer you can give a model, and the strongest source of things you did not mean to teach. The model learns everything an example shows, including its length, its quirks and its mistakes.

Start with none. Guidance for reasoning models is to try without examples first. Add one when format or tone is not landing, and stop at the smallest number that fixes it. For our Prompt Builder playbook that ceiling is three.

Make them short and varied. An example should show a pattern, not tell a story. If every example announcement opens with "We're excited", every output will too. Vary the openings, lengths and subjects so the only thing they share is the thing you want copied, and tell the model to vary any sample phrases.

Match the incoming task. A support-reply example will not transfer cleanly to an announcement even if the tone is right. Examples work when the shape of the task stays recognisable.

Agree with the rules. An example that breaks a rule wins over the rule. If an example headline runs to 80 characters, the 70-character limit is gone. Check each example against the output sections and the rubric before you add it.

Keep them apart from the data. Wrap each one in <example> tags so the model can tell an example from the release notes it is meant to work on.

A build checklist

Before putting an Operator and Playbook into repeated use, confirm that:

• the job is recurring; plain asks get a lean prompt instead;
• the role is a job and an audience in a sentence or two;
• standing rules carry their reasons and sit on the Operator;
• required inputs are listed, each with a rule for its absence;
• the instruction states the outcome, with no steps the model would take anyway;
• output sections fix order and length with numbers;
• at least one section has a legitimate empty value;
• there is one narrow, structured way to escalate;
• examples, if any, are few, varied, tagged and consistent with the rules;
• the rubric lists checks you could verify yourself, applied after the run.

From the Library · PlaybookPrompt ImproverScores an existing prompt against a 20-point checklist and returns a revised version with a change log and a test plan.→