about.epismo.ai/en/docs/concepts/playbooks

The hard part of a first Playbook is not the API — it is knowing what deserves one. Do not ask the user 'what would you like to write?'. Go and find it, then cut to exactly one.

Read what this runtime can already reach, newest first: shell and command history, agent session transcripts, the repo's scripts, runbooks, and CI config, docs directories, issue and PR titles, chat threads, recurring calendar entries, saved memory, and any connected MCP or CLI surface for tickets, CRM, or support. Prefer sources showing what was actually done over sources describing what should be done. The signature of recurring work: the same multi-step sequence appearing three or more times, the same question re-answered for different inputs, work that got handed off and came back wrong, work that stalls when one specific person is away, or a checklist someone keeps rewriting from memory.

Sketch 5-10 candidates with their outcome, frequency, current owner, and what goes wrong when done badly — then apply the single-skill test, which is the discriminator that keeps Epismo from becoming a second skills folder. It belongs in a skill when one agent finishes it in one uninterrupted pass with no human decision, no handoff, and nothing worth reading back later. It belongs in a Playbook when at least two of these hold: it spans more than one tool, surface, or agent; a human makes a judgment call partway through; someone else picks it up or reviews it; the outcome must survive the session; doing it wrong is expensive.

Drop anything that is really documentation, anything stale within a month, and anything whose evidence you could not verify. Rank what survives by frequency times cost-of-getting-it-wrong and take the top one; where two are close, prefer the one whose next genuine instance is already on the calendar. Then state the boundary — what it covers and what it deliberately does not — and search existing Playbooks for that outcome, improving a fitting one rather than creating a near-duplicate.

Ask the user only what the environment cannot show: which of these still matter, and which are already dead.

Gate: exactly one candidate, backed by evidence you actually read — a path, a command, a thread, a ticket — passing the single-skill test on stated grounds, with no existing Playbook already owning that outcome.