Runbook to Temporal Workflow Conversion Prompt

You are a senior platform engineer who has automated a runbook into a workflow that crashed midway and left the system in an unknown state.

I will provide:
- The runbook's steps, in order, with the manual judgment calls noted
- Which steps are read-only, which mutate state, and which are irreversible
- The systems each step touches and their APIs/timeouts
- Where a human must approve before proceeding

Your job:

1. **Step classification** — separate each runbook step into a deterministic workflow decision vs. a side-effecting **activity**, keeping all I/O in activities so the workflow stays replay-safe for [RUNBOOK].
2. **Activity design** — define each activity's inputs/outputs, timeout, and `retryPolicy`, marking which failures are retryable; ensure each activity is idempotent so a retry is safe.
3. **Human-in-the-loop** — model approval points as workflow **signals** with a timeout that escalates or aborts if no human responds, preserving the original runbook's judgment gates.
4. **Compensation** — for irreversible or partially-applied steps, define compensating activities (saga-style) so a failure after step N can unwind steps 1..N.
5. **Determinism** — flag any non-deterministic code (random, clock, direct I/O in workflow code) that would break replay, and move it into activities.
6. **Observability** — expose workflow queries for current step and surface activity failures, so an operator can see where a stuck run is parked.

Output as: a workflow/activity skeleton, a step-to-activity mapping table, a signal/timeout spec for each approval, and a compensation plan.

Replay-test the workflow against recorded histories and run it end-to-end in staging with deliberate worker restarts before production; the whole point of Temporal is surviving crashes, so prove it resumes correctly rather than assuming it does.

Why this prompt works

Converting a runbook to a Temporal workflow is not transcription — it’s a translation between two execution models. A human running a runbook holds state in their head, notices when a step looks wrong, and improvises a rollback. Temporal holds state durably and replays the workflow on recovery, which only works if the workflow code is deterministic. The prompt’s first and most important demand is the split between workflow decisions and activities: every side effect, every API call, every clock read must live in an activity, because anything non-deterministic in the workflow body breaks replay and can re-execute steps or diverge when a worker restarts. Get this boundary wrong and the durability that justifies adopting Temporal turns into a corruption engine.

The prompt also preserves what the human used to provide: judgment and the instinct to stop. Approval points become signals with explicit timeouts, so the original runbook’s “check with the lead before proceeding” gate survives automation instead of being silently dropped. The timeout matters because a signal with no deadline can park a half-executed runbook forever, holding locks and leaving the system in a partial state. Pairing idempotent activities with bounded retries means a transient failure self-heals while a terminal one surfaces, rather than the loop either giving up too early or hammering a dead dependency.

Compensation is where the prompt encodes the knowledge that automation tends to erase. When a person ran the runbook, they were the safety net who noticed “we can’t undo this one.” A workflow has no such instinct unless you build it in, so the prompt requires saga-style compensating activities for irreversible steps before they’re automated. The model drafts the skeleton and mappings fast, but you verify by replay-testing against recorded histories and restarting workers mid-run in staging — proving the workflow resumes correctly, which is the entire reason to use Temporal in the first place.