---
name: stack-overview
description: Explica qué es y qué puede hacer el stack de Indash — las 12 skills de creative performance, las 41 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 12 skills + las
  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 12 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` | El onboarding entero de una marca en Indash, conversando: ubica el workspace, carga el material al mismo onboarding de la app (el cliente de a una cosa, o alguien de Indash en su nombre con una carpeta con PDFs, capturas y audios), conecta la tienda, cierra con el inventario y su veredicto, y corre el análisis derivado (voz, objeciones, verbatims, avatar, sistema visual) para que la persona lo confirme rama por rama. Guarda el material crudo, sin resumir ni inferir. Al final, opcional, arma la carpeta local con el `CLAUDE.md` escrito desde Indash. Es lo que después lee `content-brief` | *"nuevo cliente: Acme"*, *"quiero cargar mi marca en Indash"*, *"el cliente me mandó todo esto, cargalo"* |
| `content-brief` | Brief de contenido del período, con el contexto de marca y la metodología del agente de briefs de la app: mensajes con fuente y cada pieza con copy literal. Lo guarda en Indash para revisión y dice qué skill ejecuta cada tipo de pieza | *"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 \<URL\>"* |
| `stories-nano-banana` | Secuencia de Stories 9:16 (1080×1920) con sticker de engagement y texto en zona segura | *"necesito stories para \<URL\>"* |
| `ads` | 3-5 Meta ads (FB/IG): imagen final + copy completo (Primary Text, Headline, Description, CTA) | *"hacé 3 ads para \<producto\>"* |
| `ugc-video-prompts` | Paquete de video UGC (Kling / Veo / Seedance + first/last frame con Nano Banana) | *"armá un UGC para \<producto\>"* |
| `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 \<cliente\> con \<producto\>"* |
| `locuciones` | **Voz en off / text-to-speech** con Gemini 3.8 TTS: guion para el oído, voz del roster de 30 (con audición), dirección en lenguaje natural por pieza y por línea, tags de vocalización, escenas de dos voces. WAV en la galería + guion dirigido en disco. El agente no escucha el resultado: la persona elige | *"generá la voz para el reel"*, *"leé este guion con una voz"* |
| `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 \<producto\>"* |
| `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 12 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 41 tools del conector `indash`

Nueve 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 (12)** — `get_brand_kit`, `update_brand_kit`,
`list_products`, `create_product`, `update_product`, `get_product_images`,
`add_product_images`, `update_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 (5)** — `generate_image`, `generate_video`, `extend_video`, `get_video_result`, `generate_speech`

**Voces (3)** — `list_voices`, `design_voice`, `delete_voice`
Las voces con las que habla `generate_speech`: las 30 de estudio, la biblioteca
extendida de Google por idioma/acento/género, y las **diseñadas** por
descripción para el workspace (con sample). Diseñar cuesta un `short`; listar y
borrar son gratis.
Donde se consume crédito. Ver sección 4 para modelos y referencias.

**Galería de Indash (3)** — `upload_creative`, `promote_creative`, `list_creatives`
Suben una pieza a la galería de la marca en Indash y listan lo que ya hay.

**El onboarding de marca (6)** — `get_brand_onboarding`, `update_brand_onboarding`,
`create_onboarding_uploads`, `run_brand_onboarding_action`, `analyze_brand`,
`confirm_brand_analysis`
Lo que usa `new-client`. Es el mismo onboarding de la app
(`/w/<slug>/onboarding`) y escribe al mismo lugar, así que se puede hacer mitad
acá y mitad allá. `get_brand_onboarding` trae lo cargado, el inventario con su
veredicto, qué pedir ahora y la guía de conducción. `update_brand_onboarding`
guarda textos, archivos, links, mecanismos, límites y audios (los transcribe el
server). `create_onboarding_uploads` da URLs firmadas para subir archivos de
hasta 50 MB desde un cliente con shell. `run_brand_onboarding_action` conecta la
tienda, lee Instagram **solo si la persona lo acepta** y cierra el onboarding. A
ningún campo entra nada que la persona no haya dicho, pegado, subido o aprobado
en la conversación. `analyze_brand` produce, con ese material y nada más, lo
derivado: perfil de voz, objeciones priorizadas, verbatims, avatar y sistema
visual. Nace pendiente y **el agente de briefs no lo ve hasta que un humano lo
confirme** con `confirm_brand_analysis`, rama por rama (confirmar o rechazar,
sin editar). Sin reseñas y sin corpus no hay análisis. No consumen crédito.

**El brief del período (2)** — `get_brand_context`, `save_brief`
Lo que usa `content-brief`. `get_brand_context` trae el contexto de marca que
cargó el cliente en su onboarding (con los archivos originales: las imágenes se
ven, el resto llega como URL firmada), el plan con su cupo, el período que
viene y la metodología con la que Indash arma un brief — **la misma del agente
de briefs de la app**, servida en vivo. `save_brief` valida el brief, lo guarda
como borrador en la app, devuelve los chequeos que revisa Indash y, solo cuando
la persona lo confirma, lo manda a revisión. No consumen crédito.

**Pedidos y colaboración (5)** — `upload_briefs`, `list_briefs`,
`update_brief_status`, `add_comment`, `list_comments`
Kanban de pedidos de piezas (`backlog` / `todo` / `in_progress` / `done`) y
comentarios sobre creatives o pedidos, compartidos con el equipo en la app. No
es el brief del período: ese es el de arriba.

**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 12 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 12 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:

```
<cliente>/
  exports/carruseles/  stories/  ads/  videos/  emails/
  briefs/
  assets/  creatives/  versions/
```

Nombre canónico: `<AAAA-MM-DD>_<slug>_v<N>.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.
- `update_brand_onboarding` / `analyze_brand` → el material de la marca y su análisis quedan en su onboarding, el mismo que se ve en la app. `new-client` no guarda nada en disco salvo que la persona pida la carpeta local.
- `save_brief` → el brief del período queda como borrador en la app, con su URL; con confirmación de la persona, pasa a revisión de Indash.
- `upload_briefs` → un pedido de pieza 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, video o locución generada se guarda además en la galería del workspace (las locuciones como creatives `audio`).

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.


### Voz — `generate_speech` (Gemini 3.8 TTS)

Text-to-speech con dirección. Dos modelos: `gemini-tts` (default, el que se
dirige) y `gemini-tts-lite` (dos tercios de los créditos, para volumen).
`style` en lenguaje natural para la pieza, acotaciones por línea entre
paréntesis, tags como `<laugh>` / `<sigh>` / `<short pause>` en el punto exacto,
y escenas de **dos voces** con turnos naturales. Sale un WAV (24 kHz mono) por
item, guardado como creative `audio` en la galería.

**Las voces, tres fuentes:** las 30 de estudio (cualquier idioma), la
**biblioteca extendida** de Google (`list_voices` por `language_codes`,
género, acento, persona) y las **diseñadas** (`design_voice`: *"una argentina
de veinte años, voz clara, acento porteño"* → un `voice_…` del workspace con
sample para escuchar). La regla: **edad, género y acento son de la voz; el
`style` es de la lectura** — Google lo dice explícito. Las diseñadas viven un
año y hay 200 por proyecto para todo Indash: se borran las descartadas.

Se cobra **por item según el largo del guion** (caracteres hablados, sin tags):
`short` ≤450 (~30s), `standard` ≤1.500 (~100s), `long` ≤4.500 (~5 min, el
tope). Una audición de una línea en tres voces son tres `short`.

Lo que **no** hace hoy: clonar la voz de una persona real, MP3 desde el
conector (se convierte local con `ffmpeg`), duración exacta. La skill
`locuciones` lleva todo esto.

## 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).