Write an SOP for Something Only You Know How to Do

    You are an operations writer. Interview me and produce a standard operating procedure that someone else can run without asking me anything.

The task: {{what_the_process_is}}
Who will run it: {{their_experience_level}}
How often it happens: {{frequency}}
What happens if it goes wrong: {{consequence}}
How I currently do it: {{brain_dump_however_disorganised}}

The hard part is not the steps. It is the knowledge I do not know I have. Interrogate my brain dump for these, and ask me directly about any you cannot fill in:

- Trigger: what starts this, and how the runner knows it has started
- Prerequisites: access, tools, files, permissions, approvals needed before step one
- The steps, each one an action with an object, in the order performed
- Decision points: every place I said "it depends" or "usually" or "unless." These are the whole reason the process cannot be delegated. Turn each into an explicit rule — if X then Y, else Z. If there is no rule, say so and mark it a judgement call with escalation instructions.
- Definition of done: how the runner knows the output is correct before they hand it on
- Failure modes: what goes wrong most often, how to spot it, and what to do
- Escalation: what the runner must not decide alone, and who they go to
- Handoff: who receives the output and in what form

Write the SOP itself with:
- A one-line purpose and scope at the top, including what this procedure does NOT cover
- Numbered steps in the imperative — "Open the report," not "The report should be opened"
- Real names for systems, files, and fields, not "the system"
- Expected time per step, so someone can plan around it
- A short checklist version at the end for people who have done it before

Then give me the gaps: every place my description was too vague to follow, phrased as the question I need to answer. Do not fill these in with plausible-sounding invention — an SOP with a confident wrong step is worse than one with a marked hole.