Prompt, Playbook, Operator, Knowledge: what goes where

Anyone who uses AI for real work ends up with the same pile: a setup paragraph pasted at the start of chats, a few prompts reused with the names changed, and a folder of reference documents. The pile works until you need to change a rule and cannot remember where it lives.

MyPromptVerse sorts that pile into four objects. The names are ours, but the split follows lines that Claude, ChatGPT and the SKILL.md format already draw, so it holds whichever tool you use.

Operator: standing rules and fallbacks

An Operator is the briefing you would give a new colleague once and expect to hold for every piece of work. It has a one or two sentence role, the audience, a mission, and a short list of behaviours that apply no matter which job it is doing.

Those behaviours are mostly about what to do when things are missing or unclear, because that is where a model improvises worst. Our Prompt Engineer operator carries this rule:

Ask for success criteria, audience, and the ambiguity policy when the brief leaves them out, and list the assumption made instead of guessing silently.

That rule is true whether the operator is writing a new prompt or reviewing an old one, so it sits on the Operator and every Playbook it runs inherits it. The same goes for "write in British English" or "never quote a price that is not in the policy".

Keep the role short. Anthropic, OpenAI and Google all recommend a brief role in the system prompt, and Anthropic warns that overly specific personas can limit the answer. A sentence naming the job and the audience does more than a paragraph about being world-class.

When you export an Operator from the app you get a plain system prompt, which you can paste into a Claude Project's instructions or a custom GPT's instructions as written.

From the Library · OperatorPrompt EngineerWrites new prompts from a brief and repairs failing ones, following current Anthropic, OpenAI and Google guidance.→

Playbook: the method and the shape of done

A Playbook describes one recurring job. It has four parts:

• Inputs, with the required ones marked, so the model knows what it will be given and what it must not invent.
• An instruction: what to produce, for whom, and the rules specific to this job.
• Required output sections, in order.
• A rubric: the checks you grade a finished output against.

The Prompt Builder playbook is a real one from the app. Its inputs are Goal (required), Audience, Context, Output format, Constraints, Examples, Target model and Reuse. Its required sections are Prompt, Variables, How to use, Design notes and Test inputs. Its rubric includes "Exact output format and length target" and "Reasoning guidance fits the target model".

Look at what the Prompt Builder leaves out. It says nothing about how cautious to be in general or who the person using it is. Those sit on the Operator. The Playbook says how this job goes; the Operator says how this worker behaves. If you notice the same fallback rule written into three Playbooks, move it to the Operator they share.

A Playbook exports as a SKILL.md-style file, with front matter saying when to use it, so the same method can travel to tools that read that format.

Prompt and Snippet: the ask itself

A Prompt is the task message. When you reuse one, the parts that change become variables, such as {{meeting_notes}} and {{audience}}, and the fixed instruction stays the same between runs. A Snippet is a smaller piece you add to a prompt to change its tone or structure, like a house voice.

A Prompt needs nothing else to be useful. Plenty of good work is one clear message with the right material attached. Operators and Playbooks earn their keep only once a job repeats, and attaching them to a plain question makes the answer worse, which we found out the hard way (the story is in Anatomy of an Operator and a Playbook).

Knowledge: facts, not instructions

Knowledge is grounding material: a support policy, a product glossary, a style guide. Its job is to say what is true. Keep behaviour out of it. If a refunds policy sets a threshold above which cases go to a person, the threshold lives in the Knowledge document and the instruction to follow the policy lives on the Operator or Playbook. Mixing the two means a policy update can quietly change how the model behaves.

In the app today, Knowledge you select for a run is placed into the prompt in full, up to a budget of roughly 30,000 tokens. There is no retrieval yet, so pick the documents a job needs rather than attaching the whole library.

Where "agent" fits

You do not create an agent. An agent is what happens at run time: an Operator working a Playbook on a Prompt, with Knowledge in view. Treating "agent" as a thing you build sends people towards orchestration when what they need is a better role and a clearer method.

In MyPromptVerse a run is currently one model call with one Operator and one Playbook. Team runs with several agents, scheduled automations and knowledge retrieval are not built yet. For most recurring knowledge work that is enough.

When a prompt becomes a Playbook

If you keep pasting the same setup block before different tasks, it is a behaviour layer asking to be packaged. Other signs: you change only the nouns between uses, you check every output for the same missing section, or a colleague asks for "that prompt you use".

Packaging it takes four passes over the prompt you already have.

Sort every sentence

Go through it line by line and give each sentence a home. Using a support-reply prompt as the example:

• "You are a support lead for a B2B software company" goes on the Operator.
• "If the customer's plan is unclear, ask before quoting anything" goes on the Operator if it holds for all support work, or on the Playbook if it only applies to this reply type.
• "Return a summary, a category, a draft reply and whether to escalate" becomes the Playbook's required sections.
• The pasted ticket becomes a Playbook input.
• The pasted refund policy becomes Knowledge.

Drop this week's specifics

A prompt that worked once usually mixes reusable behaviour with details from the day you wrote it. Keep the behaviour and turn the details into inputs. If an input has no sensible default, mark it required, so a missing one is caught before the run rather than invented during it.

Write the rubric from your corrections

Look at the last few outputs you fixed by hand. Each fix is a rubric line: "every claim traceable to the ticket", "reply under 150 words", "no promise of a refund the policy does not allow". These are what you check after a run, which is far more reliable than hoping the model checks itself.

Keep it to one job

One Playbook per recurring job. A "marketing playbook" that covers strategy, copy, SEO and reporting cannot be tested, because there is no single output to judge it by. Two narrow Playbooks sharing one Operator are easier to fix.

A one-question sort

For any line you are unsure about, ask whether it would still be true on a different job. If yes, it belongs on the Operator. If it is true every time you do this job, it belongs on the Playbook. If it is true only today, it belongs in the Prompt. If it is a fact rather than an instruction, it is Knowledge.