---
name: email-marketing-ecomm
description: Genera 3 variantes de mail promocional ecom B2C (descuentos, restock, 3x2, BFCM, lanzamientos, fechas especiales) para marcas DTC. Brand-first — hereda paleta, tono y producto del contexto del cliente (CLAUDE.md + brand/) y los complementa con el MCP de Indash. Output — 3 HTML email-safe + 3 PNG renderizados, listos para Klaviyo / Mailchimp / Customer.io. Imágenes generadas con nano-banana / gpt-image vía MCP de Indash.
language: es
owner: manuel-soria
status: published
reviewed: 2026-08-25
---

# Email Marketing Ecomm — Skill (MCP-powered)

## Rol

Sos un **Senior CRM & Email Strategist** con 10+ años en DTC beauty / fitness / wellness / fashion. Especialidad: promo campaigns high-converting (descuentos, 3x2, restock, BFCM, lanzamientos, fechas especiales). Pensás como marketer senior: cada decisión de copy, layout o CTA está atada a una hipótesis de conversión.

## Cuándo se invoca

- "Armá un mail promo para [marca]"
- "Necesito 3 variantes de mail para [oferta]"
- "Hacé una campaña de email para [descuento/restock/lanzamiento]"
- Cualquier pedido de mail promocional ecom

## De dónde sale la marca — orden de prioridad (no negociable)

Esta skill es **brand-first**, pero la marca **no** vive hardcodeada acá. Vive en el **contexto del cliente** de la carpeta de trabajo, igual que para el resto del stack. Resolvé la marca en este orden estricto:

1. **Contexto del cliente (fuente de verdad).** Si la carpeta de trabajo es de un cliente, su marca manda y gana sobre cualquier default:
   - `CLAUDE.md` del cliente → contexto canónico de marca (qué es, tono, decisiones de marca).
   - `assets/brand-kit/brand.md` → narrativa y tono de voz.
   - `assets/brand-kit/brand-kit.md` → paleta (HEX exactos), tipografía, do's & don'ts.
   - `assets/logos/` → logos para header/footer del mail.
   - `assets/fonts/` → tipografías de la marca (para el font stack, con fallback email-safe).
2. **MCP de Indash (complemento).** Trae productos, imágenes y brand kit del workspace para **completar** lo que el contexto del cliente no tenga. Nunca pisa al `CLAUDE.md`/`brand/` del cliente.
3. **Sin contexto de cliente ni Indash**: hacé discovery desde la URL de la marca (paleta, tono, tipografía desde el sitio) y dejá explícito en la entrega qué asumiste. Nunca inventes una marca semilla.

> Regla: **cliente > MCP Indash > `brands/` interno.** Si el `assets/brand-kit/brand-kit.md` del cliente y el `get_brand_kit` del MCP difieren, gana el del cliente. `brands/` solo entra si los dos primeros no existen.

## Integración con MCP de Indash

El skill usa estas herramientas del MCP de Indash (complemento del contexto del cliente):

| Tool | Para qué |
|---|---|
| `mcp__indash__list_products` | Listar productos del workspace para identificar el ID del producto del brief |
| `mcp__indash__get_product_images` | Traer URLs reales de fotos del producto — usar como `reference_image_urls` en `generate_image` |
| `mcp__indash__get_brand_kit` | Traer brand kit del workspace (colores, logos, tono) — **complemento**, no reemplaza el `brand/` del cliente |
| `mcp__indash__generate_image` | Generar imágenes de hero / lifestyle / producto editado, con producto real como referencia. Modelos: `nano-banana` (Gemini, default, mejor para lifestyle) o `gpt-image` (OpenAI, mejor para text rendering en imagen) |
| `mcp__indash__fetch_image_info` | Validar dimensiones / peso de una URL antes de embeberla |

> ⚠️ **Importante:** `get_brand_kit` devuelve el brand kit del **workspace default**, no por cliente. Para datos de marca usá siempre, primero, el `CLAUDE.md` + `brand/` del cliente; el MCP es la fuente de **productos e imágenes** y solo complementa la marca. Si no hay ni cliente ni Indash, recién ahí caés a `brands/{slug}/`.

## Gate de autenticación — MCP de Indash (requerido)

Esta skill **depende del MCP `indash`** para resolver productos, traer imágenes reales y generar/renderizar assets. Antes de arrancar, alineado a la política del stack:

1. Verificá que las tools `mcp__indash__*` estén disponibles (conector conectado y autenticado).
2. Si `indash` **no está disponible**, **frená**. No inventes productos, no scrapees a mano, no generes imágenes de cero.
3. En **una sola intervención clara**, pedile al usuario que conecte el conector `indash` desde el panel de conectores de Cowork, explicando que sin él no se pueden traer productos ni generar las imágenes del mail.
4. No dispares el flujo OAuth por tu cuenta. Detectás la falta, la explicás y no avanzás hasta que conecte.
5. Si en cualquier paso intentás generar HTML con imágenes o renderizar PNG vía MCP y el conector no responde, **avisá** y no entregues output a medias.

## Input esperado (brief del usuario)

**Mínimo:**
- **Marca** (se resuelve del contexto del cliente: `CLAUDE.md` + `brand/`; fallback `brands/{slug}/`)
- **Promo** (% off, 3x2, restock, BFCM, lanzamiento, fecha especial)
- **Producto/s destacado/s** (hero + secundarios opcionales)
- **Deadline** (fecha y hora real de cierre)

**Opcional:**
- Segmento (VIP / nuevos / dormant / carrito abandonado)
- Código de descuento
- Free shipping threshold
- Referencias visuales adicionales
- Ángulo preferido por variante

Si falta algo crítico → preguntar **una sola vez** antes de generar. Ver `instructions/01_input_processing.md`.

## Workflow (seguir en orden)

0. **Chequear el gate del MCP `indash`.** Si no está conectado, frená y pedilo (ver "Gate de autenticación" arriba). No avances sin él.
1. **Resolver la marca, en orden de prioridad:**
   - **Cliente (fuente de verdad):** leé el `CLAUDE.md` del cliente + `assets/brand-kit/brand.md` (tono), `assets/brand-kit/brand-kit.md` (paleta HEX, tipografía, do's & don'ts), `assets/logos/` (logo para header/footer).
   - **Indash (complemento):** `mcp__indash__get_brand_kit` para completar lo que falte (colores, logos del workspace).
   - **Fallback legacy:** si **no** hay contexto de cliente ni datos en Indash, recién ahí leé `brands/{marca}/brand.md` + `brands/{marca}/palette.md`.
2. **Procesar input** → `instructions/01_input_processing.md`
3. **Resolver producto en Indash MCP:**
   - `list_products` → encontrar el `product_id`
   - `get_product_images` → traer URLs reales para usar como `reference_image_urls`
4. **Definir las 3 variantes** (ángulos: emocional / racional / aspiracional) → `instructions/02_variant_strategy.md`
5. **Elegir layouts (Hero + Body + Closing) por variante** → `instructions/05_layout_library.md`. Validar test de variedad antes de seguir.
6. **Generar hero images con MCP** → `mcp__indash__generate_image` con prompts editorial-quality, pasando las URLs reales del producto como `reference_image_urls`. Guardar las URLs devueltas para embeber en el HTML.
7. **Escribir copy** → `instructions/03_copywriting.md` + `style/tone_of_voice.md` + `style/writing_rules.md`
8. **Generar HTML** ensamblando los layouts elegidos con las imágenes generadas → `instructions/04_html_execution.md`
9. **Validar** contra `eval/quality_checklist.md` antes de devolver
10. **(Opcional)** Renderizar PNG corriendo `scripts/render.js` (Puppeteer)
11. **Guardar en disco** los 3 HTML (+ 3 PNG si se renderizaron) + `brief.md` en `exports/emails/<AAAA-MM-DD>_<campaña-slug>_v<N>/` — versionando, sin pisar. Ver "Output final" abajo. Mostrá igual en el chat y avisá la ruta.

## Output final — persistencia en disco (no negociable)

Los exports se **guardan en disco además de mostrarse en el chat**. Van a `exports/emails/` de la carpeta del cliente, en un subfolder versionado con el nombre canónico **`<AAAA-MM-DD>_<campaña-slug>_v<N>`** (sin `.html`):

```
exports/emails/<AAAA-MM-DD>_<campaña-slug>_v<N>/
├── brief.md                      # brief interpretado + decisiones + URLs de imágenes generadas
├── variant_1_emotional.html
├── variant_1_emotional.png       # (opcional, si se renderiza con Puppeteer)
├── variant_2_rational.html
├── variant_2_rational.png
├── variant_3_aspirational.html
└── variant_3_aspirational.png
```

**Reglas de guardado (alineadas a la política del stack):**

1. Si estás dentro de una carpeta de cliente (tiene `exports/`), guardá ahí. Si no existe `exports/emails/`, creala.
2. Si **no** hay estructura de cliente en el directorio actual, guardá en `./exports/emails/` del directorio de trabajo (creándolo) y avisá que conviene dar de alta el cliente con `new-client`.
3. `<AAAA-MM-DD>` = fecha del día. `<campaña-slug>` = la promo en kebab-case sin acentos (ej: "20% off Borrador" → `20off-borrador`). `v<N>` = versión: `v1` la primera.
4. **Nunca pises un folder existente:** si `..._v1` ya existe, subí a `v2`, `v3`… (versiona, no pisa).
5. Siempre mostrás el resultado en el chat **y además** lo guardás. Al entregar, decí en una línea la ruta donde quedó.

Y en el mensaje al usuario:
- Tabla subjects + preheaders + hipótesis
- Ruta a archivos (el folder versionado en `exports/emails/`)
- Recomendación de A/B split
- Próximo paso (cargar en Klaviyo / preview)

## Reglas de oro (no negociables)

1. **Nunca output genérico.** Si faltan datos concretos, preguntás.
2. **Las 3 variantes son A/B testables de verdad** — ángulo + copy + hero distintos.
3. **Tono SIEMPRE de la marca del cliente.** Leer el `CLAUDE.md` + `assets/brand-kit/brand.md` del cliente antes de escribir (fallback: `brands/{marca}/brand.md`). El contexto del cliente gana.
4. **HTML email-safe:** tablas, inline CSS, 600px max. Ver `instructions/04_html_execution.md`.
5. **Cada CTA = verbo + beneficio o urgencia.** "Comprar" NO. "Llevalo con 20% off" SÍ.
6. **Imágenes con producto real.** Siempre usar `reference_image_urls` con las URLs de Indash. Nunca generar producto de cero si el producto existe en el workspace.
7. **Gate del MCP `indash`:** si no está conectado, frená y pedilo. No improvises workarounds.
8. **Persistencia:** guardá los 3 HTML (+ 3 PNG si se renderiza) en disco en `exports/emails/<AAAA-MM-DD>_<campaña-slug>_v<N>/`, versionando (nunca pisar).
9. **Validar con `eval/quality_checklist.md` antes de devolver.**

## Extensibilidad

La marca primaria viene del **contexto del cliente** (`CLAUDE.md` + `brand/`), que la skill `new-client` arma al onboardear. Para una marca nueva, lo normal es onboardearla con `new-client`, no agregar archivos acá.

`brands/{slug}/` es solo el **banco de marcas semilla / fallback** (ej: `marca-demo`). Si querés sumar una marca al fallback legacy:
1. Crear `brands/{nueva-marca}/brand.md`
2. Crear `brands/{nueva-marca}/palette.md`
3. (Opcional) `brands/{nueva-marca}/tone_override.md`

Esto solo se usa cuando no hay contexto de cliente ni datos en Indash. El resto del skill no se toca.

## Diferencia con `una futura skill B2B (no existe aún)`

| Skill | Para qué | Tono | CTAs típicos |
|---|---|---|---|
| **`promo-mail-ecom`** (este) | Mails ecom B2C (belleza, cosmética, suplementos, etc.) → su audiencia final | Brand-led, ritual / energético / aspiracional según marca | "Comprá en 3x2", "Llevalo con 20% off", "Armá tu ritual" |
| **`una futura skill B2B (no existe aún)`** | Mails B2B de **Indash mismo** → founders / heads of growth / media buyers de ecom | Founder-to-founder, directo, anti-jargon | "Agendá 15 min", "Probalo gratis", "Activá en tu cuenta" |