email-lifecycle-flow-writer

• SKILL.mdcore · 4,236 bytes
• skill.meta.jsonasset · 242 bytes

# flow-writer

**Reads:** the flow's entry in `../email-lifecycle/references/flow-library.md`; `../email-lifecycle/references/loadable-flow-format.md`; `../email-lifecycle/references/copy-craft.md`; `../email-lifecycle/references/worked-flows.md` (quality bar); `../email-lifecycle/references/sms-push-whatsapp.md` when the flow has those legs. From the brain: voice, banned words, signed-off claims, product records (price, offers, notes), learnings. From the program sheet: tool and plan, segments, priority map, cap, consent per channel. The standing offer from the shared `Standing offer:` fact. From the audit: the live flow this replaces, if any.

**Does:**
1. **Wire it first, in the tool's real syntax** (`loadable-flow-format.md`; when unsure of a tag, name the editor action instead of guessing). Check plan reality: no workflows → a fixed-date sequence becomes scheduled broadcasts with an exclusion list and the sign-up welcome becomes the form's autoresponder, written in the tool's terms (not tool-neutral); only a flow the plan cannot run even that way is said and written tool-neutral. Fill the flow header completely in the tool's own vocabulary: exact trigger name, trigger and flow filters, exit, re-entry, consent, smart sending, quiet hours, priority and suppressions, cap, UTM template, discount object (from offer-math), holdout, A/B test (winner on clicks or orders), build notes. A feature the plan lacks gets its workaround.
2. **Plan the messages.** Count and delays from the library, adjusted to this brand's price and cycle (say why if moved). Write one job per message before any copy. Check the sequence reads as a story, not five versions of the same email.
3. **Write each message finished.** Subject + 2 alternates, preview, from and reply-to, body blocks, one CTA with full URL, merge tags with fallbacks, dynamic blocks with out-of-stock behaviour, splits with a default branch, image needs with alt text (optional art requests as a line: `Graphic needed: for make-static-ads · header art: <flow, message, size, what it shows, alt text> · return to: lifecycle/flows/<flow-slug>.md`), a full plain-text version, footer, and the claim id or record behind each factual sentence. Vary length and shape across the flow. For B2B and services default to plain text from a named person.
4. **Self-check against `copy-craft.md` failure list.** Rewrite any hit.
5. **Leave honest gaps.** Anything the brain and the marketer have not settled stays a visible [placeholder] with its question at the top of the flow file, and the flow's status line reads `not ready: answer Q3, Q5`. A flow written against tracking-plan events reads `not ready: needs events E1–E3 live`; one the plan can't run even with that workaround reads `not ready: needs tool decision T1`. Only a flow with no open blocker is `ready to load` (with `· switch on after fix #N` while authentication is red or unknown); a header-art request never blocks it. Never invent a fact, an offer, a review, a count or an existing event name; events that do not exist yet go into the tracking plan (event, properties, when it fires, which flow) labelled "proposed — confirm with engineering", and the flow is written against those names.

6. **Hypothesis for this cycle.** One line per flow: what it should do and against which number (e.g. "abandoned checkout: ≥ 4% of recipients order within 7 days; baseline unknown"), the goal metric and when it will be read. Saved into `lifecycle/program.md` for the next run's read-back.
7. **Art answers.** On a re-run, read any `Graphic ready:` line under this flow's header-art `Graphic needed:` request and place the image.