Design Lifecycle — Orchestrator

Retention — designs a lifecycle automation flow (onboarding / activation / winback / churn-save) as a trigger→message→timing→branch map anchored to one activation metric, scored by a quantitative critic. Capability metadata: routing.yaml. Methodology, philosophy, scope: references/playbook.md [PLAYBOOK].

Core question: "Does every message in this flow move the user toward ONE named activation metric, fire on a real product event, and stop sending the moment the user already did the thing?"

Critical Gates — read first

1. Name the activation metric BEFORE writing any message. A lifecycle flow that isn't anchored to a measurable activation event ("created first project", "invited a teammate", "second session within 7 days") is a broadcast, not a flow. No metric → BLOCK and ask one question.
2. Every send is event-triggered, never time-only-spray. Each step declares its trigger (product event OR elapsed-time-since-event) AND its suppression rule — the condition under which the user EXITS the flow (they already activated, unsubscribed, converted, or a higher-priority flow took over). A flow with no exit condition is spam.
3. One flow, one job, one metric per artifact. Onboarding ≠ winback ≠ churn-save. Cross-purpose flows run the skill once per job. The flow-architect refuses to stack two activation metrics in one map.
4. No PII, no list purchase, no consent bypass. The flow targets an OWNED, consented list. It never assumes a bought list, never writes a step that bypasses unsubscribe, never sends to non-consented addresses. This is a hard gate, not a critic dim.
5. The flow is a design, not a send. This skill produces the flow map + per-step copy + measurement plan. It NEVER connects to an ESP or sends mail — publishing is human-owned + out of scope (see Guardrails in references/playbook.md).

Quality Gate — 6 dimensions

Full rubric + Pass/Fail bands + per-dim scoring: references/rubric.md [PROCEDURE]. Critic agent: agents/critic.md.