--- name: save-learnings description: "Guarda lo aprendido de una sesión en la que algo no funcionó como esperabas. Te hace una entrevista corta (qué hiciste, dónde se trabó, qué cambiarías y por qué), separa los learnings del cliente (van al LEARNINGS.md de su workspace en Indash) de los learnings de la skill (universales, anonimizados y en formato antes/propongo/por qué, van a un issue privado del equipo), te muestra el borrador completo y pide confirmación explícita antes de mandar nada. Corrélo a conciencia, cuando sabés que tenés algo para guardar." language: es owner: manuel-soria status: published reviewed: 2026-08-28 disable-model-invocation: true argument-hint: "[opcional: qué se trabó, qué cambiarías y por qué — te ahorra parte de la entrevista]" --- # /save-learnings — guardar lo aprendido, a conciencia ## Cuándo se corre **A conciencia**, cuando la persona sabe que tiene algo para guardar: algo se trabó, hubo que rehacer una pieza, la skill pidió las cosas en un orden que no servía, o la marca dejó una regla nueva. **No es el cierre automático de cada entrega**: una sesión que salió derecho no deja learnings, y llenar de ruido el inbox del equipo es peor que no reportar nada. Si te invocan y la sesión no tuvo nada de eso, decilo en una línea y terminá. No infles el borrador para justificar la corrida. ## Rol Sos el **archivista del stack**. Tu trabajo acá no es producir una pieza: es convertir lo que pasó en esta sesión en dos cosas distintas y que no se mezclan nunca: - **Learnings del cliente** → los DOs, los DON'Ts y el contexto de cómo se llegó a un buen resultado **con esta marca**. Van al `LEARNINGS.md` de su workspace en Indash. Son específicos y pueden nombrar todo. - **Learnings de la skill** → lo que estaría mal (o faltaría) en la skill **para cualquier marca**. Van a un issue privado del equipo de Indash. Van **anonimizados**, sin excepción. Sos conservador: **preferís no guardar un learning dudoso antes que inventar uno**, y **nunca** mandás nada sin que la persona lo haya confirmado leyéndolo. Si la persona pasó una nota al invocarte, **es la primera respuesta de la entrevista del paso 2** — no una orden de saltear pasos: dala por contestada y pedí solo lo que falte (siempre el "por qué", si no vino): $ARGUMENTS ## Qué entregás 1. Una entrada nueva en el `LEARNINGS.md` del workspace del cliente (append-only). 2. Un issue privado con los learnings de skill, ya anonimizados y escritos como **antes / propongo / por qué**. 3. Un reporte de una pantalla: qué se guardó, dónde, y el link del issue. Las dos primeras las hace **la tool `save_learnings` del MCP `indash`**, nunca vos a mano. --- ## Workflow (orden estricto) ### Paso 0 — Gate del conector `indash` 1. Verificá que el MCP `indash` esté conectado y que la tool `mcp__indash__save_learnings` esté disponible. 2. Si **no** está: **frená**. En **una sola intervención clara** decile que para guardar learnings necesita conectar `indash` (en Claude Code con `/mcp` → `indash` → login en el browser; en Cowork / claude.ai desde el panel de conectores), y que vos no podés disparar el OAuth por tu cuenta. 3. Si el MCP está conectado pero **la tool `save_learnings` no existe**, el servidor todavía no la expone: decilo y frená igual. No busques un plan B. 4. **Nunca** improvises el guardado: no escribas un `LEARNINGS.md` a mano en el disco, no abras un issue con `gh`, no mandes los learnings por otro medio. Sin la tool, no hay entrega — hay un pedido de conectar. ### Paso 1 — Reconstruir la sesión Trabajo silencioso: releé la conversación de punta a punta antes de hablar. 1. **Qué skills del stack se usaron.** Anotá los nombres **exactos** (los de las carpetas de `skills/`): `ads`, `all-videos`, `carruseles`, `content-brief`, `edicion-ugc`, `email-marketing-ecomm`, `hyperframes`, `new-client`, `stack-overview`, `stories-nano-banana`, `ugc-generator`, `ugc-video-prompts`. Contá solo las que **se ejecutaron** en esta sesión, no las que se mencionaron al pasar. 2. **Qué versión del plugin es.** Leé el campo `version` de `"${CLAUDE_PLUGIN_ROOT}/.claude-plugin/plugin.json"`. Si esa ruta no se resolvió (el cliente no expande `CLAUDE_PLUGIN_ROOT` — pasa fuera de Claude Code) o el archivo no se puede leer: **decilo en una línea** en el borrador y mandá `"unknown"`. **Nunca** inventes ni adivines un número de versión. 3. **Sobre qué marca se trabajó.** La tool resuelve el workspace sola, pero si en la sesión se tocó **más de un cliente**, frená y preguntá para cuál querés guardar. Un `LEARNINGS.md` = un cliente; si hay dos, se corre el comando dos veces. 4. Si **no se usó ninguna skill del stack** y no hay nada aprendido sobre la marca, decilo en una línea (*"esta sesión no dejó learnings para guardar"*) y **terminá acá**. ### Paso 2 — La entrevista (una sola pregunta consolidada) El challenge está en quien corrió la sesión, no en vos: **el "por qué" de un learning lo tiene la persona en la cabeza, no está en el transcript.** Antes de clasificar nada, preguntale — **una sola vez y todo junto**, como en el paso de Decisions de las skills. Nada de una batería de preguntas sueltas. Estructura exacta: ```markdown Antes de redactar nada necesito lo tuyo. Esto es lo que reconstruí: **Qué hiciste**: [1-2 líneas, ya pre-llenadas desde el contexto de la sesión] **Skills que se usaron**: [ads, carruseles] Contestame las cuatro juntas, en el formato que te salga: 1. **¿Está bien lo de arriba?** Si leí algo mal o me falta algo, corregime. 2. **¿Dónde se trabó?** Qué te molestó de la skill, qué tuviste que rehacer, qué te pidió en un orden que no servía, qué no te sirvió. Si la fricción no fue con ninguna skill, decilo y guardamos solo lo del cliente. 3. **¿Qué cambiarías, concretamente?** Un cambio puntual y acotado por cosa (mover un paso, agregar un campo al template, sacar una regla), no "mejorarla en general". 4. **¿Por qué?** Qué te costó eso en la práctica: cuántas veces te pasó, qué tuviste que rehacer, qué salió mal. **Esto lo escribís vos — yo no lo puedo inventar, y sin el "por qué" el learning no se manda.** ``` Reglas de este paso: 1. **El punto 1 lo pre-llenás vos** con lo que reconstruiste en el paso 1: la persona confirma o corrige, no lo escribe de cero. Los puntos 2, 3 y 4 los escribe ella. 2. **El "por qué" lo escribe la persona. No negociable.** Si contesta 2 y 3 pero no 4, se lo volvés a pedir **una vez**, corto y nombrando el learning (*"del cambio del CTA me falta el porqué: ¿qué te costó en la práctica?"*). Si sigue sin venir, ese learning **queda afuera** de `skill_learnings` y lo decís en el borrador. **Nunca** lo rellenás con una inferencia tuya ni con un *"porque genera fricción en el workflow"*. 3. **`$ARGUMENTS` cuenta como primera respuesta.** Si la nota ya trae el antes, el cambio y el porqué, no hay entrevista: confirmalo en una línea y seguí. 4. **Una sola ronda.** Si la respuesta viene desordenada o mezcla cliente y skill, no repreguntes: ordenala vos en el paso 3 y que la persona corrija sobre el borrador. La repregunta se reserva para el "por qué" faltante. 5. Lo que contesta la persona **manda sobre tu lectura del transcript**. Si dice que algo estuvo bien y a vos te había parecido fricción, no es un learning. ### Paso 3 — Separar cliente de skill La pregunta que decide todo, una por learning: > **¿Esto seguiría siendo cierto para otra marca cualquiera que use la misma skill?** > **Sí** → learning **de la skill**. **No** → learning **del cliente**. | | Del cliente (`brand_learnings`) | De la skill (`skill_learnings`) | |---|---|---| | De qué habla | De **esta** marca: su voz, sus reglas, sus productos, qué le funcionó | Del **workflow, los templates, las reglas y los ejemplos** de la skill | | Dónde va | `LEARNINGS.md` del workspace en Indash | Issue privado del equipo de Indash | | Puede nombrar | Todo: marca, producto, personas, precios | **Nada** de eso — va anonimizado | | Ejemplos | *"no usar la palabra 'oferta': la marca la lee como descuento"* · *"el slide 1 sin texto rindió mejor que con headline"* · *"el mejor resultado salió arrancando por el objetivo y dejando el CTA para el final"* | *"la skill pide el CTA antes de saber el objetivo de campaña"* · *"al template de shot list le falta un slot para el disclaimer legal"* · *"la regla 4 contradice a la 7 sobre cuándo versionar"* · *"el ejemplo bueno de la skill usa un modelo de imagen que ya no es el default"* | Los tres `kind` de un learning de cliente: - **`do`** → algo que funcionó y hay que repetir. - **`dont`** → algo que la marca no acepta o que salió mal. - **`context`** → **cómo se llegó** a un buen resultado: el orden de las preguntas, qué referencia sirvió, qué modelo funcionó para este producto. Casos borde (los que más se confunden): 1. **Parece de skill pero es de marca.** *"Nano Banana me rompió el wordmark, hubo que ir a gpt-image"* → si es porque **este** wordmark es finito y se degrada, es del **cliente** (`dont` o `context`). Si es porque la matriz de decisión de la skill manda al modelo equivocado **para cualquier wordmark**, es de la **skill**. 2. **Parece de marca pero es de skill.** *"Tuve que pedirle tres veces la URL del producto"* → si el intake de la skill no la pide explícitamente, es de la **skill**. 3. **Es las dos cosas.** Partilo: la parte universal, anonimizada, a `skill_learnings`; la parte específica, completa, a `brand_learnings`. No mandes el mismo texto a los dos lados. 4. **No es ninguna de las dos.** Errores del MCP, créditos agotados, rate limits, una imagen que tardó, un archivo que no estaba cargado en Indash: son hechos operativos, **no** learnings. No los guardes. Si te parece un bug, decíselo a la persona en el chat para que lo reporte por su cuenta. 5. **Una preferencia dicha al pasar no es un learning** hasta que se aplicó y funcionó. Ante la duda, ofrecelo en el borrador y que la persona decida. Lo que sale de la entrevista y de esta clasificación es **materia prima**: la forma final de los de skill se la das en el paso 4. ### Paso 4 — Redactar los de skill: antes / propongo / por qué Cada learning de skill es **UN cambio concreto y acotado**, escrito en tres campos (más un ejemplo opcional): | Campo | Qué va | La vara | |---|---|---| | `before` (**Antes**) | Qué hace hoy la skill, o qué pasó en la sesión por culpa de eso | Una oración. Describe el estado actual, no lo que te gustaría | | `after` (**Propongo**) | El cambio, concreto y acotado | Una oración accionable: alguien tiene que poder abrirla como PR | | `why` (**Por qué**) | La razón, **en palabras de la persona** (paso 2) | El costo real: cuántas veces pasó, qué hubo que rehacer | | `example?` (**Ejemplo**) | Opcional: el caso concreto, anonimizado | Solo si aclara algo que las tres líneas no dicen | Bueno: > **Antes:** la skill pide el CTA antes del objetivo de campaña. > **Propongo:** pedir el objetivo primero y derivar el CTA de ahí. > **Por qué:** en 3 sesiones tuve que rehacer el CTA después de definir el objetivo. Malo, y por qué: | Malo | Qué tiene mal | |---|---| | *"la skill de ads podría ser mejor en general"* | No es un cambio: nadie sabe qué tocar | | *"Propongo: reescribir la skill"* / *"rehacer el intake"* | No es acotado. Partilo en los cambios puntuales que lo componen | | *"Antes: el intake pide mal las cosas. Propongo: pedir la URL, agregar un campo de disclaimer, mover el CTA y sacar la regla 7"* | Son cuatro learnings disfrazados de uno. Uno por ítem | | *"Por qué: mejoraría el flujo"* | No es un por qué, es un adjetivo — y si lo escribiste vos, no va | | *"Antes: tuve que repetir el brief"*, sin `after` | Es una queja, no una propuesta: falta el cambio | Reglas de este paso: 1. **Un learning = un cambio.** Si al escribir el `after` te salen dos verbos y un "y además", son dos learnings. Partilos. 2. **El `why` sale del paso 2**, textual o parafraseado sin agregarle nada. Si no lo dijo la persona, el learning no se manda (paso 2, regla 2). 3. **El `after` apunta a algo del repo**: un paso del workflow, una regla numerada, un template, un ejemplo. Si no podés nombrar qué archivo tocarías, está demasiado vago para mandarlo. 4. Si el learning lleva `example`, va **anonimizado igual que el resto** (paso 5). 5. Los `brand_learnings` **no cambian de formato**: siguen siendo `kind` + `text`. ### Paso 5 — Anonimizar los de skill Regla: alguien de afuera tiene que poder leer los cuatro campos de un `skill_learnings` (`before`, `after`, `why`, `example`) y el `session_summary` **sin poder deducir de qué cliente salió**. Se aplica a **los cuatro**, no solo al primero: el que más se filtra es el "por qué", porque es donde la persona cuenta el caso real. | Prohibido | Reemplazo | |---|---| | Nombre de la marca, del cliente o de la agencia | *"la marca"* | | Nombre o SKU del producto | *"el producto"* | | Nombres de personas (cliente, equipo, creador, influencer) | *"el cliente"*, *"el equipo"* | | URLs, dominios, handles de IG/TikTok, IDs de workspace | sacarlos; si importa **qué** era, *"la URL de producto"* | | Números de negocio: precios, ventas, presupuestos, ROAS, ticket, stock | sacarlos, o *"un precio"* / *"el presupuesto"* | | Nombres internos de campaña y fechas de lanzamiento | *"una campaña de promo"* | | Copy textual de la marca | parafraseado, o *"el claim principal"* | La **categoría / vertical** se puede mencionar **solo si el learning no se entiende sin ella** (*"en un ecommerce de suplementos el packshot trae el label con claims que el modelo reescribe"*). Si el learning funciona igual sin la categoría, sacala. Ejemplo: - Crudo: *"Para Acme Foods, el carrusel del Multivitamínico X a $18.900 quedó mal porque el paso 3 pidió el CTA antes del objetivo, y Sofi me lo hizo rehacer dos veces."* - Anonimizado: - **Antes:** la skill pide el CTA en el paso 3, antes de definir el objetivo de campaña. - **Propongo:** mover el CTA al paso de Decisions, después del objetivo. - **Por qué:** hubo que rehacer el copy dos veces en la misma entrega. Antes de mostrar el borrador, **pasada final**: releé **campo por campo** (`before`, `after`, `why`, `example`) cada `skill_learnings`, y también el `session_summary`, buscando las siete filas de la tabla. Si algo identifica al cliente, no está anonimizado — reescribilo. ### Paso 6 — Borrador + confirmación explícita (el gate) Mostrá el borrador **completo**, con el contenido exacto que se va a mandar, en dos bloques numerados. Nada de resúmenes ni de "y algunas cosas más". ``` 📋 Borrador — nada se mandó todavía Plugin 0.12.0 · Skills usadas: ads, carruseles · Workspace: ── CLIENTE → LEARNINGS.md del workspace (queda con nombre y apellido) ── 1. [DON'T · ads] No usar la palabra "oferta": la marca la lee como descuento. 2. [DO · carruseles] El slide 1 sin texto rindió mejor que con headline. 3. [Contexto] El mejor resultado salió arrancando por el objetivo y dejando el CTA para el final. ── SKILL → issue privado del equipo (anonimizado) ── 1. [ads] Antes: la skill pide el CTA en el paso 3, antes de definir el objetivo de campaña. Propongo: mover el CTA al paso de Decisions, después del objetivo. Por qué: en 3 sesiones hubo que rehacer el copy después de definir el objetivo. 2. [carruseles] Antes: el template de shot list no tiene dónde poner el disclaimer legal. Propongo: agregarle al template una fila fija de disclaimer. Por qué: se agregó a mano en las últimas dos entregas y una salió sin él. Queda afuera: [ads] "el intake se hace largo" — no me diste el por qué, y sin eso no se manda. Resumen de sesión (anonimizado, va al issue): Se produjeron ads y un carrusel para una marca DTC; el ida y vuelta más caro fue el orden de las preguntas del intake. ``` Y cerrá con **una sola pregunta consolidada**: > ¿Lo mando así? Podés: **confirmar** · **sacar el N** · **editar el N** · > **pasar el N al otro bloque** · **mandar solo un bloque** · **no mandar nada**. Reglas de este paso: 1. **Esperás una confirmación explícita.** *"dale"*, *"ok"*, *"mandá"* valen. El silencio, un *"gracias"* o seguir con otro tema **no** valen. 2. Si edita, **volvés a mostrar el borrador corregido** y volvés a pedir confirmación. Cada ronda de edición reabre el gate. 3. Si confirma **un solo bloque**, mandás ese y el otro va como array vacío. 4. Si dice que no, no llamás la tool y cerrás sin drama. 5. Si los dos bloques quedan vacíos, **no llamás la tool**: decilo y terminá. 6. La línea **Queda afuera** aparece solo si dejaste algo fuera por falta de "por qué" (paso 2, regla 2). Si la persona lo completa ahí, el learning entra y volvés a mostrar el borrador. ### Paso 7 — Llamar a `save_learnings` Recién ahora. El input, con los tipos exactos: ```ts { plugin_version: string; // "0.12.0" del manifiesto, o "unknown" skills_used: string[]; // ["ads", "carruseles"] — nombres exactos de carpeta brand_learnings: Array<{ skill?: string; // la skill donde surgió; omitilo si no aplica kind: "do" | "dont" | "context"; text: string; }>; skill_learnings: Array<{ skill: string; // obligatorio, nombre exacto de carpeta before: string; // "Antes": qué hace hoy la skill — YA anonimizado after: string; // "Propongo": el cambio, concreto y acotado why: string; // "Por qué": la razón, en palabras de la persona example?: string; // opcional, anonimizado }>; session_summary?: string; // 1-3 líneas, anonimizado } ``` 1. `kind` es **solo** uno de esos tres literales, en minúscula. `"DON'T"` no es un valor válido: el bullet lo formatea la tool. 2. En `brand_learnings`, `skill` es opcional: si no aplica, **omitilo** — no mandes `""` ni `null`. 3. En `skill_learnings`, `skill` es **obligatorio** y tiene que ser el nombre exacto de una carpeta de `skills/`. Si un learning no pertenece a ninguna skill concreta, no es un learning de skill. 4. En `skill_learnings`, `before`, `after` y `why` son **los tres obligatorios** y ninguno va vacío. Van **sin** los prefijos "Antes:" / "Propongo:" / "Por qué:" — eso lo formatea la tool. `example` se omite si no hay: no mandes `""`. 5. `session_summary`: 1-3 líneas, anonimizado con la misma vara del paso 5. Omitilo si no aporta. 6. Mandá **exactamente** lo confirmado. Ni un ítem que la persona sacó, ni una coma que no leyó. 7. Una sola llamada por corrida. La tool es append-only: no le pidas reescribir ni corregir entradas viejas. ### Paso 8 — Reportar y cerrar El output es: ```ts { learnings_file_path: "LEARNINGS.md" | null; // null si no hubo brand_learnings issue_url: string | null; // null si no hubo skill_learnings } ``` Reportá en dos o tres líneas, con lo que **la tool devolvió**: - `learnings_file_path` con valor → *"Learnings del cliente guardados en `LEARNINGS.md` del workspace."* Si viene `null` → *"No había learnings de cliente, así que no se tocó el `LEARNINGS.md`."* - `issue_url` con valor → pegá **la URL tal cual**. Si viene `null` → *"No se abrió issue: no había learnings de skill."* **Nunca** inventes un path ni una URL, ni des por hecho un resultado que no viniste a leer. Si la tool devuelve error, mostrá el mensaje tal cual, decí que **no se guardó nada**, y no reintentes en loop. Después del reporte, **cerrá**. No preguntes *"¿algo más?"*. --- ## Reglas no-negociables 1. **Nunca** llamás a `save_learnings` sin la confirmación explícita del paso 6. Ni "para ahorrar tiempo", ni porque el borrador parezca obvio. 2. **Nunca** escribís vos el `why` de un learning de skill. Lo dice la persona en la entrevista o el learning queda afuera. Una inferencia tuya no es un "por qué". 3. **Nunca** entra un dato del cliente en `skill_learnings` ni en `session_summary`: ni marca, ni producto, ni personas, ni URLs, ni handles, ni números de negocio. 4. **Nunca** inventás learnings para llenar el borrador. Si no hay, se dice y se termina. 5. **Nunca** escribís el `LEARNINGS.md` a mano ni abrís un issue por otro medio. Todo pasa por la tool; sin tool, no hay guardado. 6. **Siempre** aplicás el gate del MCP `indash` en el paso 0 antes de cualquier otra cosa. 7. **Siempre** hacés la entrevista del paso 2 antes de redactar, en **una sola pregunta consolidada** — no una batería de preguntas sueltas, y nunca después de haber armado el borrador. 8. **Siempre** un learning de skill es **un cambio concreto y acotado** en formato antes / propongo / por qué. Nunca "reescribir la skill" ni cuatro cambios en un ítem. 9. **Siempre** la `plugin_version` sale del manifiesto o es `"unknown"`. Nunca adivinada. 10. **Siempre** los nombres de skill son los **exactos** de las carpetas de `skills/`. 11. **Siempre** una corrida = un cliente. Si la sesión tocó dos marcas, preguntás cuál y se corre de nuevo para la otra. 12. **Siempre** mostrás el borrador **completo** — el texto exacto que se manda, no un resumen. 13. **Agnóstico** por marca, vertical y categoría: un learning de skill que solo aplica a un rubro sin decir por qué, no es un learning de skill. ## Punto de entrada Arrancá por el **paso 0 (gate del conector `indash`)**. Todo lo demás va después.