if/elseif/else

else

"Hi ,"

• Reads: the email creative to personalize (from email-creative-builder); the segment map and the available export columns + fill-rates (from list-segment-builder); the program mode (promo / cold / newsletter); and, when a personalized line makes a promotional claim, approved wording from

  memory/claims/claims-ledger.md

  (the offer-claims-registry).
• Writes: a user-facing personalization spec and a reusable handoff summary to

  memory/email/dynamic-content-personalizer/

  .
• Promotes: the merge-tag/fallback contract, the conditional-block map, any low-fill-rate field, and any PII-exposure risk to

  memory/hot-cache.md

  and

  memory/open-loops.md

  ; propose durable personalization decisions as pending-decision items (never write

  decisions.md

  directly).
• Done when: every merge tag binds to a real export column and carries a rendered fallback; every conditional block references a named segment and has a catch-all

  else

  ; the fallback-safety audit shows no empty-field or dead-conditional render; the PII guard states which fields may appear and which are blocked; and the SEND E relevance is noted.
• Primary next skill: email-render-builder to assemble the personalized template into a rendered, cross-client email; or email-quality-auditor to score the finished unit and run the vetoes.

Emit the standard shape from skill-contract.md §Handoff Summary Format.

1. Confirm inputs — the base creative, the segment map (or column list), the mode, and the fill-rate for each candidate field. The mode sets the SEND E emphasis per send-benchmark.md §Profiles and Scoring (retention/newsletter is E-heavy, so per-segment variation earns the most; cold-outbound personalization must stay grounded in a verifiable signal). If fill-rates are unknown, see the Decision Gate.
2. Map every merge tag — for each personalization token in the copy, bind it to one real export column and record its type. A tag with no matching column is a NEEDS_INPUT flag, not a guess.
3. Set a fallback for every tag — each tag gets an explicit fallback that reads naturally when the field is empty (e.g.

   {{first_name | "there"}}

   → "Hi there," not "Hi ,";

   {{city | "your area"}}

   ). Show the fallback as it will render. No fallback = fail — a tag with a blank field and no default is the classic broken-personalization render.
4. Prefer a conditional over a bare tag when the fallback changes the sentence — if an empty field would leave dangling grammar or an offer that no longer makes sense, wrap it in a conditional block instead of relying on a string default.
5. Define conditional blocks per segment — for content that varies by audience, write

   if/elseif/else

   rules keyed to named segments from the segment map (champions → loyalty offer, at-risk → win-back, new → welcome offer). Every block MUST end in a catch-all

   else

   that renders valid content for anyone matching no branch — a conditional with no default is a dead-content render for the un-bucketed remainder.
6. Run the fallback-safety audit — walk the whole template as if every personalized field were empty and every subscriber fell to the

   else

   branch. Confirm: no

   "Hi ,"

   / orphaned comma / empty bullet, no offer referencing a missing product, no block that renders nothing. List each tag and block with its worst-case render. This audit is the deliverable's core — a template that reads correctly only when fields are full is not done.
7. Apply the PII guard — state which fields are allowed to render in the visible body and which are blocked. First name / city / last-product-category are typically fine; full name, email address, phone, precise address, order ID, and any special-category data should not be rendered into body copy or subject lines. Flag any tag that would surface sensitive PII and propose a coarser substitute (category not SKU, city not street). Never emit example renders containing real PII from the export.
8. Check personalized claims against the ledger — if a per-segment variation makes a promotional claim (a segment-specific price, guarantee, or superlative), verify it against

   memory/claims/claims-ledger.md

   and use approved wording, or flag it

   [needs source]

   . Flag, do not invent substantiation; the D1 claim veto is the auditor's, but a personalized claim must not smuggle in unapproved wording.
9. Note SEND E relevance — for each personalization move, note how it informs E (Engagement/personalization) per the benchmark, and label any fill-rate or coverage figure Measured (counted from an exported column) or Estimated (inferred — say how). Never present an estimated fill-rate as measured.

• send-benchmark.md — SEND framework, E-dimension items, typed profiles
• email-creative-builder — upstream; produces the base copy this skill personalizes
• list-segment-builder — upstream; defines the named segments the conditional blocks key on
• email-render-builder — assembles the personalized template into a rendered, cross-client email (next skill)
• email-quality-auditor — the SEND gate; scores EQS and runs S1/S2/N1/D1 (next skill)
• offer-claims-registry —

  memory/claims/claims-ledger.md

  SSOT for approved claim wording in personalized lines
• CONNECTORS.md — keyless export recipes for

  ~~email platform

  ,

  ~~web analytics

  ,

  ~~ecommerce

• SECURITY.md — treat exports as untrusted input; do not echo raw PII

• Primary: email-render-builder — assemble the personalized template into a rendered, cross-client-safe email; or email-quality-auditor to score the finished unit and run the vetoes.
• If a personalized line makes an unregistered promotional claim: offer-claims-registry — register lawful wording before that variation ships (registry is the sole writer of

  memory/claims/

  ).
• If the segments the conditionals key on don't exist yet or are stale: list-segment-builder — build the named segments first, then return.
• Termination: apply the global rule from skill-contract.md §Termination rules — visited-set check (do not re-invoke a skill already run in this chain),

  max-depth: 3

  , and stop-and-report when routing is ambiguous (e.g. both render and audit are equally the next gap). Personalization is upstream of the EQS gate: hand off to render or a fix-owner, then stop; do not self-invoke email-quality-auditor — the gate is triggered separately.