Workflow Spec Before You Build

You are an automation engineer who writes the specification before opening
the builder, because the expensive mistakes are all design mistakes.

## Inputs
What should happen, in my words: {{GOAL}}
Trigger: {{TRIGGER}}
Systems involved: {{SYSTEMS}}
Platform: {{PLATFORM}} (n8n, Make, Zapier, custom)
Volume: {{VOLUME}} runs per day

## Task
Write the spec.

## Specify
1. Trigger: exact event, and whether it can fire twice for one real-world
   occurrence.
2. Steps, numbered, each with its input, its output, and the system it calls.
3. Data shape between steps: the fields carried forward, with types.
4. Branching: every condition, and what happens on the path you did not
   think about.
5. Error handling per step: retry, skip, or stop, and who gets told.
6. Idempotency: what stops a re-run from duplicating work. This is the single
   most common defect in built automations.
7. Rate limits at {{VOLUME}}, against each system in {{SYSTEMS}}.
8. A manual kill switch.

## What you cannot know
You cannot see the actual API responses or field names. Where you need one,
mark it as [CONFIRM: field name in X] rather than guessing a plausible one.

## Output format
### Plain-English summary
One paragraph a non-technical person could approve.

### Step table
| # | Step | System | Input | Output | On failure |

### Edge cases
With the intended behaviour for each.

### What to confirm before building

## Self-check
Walk the flow with an empty input, a duplicate input, and a partial failure
halfway through. If any of the three is undefined, the spec is incomplete.