← Back to insights

Why your prompt library does not survive a second team

You spent a quarter building your team’s prompt library. It works for you. You hand it to a sister team and within a fortnight half the prompts are not running for them, the rest are giving different output, and the library has quietly become a wiki page nobody opens.

The failure is structural, not effortful. Most internal prompt libraries are pseudocode — readable, gestural, missing the things that make a template runnable in someone else’s hands. The Playbook’s prompt template schema names the missing pieces; this post is the short version.

What a runnable template carries

A template that survives a second team has six things on the page:

  1. A title and a one-line job-to-be-done. Not “blog brief generator” — “turns a topic + target keyword into a structured 1,200-word brief with H2s and a stated angle.”
  2. Declared variables, in {snake_case}. Every input the prompt expects, named, typed. Not “your topic here” inline; {topic} and {target_keyword} and {audience} declared at the top.
  3. The prompt body itself, copy-pasteable. Indented inside a code block or a fenced YAML field. No prose around it that the reader has to mentally strip.
  4. A worked example with concrete inputs. Real values for every variable, not “for example, you might use…”. The example is the runnable test.
  5. The expected output, described. Not “the output will be a brief” — “a 600–800 word brief in this structure: introduction (2 paragraphs), three H2 sections each 150–200 words, one CTA paragraph.” The reader has a pass/fail criterion.
  6. Stated failure modes. What the template gets wrong when used outside its sweet spot — wrong content type, missing variable, ambiguous topic. Naming the failure modes is what stops the second team from misusing the template.

If any of those six is missing, the template will not survive a hand-off. The Playbook’s prompt schema formalises the structure as a YAML file; you can adopt the schema in your team without buying anything.

Why the worked example matters most

If you do nothing else, ship the worked example. The single biggest difference between a template that runs and a template that does not is whether the next reader can substitute their inputs and see what shape of output to expect. Without the worked example, the reader runs the template, sees output that looks plausible, and has no way to know whether it is the output the template was designed to produce.

The corollary: a template you cannot write a worked example for is a template you have not nailed yet. Write the example; the act of writing it surfaces the missing variables.

What you walk away with

A library where every template is stand-alone — a new team-mate, a sister team, a contractor on a one-week engagement can pick up a single file and run it. Your prompt library stops being tribal knowledge and starts being a shared artefact.

The full prompt template schema is on the standards page. The Playbook ships sixty-plus runnable YAML templates following the schema; the prose that frames them lives alongside each template.


Liked this? Most of the work it draws on lives in the Playbook. See what's on offer or read two sample chapters.