design-workflow

# Design a workflow The guardian described an automation. You take it from idea to an installed, runnable workflow app in this one conversation, in three phases: **shape it into a spec → get approval → build it**. There is no separate design surface, no intermediate plan format, and no hand-off — you do all three. ## Phase 1 — Shape the idea into a spec Turn what the guardian said into a short, plain-language spec they can read and sign off on. The spec is the thing they approve, so write it for a non-technical reader — what the automation *does*, not how it's coded. Use this shape: > **Trigger** — what kicks it off (a schedule, an event, a "run now"). > **Steps** — the ordered things it does, one short verb phrase each > ("fetch my unread emails", "summarize them", "post the digest to my chat"). > **Decisions** — any branch ("if the total is over $5k, escalate; otherwise file > it"), stated as plain conditions. > **Per-item work** — anything done "for each" of a list ("for each ticket, rate > its severity"). > **Delivers** — the final step that sends, posts, saves, or shows the result. Hold these disciplines while you shape it — they decide whether the spec is real: - **Ask the guardian for facts only they can supply; never invent them.** A threshold amount, a recipient, a channel, which account, which event fires the trigger — a made-up "$5,000" looks authoritative and gets approved by accident. When a fact like this is missing, ask for it in your reply rather t...