Lifecycle Flow Design

Design multi-step lifecycle/nurture email flows — triggers, delays, branches, and messaging — and capture the finished design as a structured spec file ready for build-out.

When to use

• A stakeholder asks for a welcome series, onboarding drip, re-engagement flow, or post-purchase nurture sequence.
• An existing flow needs new steps, retiming, or a new trigger condition added.
• You need to turn a loose set of campaign ideas into a concrete, buildable flow spec.
• A prior flow spec must be revised based on new goals or performance feedback.

Tools

• read-file — load any prior flow spec, brief, or notes to build on instead of starting from scratch.
• write-file — save the finished lifecycle flow spec (triggers, steps, timing, branch logic) to a file.
• complete-task — close out the task with a structured summary once the spec file is written.

Playbook

1. Clarify the flow's goal (activation, retention, win-back, post-purchase, etc.) and the audience segment it targets.
2. If a prior spec, brief, or research doc exists, load it with read-file to reuse existing structure and avoid contradicting past decisions.
3. Define the entry trigger precisely (e.g. "signup completed," "cart abandoned 24h," "no login in 30 days") — a flow must have exactly one clear trigger.
4. Map the sequence of steps in order: for each step, specify the channel (email), the delay/timing since the previous step or trigger, and the message intent (not full copy, just purpose and key point).
5. Add branch logic where relevant (e.g. "if opened previous email, send step 3a; if not, send step 3b") and document exit conditions (unsubscribe, goal completed, max steps reached).
6. Note any suppression rules (e.g. do not enter flow if already in another active flow) and frequency caps.
7. Assemble the full spec — trigger, steps, timing, branches, exits, suppressions — into one structured markdown or JSON document.
8. Save the spec with write-file, using a clear filename that identifies the flow and its audience/purpose.
9. Summarize the flow (trigger, step count, total duration, key branches) and close out with complete-task.

Failure modes

• Vague or missing trigger definition -> do not guess; state the assumption explicitly in the spec and flag it for confirmation rather than inventing behavior.
• Overlapping flows with no suppression rule -> call this out in the spec as a risk and propose a suppression rule rather than silently ignoring it.
• Spec grows too complex to reason about (too many branches) -> simplify to a linear core path plus at most one or two branch points, and note deferred branches separately.
• Prior spec conflicts with new requirements -> flag the conflict in the output rather than silently overwriting the older design's intent.

Done when

• A single spec file exists (via write-file) containing the trigger, ordered steps with timing, branch/exit logic, and suppression rules.
• The spec is internally consistent: every step has a defined delay, every branch has a resolution, and the flow has at least one exit condition.
• complete-task reports the flow name, entry trigger, step count, and total flow duration.