---
name: post-krafter
description: >-
  Genera posts de redes sociales (Instagram/Facebook) para propiedades inmobiliarias,
  maquetados en HTML/CSS con el design system del cliente y renderizados a imagen (PNG)
  en formatos feed 1080x1350, cuadrado 1080x1080 y story 1080x1920. Activar SIEMPRE que
  el usuario pida crear un post, creativa, flyer, publicación, story o imagen para una
  propiedad; pase una URL de listing (EasyBroker, sitio inmobiliario en WordPress) o fotos
  de una propiedad; o mencione "Post Krafter", "post de esta casa", "creativa inmobiliaria",
  "flyer de propiedad". SOLO bienes raíces. Usa fotos REALES del listing (nunca generadas).
  Produce diseño nivel Canva con dirección de arte (composición, tipografía, capa de
  criterio y curvas).
---

# Post Krafter

Actúa como director de arte inmobiliario. Genera posts como mini-páginas web (HTML/CSS) usando el
design system del cliente como tokens, y las renderiza a imagen. La creatividad vive en una **capa
de diseño de movimientos pre-aprobados** (`references/capa-creativa.md`), no en improvisación.

## Regla de oro (inviolable)

**Los píxeles reales nunca pasan por IA generativa.** Las fotos de la propiedad se descargan del
listing y entran como archivos `<img>` intactos. La IA solo genera lo que no existe (layout, fondos).
Nunca recrear, regenerar ni "imaginar" la casa/producto. Íconos = Tabler webfont, NUNCA emoji.
Colores/logo/fuentes SIEMPRE de los tokens del cliente, nunca hex sueltos.

## ⚡ Si estás en Cowork, lee esto PRIMERO

El entorno Cowork (sandbox Linux) tiene la red muy restringida y es donde los chats nuevos se
atoran. **Antes de hacer nada, abre `references/pipeline.md` y sigue el §0 QUICKSTART COWORK paso a
paso.** En resumen, lo que NO hay que hacer (y por qué fallan): `curl`/`wget` (bloqueados),
`pip install playwright` (CDN bloqueado), `npx puppeteer` (bloqueado). Lo que SÍ funciona:
`web_fetch` para el listing, `@sparticuz/chromium` vía npm para renderizar, y el MCP de Chrome para
bajar las fotos. Y el error #1: el `$` en heredoc de bash se come el precio — usa heredoc citado
`<<'PYEOF'` o la tool Write. Todo esto está detallado en pipeline.md §0 y §5.

## Flujo obligatorio

1. **Ingesta (sin IA generativa).** Obtener el HTML del listing y extraer datos
   (precio, recámaras, baños, m², ubicación) y las URLs de las fotos. Descargar las fotos reales a
   `assets/<propiedad>/`. La vía depende del entorno (Claude Code = curl; Cowork = web_fetch + MCP
   de Chrome para las fotos): ver `references/pipeline.md` **§0 QUICKSTART** (Cowork, paso a paso) o
   §1 (Claude Code).
2. **Capa de criterio (analizar antes de componer).** Mirar las fotos y el precio para decidir el
   tratamiento (ver `references/capa-creativa.md` §6): ¿lujo (>$10M o fachada fina) → `hero-solo`
   editorial? ¿estándar → varias fotos? Elegir la foto principal más impactante y **analizar su
   "aire"** para encuadrarla bien (§6 encuadre inteligente).
3. **Composición.** Elegir una receta de `plantillas/` y aplicar la gramática de
   `references/capa-creativa.md`: esqueleto + forma + acento + tipografía (Playfair + escala modular)
   + composición (tercios, aire, peso visual) + curvas si aplica. Rellenar los `{{PLACEHOLDERS}}`
   con los datos y fotos reales.
4. **Render.** HTML → PNG (ver `references/pipeline.md` §3): Edge headless en Claude Code, o
   `scripts/render.js` (Chromium vía npm + fuentes offline de `assets/fonts/`) en Cowork.
   Formatos: feed 1080×1350, cuadrado 1080×1080, story 1080×1920.
5. **QA visual.** Leer el PNG y revisar contra el checklist de `references/capa-creativa.md` §9:
   ¿foto real e impactante? ¿texto legible sobre foto? ¿íconos cargaron? ¿balance y aire correctos?
   ¿datos reales? Corregir y re-renderizar antes de entregar.

Mostrar el PNG al usuario y esperar aprobación antes de dar por terminado.

## Recetas disponibles (`plantillas/`)

| Receta | Esqueleto | Cuándo |
|---|---|---|
| `plantilla-lujo-onda.html` | `hero-solo` + onda + scrim | Propiedad de lujo (>$10M) o fachada fina. Datos mínimos, editorial |
| `plantilla-editorial-lateral.html` | `hero-lateral` + scrim + Playfair | Propiedad con buena fachada + interiores; balance foto/datos |
| `plantilla-story.html` | `hero-solo` vertical + scrim-bottom + chips | Story/reel cover 1080×1920 de cualquier propiedad; acompaña al post de feed. Respeta zonas seguras de IG |
| `plantilla-ficha-split-dark.html` | panel slate 44% + hero 60/40 + thumbs que invaden + checklist + CTA | Propiedad estándar/premium con muchos datos y features; el layout más "app" y vendedor |
| `plantilla-magazine-dark.html` | fondo azul marino + Playfair grande + hero enmarcado + aire | Propiedad cálida/residencial, renta premium. Editorial con aire, sobre oscuro |
| `plantilla-magazine-claro.html` | igual pero fondo crema | Misma receta en claro. Solo si el logo del cliente lee bien sobre fondos claros (el de Nodo NO) |
| `plantilla-tarjeta-flotante.html` | hero full-bleed + tarjeta blanca flotante | Propiedad con UNA foto muy fuerte y pocos datos. Look de app premium |
| `plantilla-mosaico-grid.html` | mosaico 3 fotos + banda slate de datos | Propiedad con varias fotos buenas y parejas (deptos nuevos, interiores) |
| (discover en `posts/`) | `hero-lateral` datos | Propiedad estándar con muchos datos/features |

Cuando una composición nueva funcione bien, guardarla como plantilla parametrizada aquí.

**Variedad por encima de la comodidad.** El objetivo del catálogo es que el feed del cliente no se
vea repetitivo: ninguna receta es "la preferida". Antes de elegir, revisar `posts/` para ver qué
esqueleto se usó en los últimos 2-3 posts de ese cliente y escoger uno distinto. Si el usuario pide
varios posts de golpe, repartir recetas diferentes entre ellos. Y cuando el catálogo ya cubra bien
un caso, vale más **inventar una receta nueva** (y guardarla) que reusar la de siempre — así el
catálogo crece con el uso.

## Estructura por cliente

El **skill es genérico**; los datos del cliente viven fuera y se pasan como input:
- `brand/tokens.css` — design system del cliente (colores, fuentes, radios). **Una vez por cliente.**
- `brand/logo-*.png` — logo.
- `assets/<propiedad>/` — fotos reales descargadas.
- `posts/` — PNG finales.

**Onboarding de cliente nuevo (design system primero).** Cada cliente trae un `design_system.md`
en su folder (concepto Claude Design que usa Med). Al arrancar con un cliente: buscar ese archivo,
extraer paleta/tipografías/radios y generar su `brand/tokens.css` con los MISMOS nombres de token
(`--primary`, `--accent`, `--f-display`, `--scrim-*`, etc.) para que todas las plantillas funcionen
sin tocarlas. Nunca pedir colores al usuario si existe design system; si hay más de uno en el
folder, preguntar cuál manda antes de generar tokens.

Nodo Inmobiliario es el cliente piloto embebido (sirve de ejemplo funcional).

## Referencias

- `references/capa-creativa.md` — **el cerebro**: gramática de composición, piezas inmobiliarias,
  capa de criterio, tipografía, composición/balance/aire, curvas, checklist.
- `references/pipeline.md` — scraping por fuente (EasyBroker, WordPress), comando de render,
  contrato de datos, gotchas conocidos.

## Reglas never (anti-genérico)

Ver `references/capa-creativa.md` §1. En resumen: nunca una sola fuente; nunca foto cruda si pide
elegancia; nunca todos los datos posibles (menos es más); nunca emoji; nunca texto blanco sobre foto
sin scrim; nunca repetir el mismo esqueleto dos posts seguidos; nunca hex fuera de tokens.
