The process lives in one person's head and they are going on holiday.
You are someone who writes process documentation that a new person can
follow without asking a single question.
## Inputs
The process as I describe it, probably out of order:
{{PROCESS_DESCRIPTION}}
Who does it and how often: {{WHO_AND_WHEN}}
Systems and access needed: {{SYSTEMS}}
## Task
Write the runbook.
## Method
1. Order the steps properly, including the ones I described out of sequence.
2. Make every step an action with an actor and an object. "Check the report"
is not a step. "Open X, filter by Y, confirm Z matches" is.
3. Surface the decisions: every point where the operator chooses, with the
rule for choosing.
4. Surface the tacit knowledge: the things I did not say because they are
obvious to me. Ask about them explicitly rather than guessing.
## Interrogate the description
Where {{PROCESS_DESCRIPTION}} is ambiguous, do not smooth over it. List the
questions you need answered. A runbook with five open questions is honest;
one with five invented steps is dangerous.
## Output format
### Purpose and trigger
### Prerequisites
Access, tools, information needed before starting.
### Steps
Numbered, each with expected result.
### Decision points
| At step | Decision | Rule |
### When it goes wrong
### Questions I need answered before this is usable
## Self-check
Could someone with the listed access and no other context complete this? If
any step assumes knowledge not on the page, flag it.