pipeline-replaylisted

# Pipeline Replay The two worst sentences in automation: "it ran twice" and "it died on step four, how do I restart it." Both have the same root cause. Nobody decided, per step, what is safe to repeat and what is not. So the retry sends the email again, or you can't resume without redoing the charge. This skill makes that decision explicit, step by step, before it bites. The pattern it builds is the one I run in production: a persisted state file is the source of truth, every step saves to it, and a re-run skips finished work by looking at the data, not a flag. You describe the pipeline, it produces a replay plan. Work through every step. Build the plan, then stop. ## Inputs (ask for whatever is missing) - **The pipeline** (required): the steps in order, what each one does. If a `build-spec` exists, take the happy path and the state notes from it. - **What each step touches**: which steps call an external system (send, charge, post, write to someone else's database) vs only read or write your own state. - *Optional:* where state lives (a JSON file, a DB row, a queue), and the real incident if this is a post-mortem ("it sent two emails"). ## The method 1. **List the steps in order.** One row per step. If a step does two things to the outside world, split it — a row should have one external effect at most. 2. **Classify each step's side effect.** The core of the whole skill: - **read** — pure lookup. Always safe to repeat. - **internal-write** — writes only your o