Build is how a Playbook comes to exist in your account. There are two doors, and they lead to the same place.

From a template

The template gallery is the fast path: pick a template, see its real example output, and copy it into your account as an editable draft. Templates are a working starting point you make yours. The Getting started page walks the whole flow.

From scratch

Open Services, choose Create new Service, then Create from scratch. Describe the operation first: your description seeds the new Draft Service's name and goal, so it opens already titled rather than as "New Playbook". On a desktop the builder opens on its Steps, which start empty; on a phone it opens on the Service overview with Steps as its first row. You can write the steps directly or ask YAMO in the build chat to shape the stages, inputs and references with you.

The playbook.md document

A Playbook is a document, not a diagram. Its home file, playbook.md, is readable top to bottom, and the builder renders it as the Details tab: edit a section in place, or ask YAMO in the chat; both edit the same document. What you see is what runs.

The parts, in plain language:

Goal: what the Playbook delivers, stated as an outcome. From the Brief to Report template: "Turn a written brief into a finished report."
Persona: who the Playbook works as. The URL SEO Audit template's persona is "a pragmatic SEO consultant". That framing carries into every stage of every run.
Rules: your absolutes. Rules bind every Play at runtime. The Sales Email Drafter template rules include "Prices exactly as offer.md states them": one line in the document, enforced on every stage.
Inputs: the Playbook's form: what it asks for each run (run inputs) and what you set once as the owner (config inputs). Each input has a type, such as text, URL, file, choice or date, and its value lands in the Plays where the document references it.
Outputs: what a run delivers. Most Playbooks produce one primary document. A Playbook can declare named outputs: the Content Engine template delivers a content pack plus the article and social posts as separate artifacts.
References: the files the Playbook works from (your voice, your offer, your watchlist). See Reference files.
Connectors: the tools it calls. See Connectors.

Plays

Below the document's front matter sit the Plays, the ordered stages that do the work. The builder calls them Steps and shows them on the tab it opens on, because the steps are the work; Play remains the name of the unit inside the definition. Each Play is its own small document: instructions, the inputs it consumes, what it hands to the next stage, and what it needs — the tools it calls and the reference files it draws on, shown on every step whether or not it declares any. A Play can declare a human gate, which pauses the run for your approval before it proceeds. See Skills & Plays.

Knowing when it's ready

YAMO's setup checklist in the build chat audits the draft against its own contract: references still on placeholders, Connectors not connected, config inputs unset. The Resources tab shows the same state at a glance. When the checklist is clear, the Playbook is ready to run. The hard items are the same checks that gate a run: Connectors, missing references, unset config inputs. So there are no surprises at run time; placeholder content is guidance, not a gate. A run with placeholders in place is allowed, it just works from the example knowledge.