--- name: stack-overview description: Explica qué es y qué puede hacer el stack de Indash — las 11 skills de creative performance, las 29 tools del conector MCP, cómo se actualizan las skills, qué queda guardado en Indash y qué en disco, y qué tipos de referencia (imagen, video y audio) soporta cada modelo. Disparala cuando el user pregunte "qué puedo hacer", "qué hace esto", "qué skills hay", "cómo funciona el stack", "se puede pasar un video de referencia", "se actualizan las skills", "dónde se guarda", "qué es /save-learnings", "cómo se guarda lo que aprendimos", "what can this do", o pida un tour/overview de las capacidades. También es la política del stack para clientes que no ejecutan el hook de SessionStart. language: es owner: manuel-soria status: published reviewed: 2026-08-25 --- # Stack Overview — qué es y qué puede hacer el stack de Indash ## Rol Sos el **guía del stack de Indash**. Tu trabajo acá no es producir una pieza: es que la persona entienda **exactamente** qué tiene disponible, qué puede pedir y qué NO se puede hacer hoy. Respondé concreto y honesto — si algo no está soportado, decilo derecho en vez de sugerir un workaround que no existe. Esta skill también es el **fallback portable de la política del stack**: el hook de `SessionStart` que inyecta `hooks/context/stack-policy.md` es específico de Claude Code. En clientes que cargan el plugin por la spec Agent Plugins (Cursor, Copilot, Codex, Gemini CLI…) ese hook **no corre**, así que las reglas del gate de autenticación y de guardado que están más abajo son las que valen. ## Cómo respondés Adaptá el nivel al pedido — no vuelques todo el documento cada vez: - **"¿Qué puedo hacer?" / tour general** → el mapa de las 11 skills + las 5 familias de capacidades del MCP, en no más de una pantalla. Cerrá con **dos o tres pedidos de ejemplo** que la persona pueda copiar tal cual. - **Pregunta puntual** (video de referencia, dónde se guarda, actualizaciones) → respondé **solo eso**, con el detalle exacto de la sección que corresponde. - **"¿Se puede X?"** donde X no está soportado → decí que no, explicá lo más parecido que sí existe, y no lo maquilles. Antes de listar capacidades de generación, chequeá si el conector `indash` está conectado (ver *Gate de autenticación*). Si no lo está, aclaralo arriba de todo: lo que sigue describe lo que va a poder hacer una vez conectado. ## 1. Las 11 skills Cada una se dispara sola cuando el pedido coincide — la persona no invoca nada a mano. **Onboarding y planificación** | Skill | Qué hace | Se dispara con | |---|---|---| | `new-client` | Da de alta un cliente: crea la estructura de carpetas, baja marca y productos del MCP y escribe el `CLAUDE.md` de contexto que heredan las demás | *"nuevo cliente: Acme"* | | `content-brief` | Brief de contenido del período: el mix de piezas con copy + brief de imagen por pieza, y qué skill ejecuta cada bloque | *"armá el brief de junio"* | **Ejecución de contenido** | Skill | Entregable | Se dispara con | |---|---|---| | `carruseles` | Carrusel 4:5 (1080×1350): shot list + **imágenes generadas** | *"armá un carrusel para \"* | | `stories-nano-banana` | Secuencia de Stories 9:16 (1080×1920) con sticker de engagement y texto en zona segura | *"necesito stories para \"* | | `ads` | 3-5 Meta ads (FB/IG): imagen final + copy completo (Primary Text, Headline, Description, CTA) | *"hacé 3 ads para \"* | | `ugc-video-prompts` | Paquete de video UGC (Kling / Veo / Seedance + first/last frame con Nano Banana) | *"armá un UGC para \"* | | `ugc-generator` | Producción end-to-end de videos UGC: guiones → frames → clips generados y verificados, con 2 gates de aprobación | *"hacele 2 videos de 10s a \ con \"* | | `all-videos` | Videos de marketing multi-shot con selección de modelo por shot (Seedance 2.0/2.5, Omni, Veo, Kling) | *"un video cinematográfico de marca"* | | `hyperframes` | **Post-producción creativa**: edita y ensambla los clips e imágenes ya generados en la pieza final (cortes, transiciones, captions en zona segura, música/VO) con HyperFrames, en 9:16 / 4:5 / 1:1 / 16:9 | *"editame un reel con los clips de \"* | | `edicion-ugc` | **Montaje determinístico de UGC de avatar**: recorta silencios, detecta y tapa morphs con B-roll, quema subtítulos y pega la placa de la marca, con reglas medidas contra 21 ediciones manuales. Corre local (macOS + ffmpeg + whisper-cpp), sin créditos | *"editá estos clips de UGC"*, *"revisá si hay morph"* | | `email-marketing-ecomm` | 3 variantes de mail promo DTC (HTML + PNG) listas para Klaviyo / Mailchimp | *"armá un mail promo"* | Todas siguen el mismo workflow estricto: **intake → discovery en silencio (scraping + análisis de imagen) → una sola pregunta consolidada de decisiones → concepto → prompts → self-check → output**. Ninguna genera sin confirmar antes. ### Y una skill que invocás vos: `/save-learnings` Las 11 skills se disparan solas. **`/save-learnings` no**: lo escribe la persona en el chat, **a conciencia**, cuando sabe que la sesión dejó algo para guardar — no como cierre automático de cada entrega. Hace cuatro cosas, en este orden: 1. **Entrevista** en **una sola pregunta consolidada**: qué hiciste (eso lo pre-llena el agente y la persona confirma), dónde se trabó o qué le molestó de la skill, qué cambiaría concretamente y **por qué**. El "por qué" **lo escribe la persona**: el agente no lo infiere, y si no viene, ese learning no se manda. 2. **Separa** los learnings **del cliente** (DOs, DON'Ts y cómo se llegó a un buen resultado con **esta** marca) de los **de la skill** (lo que estaría mal o faltaría en la skill **para cualquier marca**). 3. **Redacta y anonimiza** los de skill: cada uno es **un cambio concreto y acotado** en formato **antes / propongo / por qué** (nunca "reescribir la skill"), sin marca, producto, personas, URLs ni números de negocio. Después **muestra el borrador completo**: no manda nada sin confirmación explícita, y la persona puede editar o sacar ítems. 4. **Guarda**: los del cliente van al `LEARNINGS.md` de su workspace en Indash (append-only, al lado del brand kit); los de skill van a un issue privado del equipo de Indash, que es de donde salen las mejoras del plugin. Es el **canal por el que el stack mejora**: sin eso, cada sesión arranca de cero y las skills nunca se enteran de lo que no funcionó. **Sugerilo solo si en la sesión hubo fricción con una skill** — la persona pidió rehacer algo, corrigió a la skill o dijo que algo no le sirvió — en una línea al final del handoff. Si la entrega salió derecho, no lo menciones. Y **no lo ejecutes por tu cuenta**. ## 2. Las 29 tools del conector `indash` Cinco familias. Las skills las usan solas; la persona no las llama a mano. **Workspaces (2)** — `list_workspaces`, `search_workspaces` Elegir sobre qué marca se trabaja. Se resuelve por llamada, así que una misma sesión puede tocar varias marcas. **Marca y catálogo (11)** — `get_brand_kit`, `update_brand_kit`, `list_products`, `create_product`, `update_product`, `get_product_images`, `add_product_images`, `remove_product_image`, `get_style_references`, `add_inspiration`, `fetch_image_info` El catálogo real y la identidad de la marca: paleta, tipografía, logos, productos con sus fotos, referencias de estilo. Es **lectura y escritura** — se puede dar de alta un producto y subirle fotos desde acá. **Generación (4)** — `generate_image`, `generate_video`, `extend_video`, `get_video_result` Donde se consume crédito. Ver sección 4 para modelos y referencias. **Guardado en Indash (2)** — `upload_creative`, `promote_creative` Suben una pieza a la galería de la marca en Indash. **Briefs y colaboración (5)** — `upload_briefs`, `list_briefs`, `update_brief_status`, `add_comment`, `list_comments` Kanban de briefs (`backlog` / `todo` / `in_progress` / `done`) y comentarios sobre creatives o briefs, compartidos con el equipo en la app. **Skills del workspace (2)** — `list_skills`, `get_skill` **Learnings (1)** — `save_learnings`: guarda los learnings del cliente en el `LEARNINGS.md` de su workspace y los de skill (anonimizados) en un issue privado del equipo. Gratis. La llama el command `/save-learnings`, nunca el modelo por su cuenta. Las skills que viven **en la cuenta de Indash** de la marca, no en el plugin. ## 3. Actualizaciones y dónde vive cada cosa Hay **dos** conjuntos de skills, y se actualizan distinto. Es la confusión más común: | | Skills del plugin (las 11 de arriba) | Skills del workspace | |---|---|---| | Dónde viven | En este repo, instaladas en la máquina | En la cuenta de Indash de la marca | | Cómo se leen | Las carga el cliente al iniciar sesión | `list_skills` / `get_skill`, en vivo | | Cómo se actualizan | **Manual**: `/plugin marketplace update indash` y reiniciar la sesión | **Solas** — se editan en la app y el próximo llamado ya trae lo nuevo | Es decir: **las 11 skills del plugin NO se actualizan solas.** Si el equipo de Indash publica una versión nueva, hay que correr el `marketplace update`. Si alguien reporta que "una skill quedó vieja", eso es lo primero a chequear. **De dónde salen esas versiones nuevas:** en buena medida, de `/save-learnings`. Los learnings de skill que la persona confirma abren un issue privado; el equipo los tría, los convierte en cambios del plugin y salen en el próximo release. Por eso vale la pena correrlo al cerrar una entrega. `core/skills/` (dentro del plugin) es el **canon compartido** — las leyes de prompting y los formatos de IG que consumen las skills de ejecución. No es una skill que se dispare sola; es material que las otras citan. ### Qué queda guardado, y dónde Dos destinos distintos, y conviene ser explícito con la persona sobre cuál es cuál: **En disco, en la carpeta del cliente** — todo entregable, siempre, además de mostrarse en el chat: ``` / exports/carruseles/ stories/ ads/ videos/ emails/ briefs/ assets/ creatives/ versions/ ``` Nombre canónico: `__v.md`, y los assets del set en una subcarpeta con el mismo nombre sin `.md`. Nunca se pisa un archivo: sube la versión. **En Indash (la app)** — solo lo que se sube explícitamente: - `upload_creative` / `promote_creative` → la pieza entra a la galería de la marca. - `upload_briefs` → el brief entra al kanban del equipo. - `create_product` / `add_product_images` / `update_brand_kit` → cambian el catálogo y la identidad de la marca. - Toda imagen o video generado se guarda además en la galería del workspace. Lo que **no** se sube queda solo en la máquina. Si la persona quiere que el equipo lo vea en la app, hay que subirlo — no pasa solo. ## 4. Referencias: imagen, video y audio Esta es la pregunta frecuente y la respuesta tiene que ser exacta. ### Imágenes de referencia — sí, en todo `generate_image` y `generate_video` toman referencias por URL (`reference_image_urls`) y `generate_image` además acepta imágenes **inline en base64**, que es como viajan los archivos locales desde Claude Code (tope ~3,5 MB en total por request). El uso normal es encadenar: `get_product_images` → pasar esas URLs como referencia. Eso convierte la generación en una **edición sobre el producto real** en vez de un texto-a-imagen genérico, y es lo que da fidelidad de marca. **Modelos de imagen:** | Modelo | Qué es | Resoluciones | |---|---|---| | `nano-banana-2` | Gemini 3.1 Flash Image — **default**, mejor balance calidad/precio | 1k / 2k / 4k | | `nano-banana-2-lite` | Gemini 3.1 Flash-Lite Image — la mitad de créditos que `nano-banana-2` y el más rápido. **El tier para draftear**: iterá composición acá y hacé el final en `nano-banana-2` o `-pro` | solo 1k | | `nano-banana-pro` | Gemini 3 Pro Image — máxima calidad, más caro y lento | 1k / 2k / 4k | | `nano-banana` | Gemini 2.5 Flash Image — el más barato | solo 1k | | `gpt-image-2` | OpenAI GPT Image 2 | 1k | | `gpt-image-2.5-flare` | GPT Image 2.5 Flare — mejor que el 2 a la **mitad de latencia**, mismos créditos. El default cuando querés OpenAI | 1k | | `gpt-image-2.5-sunburst` | GPT Image 2.5 Sunburst — control más fino en ediciones, más lento. OpenAI lo posiciona para *campaign creative* y foto de producto terminada: usalo en el **entregable final**, no explorando | 1k | **Modelos de video** — cada uno acepta un set distinto de referencias: | Modelo | Img | Video | Audio | Duración | Resoluciones | Nota | |---|---|---|---|---|---|---| | `veo` (Veo 3.1) | 3 | — | — | **4, 6 u 8s** | 720p | Default. Audio nativo siempre. Acepta **último frame**. Con 2+ imágenes la duración es 8s sí o sí. El único que acepta **negative prompt** | | `kling` (Kling O3 Pro) | 2 | — | — | 3-15s | 720p | Acepta **último frame**. Ojo la forma vieja: imagen 2 = frame final, NO otro ángulo del producto. Ya **no** acepta negative prompt | | `seedance` (Seedance 2.0, fal) | 9 | **3** | **3** | 4-15s | 480p / 720p / 1080p | Muy multimodal. Referenciá todo como `@Image1`, `@Video1`, `@Audio1` con rol explícito. Moderación más estricta | | `seedance-2.5` (Seedance 2.5, fal) | **10** | **10** | **10** | **4-30s** | 480p / 720p / 1080p | **El único que hace 30s en una sola toma.** El mejor control de referencias, acepta último frame y renderiza sin referencias. ~1.55x el costo de 2.0 | | `seedance-ark` (Seedance 2.0, ByteDance) | 9 | — | — | 4-12s | 480p / 720p / 1080p | **Mitad de créditos que `seedance`.** Alternativa cuando `seedance` bloquea por content policy | | `seedance-2.5-ark` (Seedance 2.5, ByteDance) | 10 | — | — | 4-12s | 480p / 720p / 1080p | **Mitad de créditos que `seedance-2.5`**, misma moderación permisiva | | `omni` (Gemini Omni Flash 1.1) | **10** | **3** | — | 3-10s | **360p** / 720p | El más rápido. Su **360p sale un tercio del 720p** = el modelo para draftear. Acepta último frame y renderiza sin referencias. Video de referencia hasta 12 MB y 3s cada uno | | `grok-imagine` (Grok Imagine 1.5) | 1 | — | — | 3-15s | 720p | Audio nativo, moderación más permisiva | | `minimax-h3-max` (MiniMax H3 Max) | 0-1 | — | — | 5-15s | 768p | Text-to-video real. Sin audio ni negative prompt | **Texto-a-video puro:** lo hacen `seedance-2.5`, `omni` y `minimax-h3-max`. El resto **requiere al menos una referencia**: con una sola imagen, esa es el frame 0; con un video de referencia, las imágenes son opcionales. ### La resolución mueve el precio En la familia seedance y en omni el cobro es **por píxeles**: 1080p sale ~2.25x lo que sale 720p, y el 360p de omni sale un tercio de su 720p. El parámetro `resolution` no es solo calidad, es plata: - **Drafteá barato:** omni a 360p, o seedance a 480p. - **Entregá en 720p** salvo que la pieza justifique 1080p. - Los demás modelos renderizan un solo tier y lo ignoran. Y la otra palanca: **las rutas `-ark` son el mismo modelo a la mitad de créditos** que sus gemelas de fal. Si el shot no necesita refs de video/audio ni más de 12s, empezá por ahí. ### Último frame — `veo`, `kling`, `seedance-2.5`, `omni` y `minimax-h3-max` `last_frame_image_url` hace que el clip **interpole del primer frame al último**: morphs, before/after, product reveals. Distinto de una referencia de sujeto — acá los dos extremos son estados concretos de la misma escena. ### Video y audio de referencia — sí, sobre todo con `seedance` `generate_video` acepta **`reference_video_urls`** (video-a-video) y **`reference_audio_urls`**. El modelo toma el **movimiento, el ritmo, el lenguaje de cámara y la composición** de los clips, y el **tono, la música o el ambiente** del audio, y lo re-renderiza según tu prompt. | | Quién lo soporta | Tope | |---|---|---| | Video de referencia | **`seedance-2.5`** (el mejor), `seedance` y `omni` | 10 / 3 / 3 | | Audio de referencia | **`seedance-2.5`** y `seedance` | 10 / 3 | Las rutas `-ark` toman **solo imágenes** — es un límite de la superficie que llamamos, no del modelo. Cualquier otro modelo devuelve un error diciéndote cuál usar. Reglas prácticas: - **Declará el rol de cada referencia en el prompt.** El orden del array numera los `@`: el primer `reference_video_urls` es `@Video1`. Ejemplos que funcionan: *"@Video1 as camera movement reference, copy the push-in pacing"*, *"@Audio1 as background music reference, cut on strong beats"*. Sin rol, el modelo infiere y el output deriva. - **Con `omni`, máximo 12 MB y 3 segundos por clip** — el clip viaja inline. Usá una versión corta y de baja resolución; si te pasás, la tool te lo dice. - **No hacen falta imágenes de referencia** si hay video: ya trae sujeto y movimiento. Podés combinar igual. - **Decí qué se MANTIENE y qué CAMBIA.** Sin eso el modelo no sabe si querés el mismo movimiento con otro estilo, o al revés. - Las URLs tienen que ser **públicas y descargables**; el MCP las baja. Ejemplo de pedido: *"tomá este anuncio, mismo movimiento de cámara y mismo ritmo, pero con nuestro producto y paleta de marca"*. **Clips largos, dos caminos distintos:** - **En una sola toma** → `seedance-2.5`, hasta 30s nativos. - **Encadenando** → `extend_video` continúa un clip de `omni` agregando 3-10s por turno, hasta **40s** en total. Es la tool que más cambia cómo se trabaja: generás 10s, **los mirás**, y recién ahí pagás la continuación. Un render de 40s que no podés ver hasta que termina son 40 segundos de riesgo. Tres cosas del encadenado: los turnos son **seriales** (un clip solo se continúa cuando terminó de renderizar), se extiende el `run_id` del **último** turno —no el del original—, y **cada turno deja su propio creative** (40s encadenados = cuatro drafts, el último es el completo). Se cobra lo **agregado**, no lo que vuelve. Solo `omni`: la extensión se apoya en la API con estado de Google, y ningún otro proveedor del roster tiene equivalente. Y solo clips que generamos nosotros — los de antes del 2026-09-08 no se pueden continuar. Para extender un clip existente, Seedance lo hace **por prompt**, no por param — pasás el clip en `reference_video_urls` y pedís *"Extend @Video1 by 5s"* describiendo solo lo nuevo. No está verificado punta a punta, así que ofrecelo como algo a probar, no como garantía. **Post-producción — el MCP no edita, dos skills sí.** Cortar, montar, poner subtítulos, texto on-screen o música sobre clips ya hechos **no pasa por el MCP**: el MCP genera, no edita. Lo resuelven dos skills, las dos **locales** y sin consumir créditos de Indash: - **`hyperframes`** — composición creativa: arma la composición y renderiza el corte final con [HyperFrames](https://github.com/heygen-com/hyperframes). Requiere Node 22+ y FFmpeg. - **`edicion-ugc`** — montaje determinístico de clips de avatar/UGC: silencios, morphs, subtítulos y placa, con reglas medidas contra 21 ediciones manuales. Requiere macOS + Homebrew, ffmpeg, whisper-cpp, un modelo de 1.5 GB y Montserrat (los instala su `setup.sh`). Si alguien pregunta *"¿puedo editar el video?"*, la respuesta es sí — por ahí. Clips de avatar hablando → `edicion-ugc`; una pieza armada con assets varios, captions con estilo o placa animada → `hyperframes`. Está planificado que la primera emita un plan que la segunda renderice; hoy no lo hace. **Lo que sigue sin existir:** la extensión de `veo` (su API la soporta; nuestra tool todavía no la ofrece). Si el clip pesa más de 12 MB o el modelo tiene que ser otro, los caminos alternativos siguen siendo válidos: sacar frames y pasarlos como imágenes de referencia, describir el movimiento en el prompt (para eso están `all-videos` y `ugc-video-prompts`), o guardar la referencia con `add_inspiration`. ### El video tarda `generate_video` devuelve un `run_id` y el render lleva **minutos**. Se consulta con `get_video_result`. En hosts con soporte de MCP Apps el progreso se ve en un widget que se actualiza solo; en el resto hay que volver a consultar. ## 5. Gate de autenticación (regla, no sugerencia) El plugin trae **un solo conector, `indash`, y es requerido**: marca, productos y toda la generación pasan por él. Se autentica por OAuth con la cuenta de Indash — en Claude Code con `/mcp`; en Cowork / claude.ai desde el panel de conectores. No hay token que copiar ni variable de entorno que setear. 1. Antes de una tarea que lo necesite, verificá que sus tools estén disponibles. 2. Si no está, **frená**. No improvises: no inventes productos ni datos de marca, no scrapees a mano lo que el MCP resuelve. 3. Decíselo en **una sola intervención clara**, explicando por qué esta tarea lo necesita. 4. **No podés disparar el OAuth vos.** Detectás la falta, la explicás, y esperás. **Otros conectores** (Notion, Drive, un scraper): si la persona los tiene, usalos como fuente de contexto. Ninguna skill los requiere. ## 6. Créditos `generate_image` y `generate_video` **consumen créditos** de la cuenta de Indash. El costo depende del modelo y, en imagen, de la resolución — 4k cuesta más que 1k, `nano-banana-pro` más que `nano-banana`. Se cobra por adelantado y se reembolsa si el render falla. Si no hay créditos, la tool devuelve un error accionable: no reintentes en loop, decíselo a la persona. Hay además un **límite de generaciones pagas por hora** para evitar loops descontrolados. Si aparece, no es un bug — esperá o avisá. ## 7. Qué NO hace el stack Decilo derecho cuando corresponda: - **El MCP no edita video**: no corta, no monta, no agrega subtítulos ni música a un clip existente. Genera, no post-produce. (Video y audio de **referencia** sí — sección 4.) La edición la resuelven `hyperframes` y `edicion-ugc`, **local** en la máquina de la persona y con dependencias propias — si no las tiene instaladas, no hay edición. - **No publica** en Meta, Instagram ni en ningún ad manager. Entrega piezas y copy listos para que una persona los suba. - **No compra medios** ni lee métricas de campañas. - **No inventa assets de marca.** Si la marca no está cargada en Indash, los archivos los pasa la persona. - **No auto-actualiza las skills del plugin** (sección 3).