Skill de notas de reunión: de la transcripción a tareas con responsable y fecha

Todo equipo sufre la misma fuga silenciosa: se toma una decisión en una llamada, tres personas la recuerdan de tres formas distintas y la única tarea que importaba nunca termina en un gestor. Un skill de notas de reunión sella esa fuga tratando la transcripción como materia prima de la cual extraer, no como texto que resumir. Al terminar esta guía vas a tener un skill de Claude Code, pequeño y reutilizable, que convierte una transcripción en decisiones, tareas con responsable y fecha, y preguntas abiertas; y de paso vas a saber dónde falla y cómo mantenerlo honesto.

01 · Qué hace y qué deja fuera a propósito

Un skill es una capacidad empaquetada que invocas cuando la necesitas, en lugar de pegar las mismas instrucciones una y otra vez. Este tiene una sola tarea: leer una transcripción o un montón de apuntes desordenados y devolver un registro estructurado. La estructura lo es todo.

Produce exactamente tres cosas:

• Decisiones: lo que de verdad se acordó, planteado como un hecho, no como una discusión.
• Tareas: cada una con responsable y fecha, en formato de lista.
• Preguntas abiertas: todo lo que salió pero quedó sin resolver, para que no se pierda en silencio.

Todo lo demás (la conversación de pasillo, los desvíos, el "bueno, ¿en qué estábamos?") se bota a propósito. Esa es la diferencia entre un resumen y una extracción. Un resumen lo ojeas una vez y lo olvidas. Una lista de "quién debe qué y para cuándo" la puedes accionar mañana mismo.

02 · Cuándo debe dispararse

El momento en que lo corres importa más de lo que uno cree. Córrelo apenas termina la llamada, con la transcripción fresca y mientras todavía recuerdas cómo estuvo la reunión. Dos días después vas a estar reconstruyendo lo que se quiso decir de memoria, que es justo la falla que este skill existe para evitar.

Buenos momentos para invocarlo:

1. Apenas termina un standup, una llamada con un cliente o una sesión de planning, con la transcripción recién pegada.
2. Cuando tienes un muro de apuntes que escribiste durante la llamada y necesitas convertirlos en próximos pasos.
3. Cuando alguien pregunta "¿qué decidimos?" y la respuesta honesta es una transcripción de 4,000 palabras que nadie va a leer.

Sáltalo cuando no haya nada que extraer. Una reunión puramente informativa, sin decisiones ni tareas, no necesita este skill. Necesita un "FYI, nada que accionar" de una sola línea. Forzar una estructura sobre una reunión que no la tuvo solo fabrica tareas falsas, y una tarea falsa es peor que ninguna.

03 · Cómo funciona por dentro

Un skill de Claude Code es, en su forma más simple, un archivo Markdown con frontmatter YAML que el agente carga cuando la description calza con lo que estás haciendo. No hay magia en el runtime. Toda la fuerza está en las instrucciones y en la forma fija de la salida.

El mecanismo son tres pasos, uno detrás del otro:

1. Leer la fuente tal cual. El modelo procesa la transcripción como viene. Todavía no parafrasea nada.
2. Clasificar cada línea en una caja: decisión, tarea, pregunta abierta o ruido. El ruido es la caja más grande, y se bota.
3. Emitir la plantilla fija. Como la forma nunca cambia, las herramientas que vienen después (un gestor, un pegado en Notion, un grep) pueden confiar en ella.

La definición del skill

Aquí va un SKILL.md mínimo pero completo. Fíjate en la línea de description: es lo que hace que el skill se dispare con el tipo correcto de request.

---
name: meeting-notes
description: Extrae decisiones, tareas con dueño y preguntas abiertas de una transcripción o apuntes de reunión. Dispara después de una llamada.
---

Dada una transcripción o apuntes sueltos, produce SOLO esta estructura:

## Decisiones
- <lo que se decidió, como afirmación de hecho>

## Tareas
- [ ] <tarea> — responsable: <nombre> — fecha: <YYYY-MM-DD>

## Preguntas abiertas
- <salió pero quedó sin resolver>

Reglas:
- Descarta la charla, los desvíos y el contexto repetido.
- Toda tarea DEBE tener responsable y fecha.
- Sin responsable claro, escribe "responsable: SIN ASIGNAR". Nunca adivines un nombre.
- Sin fecha dicha, escribe "fecha: PENDIENTE". Nunca inventes una.
- No agregues comentarios fuera de las tres secciones.

Las reglas de «responsable: SIN ASIGNAR» y «fecha: PENDIENTE» no son adorno. Son la válvula de seguridad que evita que el skill invente responsabilidades, que es lo más peligroso que podría hacer.

Por qué importa fijar la forma

Cuando la plantilla de salida es idéntica cada vez, las tareas se convierten en una lista que pegas directo en tu gestor y nada se queda en el tintero, porque el formato obliga, sí o sí, a poner responsable y fecha en cada línea. Una tarea sin responsable salta a la vista como SIN ASIGNAR, en vez de esconderse como un bullet pulido que parece resuelto.

04 · Un ejemplo concreto

Supongamos que pegas un pedazo desordenado de transcripción:

Ana: ok, entonces el contrato del API, yo creo que vamos con paginación por cursor.
Marco: sí, de acuerdo, offset nos va a doler cuando escalemos.
Ana: dale. alguien tiene que actualizar el spec de OpenAPI... ¿Marco, puedes?
Marco: claro, lo tengo para el viernes.
Ana: y todavía no sabemos si el equipo de mobile necesita el endpoint viejo.
Marco: cierto, no hay nadie de mobile aquí. dejémoslo marcado.
Ana: ah, y deberíamos quizás tal vez revisar los rate limits en algún momento.

Le dices al skill que la reunión fue el martes 2026-05-12, así que "para el viernes" significa 2026-05-15. Devuelve:

## Decisiones
- El API usará paginación por cursor en lugar de offset.

## Tareas
- [ ] Actualizar el spec de OpenAPI para paginación por cursor — responsable: Marco — fecha: 2026-05-15
- [ ] Decidir si se revisan los rate limits — responsable: SIN ASIGNAR — fecha: PENDIENTE

## Preguntas abiertas
- ¿El equipo de mobile todavía necesita el endpoint viejo? (no había nadie de mobile)

Fíjate en lo que pasó. "¿Marco, puedes?" más "lo tengo para el viernes" se convirtió en una tarea con responsable y fecha. El vago "deberíamos quizás tal vez revisar los rate limits" se convirtió en una tarea real pero SIN ASIGNAR / PENDIENTE, sacada a la luz en vez de descartada o asignada a la ligera. Y la pregunta sin resolver de mobile fue a parar a preguntas abiertas, en lugar de quedar disimulada.

05 · Configuración y personalización

El skill es un solo archivo, así que ajustarlo es tan simple como editar las instrucciones. Las perillas que vale la pena mover:

• Idioma de salida. Agrega una línea como "responde en el mismo idioma de la transcripción" para que una llamada en español genere notas en español.
• Formato de fecha. El formato ISO (YYYY-MM-DD) se ordena y se parsea sin problemas. Déjalo así, y no dejes que derive a algo como "el próximo martes".
• Campos del gestor. Si tu gestor usa etiquetas o prioridades, extiende la línea de la tarea. Por ejemplo, agrega un campo de prioridad, pero solo cuando la transcripción mencione una prioridad de verdad.
• Lista de responsables. Para equipos fijos, pega el roster en el prompt para que los nombres se normalicen ("Marco" y "Marcos" no terminen siendo dos personas).

06 · Trampas y límites honestos

Las transcripciones son ruidosas y la gente matiza todo el tiempo: "deberíamos quizás tal vez en algún momento". El comportamiento más importante del skill es cómo maneja la ambigüedad.

• Nunca adivines un responsable. Una tarea asignada a la persona equivocada es peor que una marcada sin responsable, porque nadie revisa las que parecen hechas. La tarea mal asignada se pudre en silencio. La SIN ASIGNAR levanta una pregunta en el próximo standup.
• Nunca inventes una fecha. Un deadline equivocado, pero dicho con seguridad, es una trampa. PENDIENTE es honesto e invita a darle seguimiento.
• No puede leer una intención que la transcripción no contiene. Si una decisión se tomó con un gesto de cabeza y un "ajá", el modelo puede pasarla por alto. Repasa la salida una vez. El skill es un multiplicador de tu atención, no un reemplazo.
• Audio malo, transcripción mala, extracción mala. Una transcripción enredada se propaga tal cual. Si los nombres salen mal, corrígelos en la fuente o en el roster. No confíes en que la salida los arregle.

Esta es la misma disciplina en la que me apoyo en proyectos más complejos, como el trabajo de deliberación en ThinkTank AI: el modelo es más útil cuando es explícito sobre lo que no sabe, y más peligroso cuando tapa un hueco con una suposición dicha con seguridad. Un skill de notas de reunión es un terreno pequeño y seguro para agarrar ese hábito.

Empieza con el SKILL.md de arriba, córrelo en tu próxima llamada y compara las primeras salidas con lo que recuerdas. En un par de reuniones vas a confiar en la forma, vas a dejar de reescribir notas a mano y vas a notar que se caen menos tareas en silencio, que era de lo que se trataba todo esto.