A prompt playbook is what stops output quality depending on who happens to be prompting. It is a short, structured library of the prompts a team uses for its recurring tasks, with the reason each one is built the way it is. Without one, quality varies with the individual, training has nothing specific to teach, and every staff change resets the standard.

This guide covers what belongs in a playbook entry, how to design one that people actually use, how to version and maintain it, and why it matters more than individual prompt skill. It is part of the Skills, Change & Measurement pillar.

The playbook is the institutional memory of the workflow. Prompts in people’s heads leave with the people.

What a playbook entry contains

Five parts, and each has a purpose.

  • Task. What the prompt is for, in one line — “draft the variance commentary for the monthly pack”.
  • Prompt. The text, with placeholders for the variables: period, figures, prior period, audience.
  • Inputs. What must be supplied, and from where. This is where the workflow’s source discipline is recorded.
  • Output format. The structure expected — headings, length, tone, what must not appear.
  • Checks. What the human must verify before the output is used.

The fifth part is what distinguishes a playbook from a prompt list. A prompt library teaches people what to paste; a playbook teaches them what to trust.

Why a playbook beats prompt skill

Three reasons, and they are practical rather than theoretical.

  • Consistency. Two people running the same playbook produce comparable output; two people writing their own prompts do not.
  • Training. A playbook gives training something specific to teach and assess, rather than a general session on how to write prompts.
  • Continuity. When someone leaves, the workflow remains. Prompts stored in individual accounts leave with the individual.

A useful test for any team: if the person who currently does this task left tomorrow, could a colleague produce the same output? Where the answer depends on that person’s prompt-writing, there is no playbook.

Designing entries that work

Four design principles.

  • Write for the task, not the tool. The prompt should describe the work; tool-specific syntax belongs in a note, not the entry. That is what lets the playbook survive a tool change.
  • Make the inputs explicit. Where the figures come from, where the template lives, what must accompany the prompt.
  • Constrain the output. Length, structure, tone and prohibited content — constraints produce consistency and reduce checking time.
  • Write the checks in. The verification step belongs in the entry, not in a separate policy document.

The most common design mistake is a prompt so general it produces different output every time. Structure is what makes output comparable between cycles and people.

A worked entry

  • Task: Draft the variance commentary for the monthly management pack.
  • Inputs: Frozen figures for the period and the prior period, from the finance system extract; the standard variance threshold; the prior month’s commentary.
  • Prompt: “You are drafting the variance commentary for a monthly management pack. Using only the figures supplied, identify variances above [threshold], and for each write two sentences: what moved, and by how much. Do not explain why the variance occurred. Do not introduce any figure not supplied. Audience: the executive team. Tone: plain.”
  • Output format: One paragraph per material variance, in descending order of size, headed by the line item.
  • Checks: Every figure against the finance extract; no figure present that was not supplied; the explanation of the cause added by the finance lead; the whole section reconciled to the report.

The prompt deliberately prevents the model from stating causes, because the cause is the judgement the finance lead owns. That constraint is the design.

Versioning and maintenance

A playbook that is not maintained decays into a source of inconsistent output.

  • Version each entry, with a date and a note of what changed.
  • Record why a change was made — usually a correction that revealed a missing constraint.
  • Review twice a year, and after any tool change, because prompts tuned to one assistant may need adjusting for another.
  • Retire entries that no longer fit, rather than leaving them to be used by mistake.

The change log is more valuable than it looks: it is the record of what the team learned about its own work.

Where the playbook lives

A playbook only works if people can find it, which is a distribution problem rather than a drafting one.

  • Put it where the work happens — the shared drive the team uses, or the workflow tool itself. A playbook in a folder nobody opens is a document, not a control.
  • Link it from the report or document template, so it appears at the moment of use.
  • Name an owner who maintains it and answers questions about it.
  • Keep it short. A five-entry playbook that is read beats a fifty-entry library that is not.

The test is whether a new joiner, given a task, finds the playbook without being told where it is. Where they ask a colleague first, the playbook is in the wrong place.

A second worked entry

  • Task: Summarize a long inbound email thread into a structured handover note.
  • Inputs: The full thread, exported from the mailbox; the standard handover structure; the client name and contract reference.
  • Prompt: “Summarize this thread into a handover note with four sections: the issue, what has happened so far, the current state, and the next step with an owner. Use only information present in the thread. Do not infer a cause or a resolution. Note any date or figure exactly as written.”
  • Output format: Four headed sections, under 300 words, with the most recent state described first in each section.
  • Checks: The next step and its owner confirmed against the most recent message; every date and figure matched to the thread; any inference removed.

The entry works because it constrains what the model may do. It summarises, and it does not interpret — which is exactly the boundary that makes the output usable by a colleague in a hurry.

Common mistakes

  • A prompt list without checks. The playbook teaches what to paste and not what to trust.
  • Prompts that are too general. Output varies, and the playbook provides no consistency.
  • Tool-specific syntax in the entry. The playbook has to be rewritten at the next tool change.
  • No inputs recorded. People supply the wrong source, and the output is wrong for a reason the prompt cannot fix.
  • No versioning. Nobody knows which prompt is current.
  • Never reviewed. Entries drift and are used well past their accuracy, producing output that looks correct and no longer is.

Frequently asked questions

What is a prompt playbook?

A structured library of the prompts a team uses for recurring tasks, each with the task, the prompt, the inputs, the expected output format and the checks the human must run.

Why do we need a playbook rather than good prompts?

Because consistency, training and continuity all depend on the workflow being recorded rather than held by individuals. A playbook makes output comparable between people and cycles.

What should each playbook entry include?

Task, prompt, inputs, output format and checks — five parts, with the checks section being what distinguishes a playbook from a prompt list.

How often should a playbook be updated?

Twice a year, after any tool change, and after any correction that revealed a missing constraint.

Should we include prompts for tasks we no longer use?

No. Retire them, with a note. An out-of-date entry used by mistake produces output that has quietly become wrong.

Can we buy a prompt library instead?

General prompt libraries are useful for ideas and rarely sufficient for a workflow. The valuable part of a playbook is the inputs, the output format and the checks, which are specific to your work.

How many entries should we start with?

Five, covering the most frequent tasks. Adding entries is easy; maintaining a large library is not, and an unmaintained entry is worse than a missing one.

What if two people run the same task differently?

That is the signal a playbook is needed. Capture the better approach as the entry, version it, and let both people use it, rather than allowing two standards to coexist.

Who owns the playbook?

The use-case owner, with the practitioners supplying the entries. Where nobody owns it, the entries drift and are used past their accuracy, which is worse than having no playbook at all.

Next step

Build five entries — the summary, the narrative section, the variance commentary, the client update and the proposal section — and version them. Download the Prompt Playbook, see Training Your Team to Use AI Well, or book a team training session and we will build the playbook with your team.

Sources

  • Playbook structure reflects standard operational-procedure practice applied to AI prompting: task, inputs, output definition, checks and version control.

No statistic in this article is invented; where figures appear in the linked guides, they are cited there with their source and date.