---
name: curcuma-email-design
route: "Write a NEW email from a brief or description"
router-terms: write, create, draft, design, build, make, generate, new email, welcome email, newsletter, cart abandonment, product launch, win-back, transactional, promotional, black friday, holiday, sale
description: |
  Write a production-quality HTML email grounded in real references. Searches
  for 3-5 relevant emails, studies the best one via get_email_summary, validates
  structural patterns via get_pattern, then writes the email. Use when the user
  wants a NEW email — they describe what they want, you ground it in evidence,
  and deliver production HTML.
  Trigger on: "write me a", "create a", "design a", "draft a", "build an",
  "I need a [type] email", "make a welcome email", "new newsletter".
---

# Curcuma Email Design

Write a production-quality HTML email grounded in evidence from 19,795 real
emails. Don't invent markup from scratch — find what works, understand why,
then write.

**Read `skills/GROUNDING.md` first.** Violations that recurred in the wild
(and are banned): inventing demos instead of corpus HTML, dashed image
placeholders as “done,” therapy-speak copy, generic indigo SaaS templates,
missing slug citations.

## When to Use This

- User wants a NEW email (welcome, cart abandonment, newsletter, launch, etc.)
- User describes an email type or goal ("write a win-back for lapsed subscribers")
- User provides a brief or content for a new email

## When NOT to Use

- User has existing HTML to fix → `curcuma-email-improve`
- User wants research/analysis, not a finished email → `curcuma-email-research`

## CRITICAL: Output Behavior

**This skill produces a finished HTML email file, not a plan.**

1. Save the email as `email-output/{type}-{date}.html`
2. Output the full HTML inline so the user can copy it
3. Report which references informed the design and what patterns were applied
4. Mention which real emails it's grounded in

---

## Workflow

### Step 1: Understand the brief

Before searching, extract:
- Email type (welcome, cart abandonment, newsletter, transactional, etc.)
- Brand context (company name, industry, tone)
- Key content (headline, CTA, any copy provided)
- Design constraints (colors, fonts, width — usually 600px)

If the brief is vague, ask 1-2 targeted questions. Don't guess.

### Step 2: Search for references

Run at least one real search for the user's email type:

```
search_emails(query="welcome", limit=10, max_per_company=1)
```

Search discipline:
- Use 2-3 word natural phrases: "abandoned cart", "black friday", "welcome"
- `max_per_company=1` for brand diversity
- Read `coverage` — if `weak` or `none`, simplify the query
- If no results, try `list_categories` to find the right category, then
  search within it
- For specific techniques, also search "bulletproof button", "preheader",
  "dark mode" — these surface emails demonstrating that technique

### Step 3: Study the best references

Pick 2-3 results whose layout and style match the brief. For each:

```
get_email_summary(slug="welcome-to-rare-beauty-by-selena-gomez")
```

This returns ~3KB of design intelligence:
- `structure.layout_type` — single-column or multi-column
- `color_palette` — top colors used (**use these**, not generic purple)
- `cta_type` — button, image-link, text-link
- `cta_buttons` — actual CTA text from real emails (**reuse wording patterns**)
- `preheader` — hidden preview text patterns
- `visible_text` — the copy structure (headline → body → CTA → footer)
- `link_labels` — what links real emails include

**Read the summary carefully.** This is your design brief from reality.

**Copy discipline from summaries:**
- Steal *structure* (cart card → price → FINISH CHECKOUT; logo → hero → CTA)
- Steal *labels* (“In your cart”, “Did you forget something?”, short holds)
- Do **not** invent guilt-therapy voice. Match the directness of `visible_text`
- Keep body short when real cart emails are short

### Step 4: Validate structural patterns

Before writing, check what the industry actually ships:

```
get_pattern(name="bulletproof button")
get_pattern(name="dark mode")
get_pattern(name="responsive")
```

These return **live** prevalence strings plus production code examples.
Use the snippets and prevalence **exactly as returned** — do not paste
numbers from memory or from this skill file.

Key patterns to check (names only — stats come from the tool):
- `bulletproof-button` — VML / padded-td fallback for Outlook
- `mso-conditional` — Outlook-specific fixes
- `responsive` — mobile media queries
- `preheader` — hidden preview text
- `ghost-table` — Outlook column fallbacks

**Hard fail:** never write “X% of emails…” unless that percentage appeared
in a `get_pattern` result **in this session**.

### Step 5: Choose write path

**Default — summary-grounded write (recommended for most briefs):**  
Write production HTML from scratch, informed by the summaries + patterns.
E1 showed compact summaries beat raw skeleton fill when the agent is free
to design.

**Chassis path — use when the user (or product prompt) asks for `get_skeleton`,
or you need a known-good Outlook stack:**

```
get_skeleton(slug="<best-match-slug>")
```

Then:

1. Fill copy tokens first (HEADLINE, BODY, CTA_TEXT, PREHEADER, FOOTER).
2. Read **`image_slots`** and **`image_policy`** — do not invent images.
3. For each slot: brand CDN URL **or** leave `{{IMG_*}}` and collect
   `needs_images[]`. **Never** placehold.co / dummyimage / picsum.
4. `cta_button_image` → replace with a bulletproof HTML button when you can.
5. Drop empty skeleton modules; stack multi-column blocks for mobile.
6. Subject + preheader + body offer must agree (same code/% if any).

### Step 6: Write the email

Structure (either path):

1. **DOCTYPE + html** — XHTML 1.0 Transitional (email standard)
2. **MSO conditionals** — Outlook conditional comments
3. **Preheader** — hidden preview text (max ~90 chars)
4. **Container table** — 600px width, centered
5. **Content** — brief + reference structure (from step 3)
6. **Footer** — unsubscribe, physical address, social
7. **Responsive CSS** — @media for mobile stacking

Code quality rules:
- Bulletproof buttons (VML fallback) — not image-only CTAs
- MSO conditionals for Outlook
- `role="presentation"` on layout tables
- Inline CSS; alt text + width/height on images
- Real assets only — honest `{{IMG_*}}` beats fake placeholders
- Palette from summary `color_palette` when brand colors unspecified
- Production preview: fill personalization tokens from the brief unless
  the user wants merge tags left raw

### Step 6b: Proof pairs / landing demos / “show before and after”

If the user wants a comparison (0 refs vs grounded):

| Arm | Source of truth |
|---|---|
| No library | Real no-ref output (eval artifact or a write with tools disabled and labeled). Minimal honest HTML chrome. Do not invent parody SaaS templates. |
| With library | `search` → `summary` / `skeleton` on **real cart/welcome slugs**, then write. Footer or notes **list those slugs**. |

Never invent both arms from imagination. Never use plain text alone as the
“production” arm. Never leave `{{IMG_HERO}}` dashed boxes on the grounded arm.

### Step 7: Deliver

Save the file and output the HTML. Report (required):

```
Based on:
- [company] — [slug]
- [company] — [slug]
Path: summary-write | skeleton-fill
Layout: [single/multi-column]
Patterns applied: [list with prevalence]
needs_images: [tokens still open, or "none"]
Colors: [#primary, #accent]  # from summary palette or brand brief
```

## Anti-patterns

- DON'T skip the search — training data is not a reference library
- DON'T use `get_email_html` for studying — use `get_email_summary` (~3KB)
- DON'T invent placehold.co / gray boxes / dashed `{{IMG_*}}` as finished work
- DON'T invent before/after demos — use eval artifacts + real corpus slugs
- DON'T write therapy-speak (“no guilt”, “hope this finds you well”, “amazing opportunity”)
- DON'T default every brand to indigo/purple SaaS chrome
- DON'T ship “CLICK HERE!!!” when summaries have real CTA labels
- DON'T treat skeleton fill as always best — prefer summary-write unless
  chassis is requested; when filling a skeleton, follow image_slots strictly
- DON'T forget the preheader
- DON'T ship image-only CTAs when an HTML button works
- DON'T use flexbox or CSS grid — tables only
- DON'T skip unsubscribe + physical address (CAN-SPAM / GDPR)
- DON'T omit slug citations