Cómo armar una skill de Claude sin que invente datos

En pocas palabras: Con call-notes-to-actions, una skill gratuita y MIT publicada el 14 de septiembre de 2026, Claude convierte notas de reuniones en tablas de acciones y emails de seguimiento usando solo un archivo SKILL.md de menos de 100 líneas, sin código de por medio.

Un desarrollador de FairdraftStudio publicó el 14 de septiembre de 2026 una skill de Claude gratuita y con licencia MIT llamada call-notes-to-actions: un archivo SKILL.md de menos de 100 líneas de Markdown que convierte notas de reuniones en tablas de acciones y emails de seguimiento, sin una sola línea de código de por medio.

Una skill de Claude es una carpeta con un archivo SKILL.md: frontmatter YAML con los campos name y description, más instrucciones en Markdown plano. No tiene código, dependencias ni llamadas a API. Claude lee esas instrucciones y las sigue cuando el pedido del usuario coincide con la descripción. Es la forma más liviana de darle a Claude un procedimiento fijo para una tarea repetitiva.

¿Qué es una skill de Claude y cómo funciona el archivo SKILL.md?

Una skill de Claude arranca y termina en un archivo de texto. No hay backend, no hay instalación de paquetes, no hay tokens de API que gestionar. El frontmatter de call-notes-to-actions es literal así:

name: call-notes-to-actions
description: "Turns a meeting transcript, call recording notes, or rough meeting notes into a crisp summary with decisions, an action-item table (owner, action, due date), open questions, risks, and a ready-to-send follow-up email. Use when someone asks to summarize a call or meeting, extract action items, write meeting minutes, or draft a follow-up email after a client call." Esto se conecta con lo que analizamos en si todavía no conocés bien la herramienta.

Ese campo description es lo único que Claude usa para decidir si la skill aplica a un pedido. El autor lo dice sin vueltas en su artículo: una descripción prolija tipo “convierte notas en action items” es correcta, pero comparte poco vocabulario con lo que la gente realmente tipea. Por eso la descripción nombra los inputs (transcript, notas de llamada, apuntes sueltos), los outputs (resumen, decisiones, tabla, email) y una cláusula explícita de “usar cuando…” que lista los pedidos típicos.

El ejercicio que propone es simple: escribir cinco formas distintas de pedir la skill y chequear que cada una comparta palabras con la descripción. Instrucciones que nunca se cargan no sirven para nada.

¿Qué reglas usa la skill para no inventar decisiones ni fechas?

La skill tiene cuatro reglas cortas contra la alucinación, y son la parte más reutilizable de todo el diseño. Primera: extraer solo lo que se dijo, sin decisiones, owners ni fechas inventadas. Segunda: si un owner o una fecha están implícitos pero nunca se dijeron explícitamente, la skill los completa igual pero les agrega la etiqueta (proposed), así el lector ve exactamente qué es inferencia y qué no.

Tercera regla: las vaguedades típicas de una reunión (“habría que ver eso”) se convierten en items de acción con owner TBD en lugar de desaparecer del resumen. Cuarta: decisiones y preguntas abiertas van separadas, porque sin esa línea divisoria los puntos ambiguos terminan en la lista de decisiones, donde parecen algo cerrado cuando no lo son.

Ojo con las fechas relativas. “El viernes que viene” es una trampa clásica en cualquier flujo con modelos de lenguaje. La skill convierte esas fechas usando la fecha de la reunión, o la de hoy si no hay fecha de reunión, y deja esa conversión anotada en un bloque aparte para que se pueda verificar antes de mandar nada. Relacionado: para elegir el modelo más adecuado a tu caso.

¿Cómo es el formato de salida fijo de la skill?

El output no es libre: está especificado línea por línea en el SKILL.md. Fijate qué incluye cada corrida:

• Resumen de máximo 3 bullets. Nada de párrafos largos arriba de todo.
• Decisiones numeradas. Solo lo que quedó acordado, con timestamp si el transcript lo tiene.
• Tabla de acciones con columnas owner | action | due | status.
• Preguntas abiertas y riesgos separados de las decisiones.
• Email de seguimiento armado desde la misma tabla, bajo los encabezados “Acordamos / Voy a / ¿Podrías / Sigue abierto”.
• Bloque “To confirm” para borrar antes de enviar el email, con las fechas inferidas marcadas ahí.

Un formato fijo tiene dos ventajas concretas. La salida se puede escanear siempre de la misma manera, y los huecos se vuelven visibles: una celda de owner vacía salta a la vista, mientras que ese mismo hueco escondido en un párrafo pasa desapercibido. Como el email sale de la misma tabla que el resumen, no pueden contradecirse entre sí, que es justo el error típico cuando alguien escribe el recap a mano después de la reunión.

¿Cómo probar la skill call-notes-to-actions en Claude Code y en la app?

Hay tres caminos de instalación, según el repositorio en GitHub: el plugin recomendado en Claude Code, la carga manual del zip en la app, o copiar la carpeta a mano. Los tres terminan en el mismo lugar: la skill disponible para usarse.

Método	Dónde se hace	Pasos clave
Claude Code (plugin)	Terminal	/plugin marketplace add FairdraftStudio/call-notes-to-actions-skill y luego /plugin install call-notes-to-actions@fairdraft-studio
Claude app (web o desktop)	Settings > Capabilities	Activar “Code execution and file creation”, después Customize > Skills > Upload skill y elegir call-notes-to-actions.zip
Manual	Carpeta local	Copiar plugins/call-notes-to-actions/skills/call-notes-to-actions a ~/.claude/skills/ y reiniciar Claude Code

Una vez instalada, alcanza con pegar un transcript y pedir “resumí esta llamada y armame el email de seguimiento”. El repo trae un ejemplo real con input y output, así que no hace falta probar en blanco.

¿Qué límites tiene este enfoque de skills para notas de reuniones?

El checklist de autoverificación que corre la skill antes de responder no es una garantía. Chequea que cada item tenga verbo y owner, que nada aparezca sin respaldo en las notas, que las fechas relativas estén convertidas y que el email coincida con la tabla. Pero sigue siendo el mismo modelo revisando su propio trabajo. En otra skill que simplifica tareas repetitivas profundizamos sobre esto.

¿Alguien lo verificó de forma independiente? El propio autor no lo dice así, pero es honesto al respecto: recomienda leer el resultado antes de mandarlo, no confiar a ciegas en el checklist. Ese matiz vale para cualquier skill que uses, no solo para esta.

¿Qué está confirmado y qué no sobre esta skill?

Está confirmado en las fuentes: el SKILL.md tiene menos de 100 líneas, es MIT, es gratis, y el repositorio incluye un ejemplo real de input y output. También están confirmados los comandos de instalación en Claude Code y los pasos en la app web.

No está confirmado ni medido en ninguna fuente: cuánta gente la instaló, si Anthropic la recomienda de alguna forma (el repo aclara que no hay afiliación ni endorsement), y si el checklist de autoverificación reduce errores de forma medible frente a un resumen escrito a mano. Tomalo como una herramienta útil con evidencia de diseño, no como un producto con métricas de adopción publicadas. Mirá también un caso donde la integración quedó incompleta.

Errores comunes al armar una skill de Claude para reuniones

• Escribir una description genérica. Si dice apenas “resume reuniones”, Claude no la activa con pedidos como “armame el follow-up del call de hoy”. Hay que nombrar inputs, outputs y la cláusula “usar cuando…”.
• Confiar en el checklist como si fuera una revisión externa. Es el mismo modelo chequeándose a sí mismo, así que conviene leer el resultado igual antes de mandarlo.
• No definir de qué fecha parten las conversiones relativas. Sin esa regla, “el viernes que viene” puede terminar siendo cualquier viernes.
• Mandar el email sin borrar el bloque “To confirm”. Ese bloque existe justamente para que las inferencias no lleguen al cliente disfrazadas de hechos.

Preguntas Frecuentes

¿Qué es una skill de Claude?

Es una carpeta con un archivo SKILL.md que tiene frontmatter YAML (name y description) más instrucciones en Markdown. No lleva código ni dependencias: Claude las sigue cuando el pedido del usuario coincide con la descripción de la skill. Sobre eso hablamos en para automatizar el flujo sin usar una API key propia.

¿Cómo se crea un archivo SKILL.md?

Se arranca con un bloque YAML entre tres guiones que define name y description, y después se escriben las instrucciones en Markdown normal: reglas, formato de salida esperado y, si hace falta, un checklist de autoverificación. No requiere ningún lenguaje de programación.

¿Cómo evito que la IA invente decisiones en un resumen de reunión?

Agregando reglas explícitas en el SKILL.md: extraer solo lo dicho, marcar inferencias con una etiqueta como “(proposed)” y usar un owner tipo “TBD” para las ideas vagas en vez de omitirlas. Separar decisiones de preguntas abiertas también ayuda a que nada ambiguo pase por acordado.

¿Cómo instalo una skill en Claude Code?

Con dos comandos en la terminal: /plugin marketplace add [usuario]/[repo] para agregar el marketplace, y /plugin install [nombre-skill]@[marketplace] para instalarla. En el caso de call-notes-to-actions son /plugin marketplace add FairdraftStudio/call-notes-to-actions-skill y /plugin install call-notes-to-actions@fairdraft-studio.

¿Qué diferencia hay entre una skill y un plugin en Claude?

La skill es el archivo SKILL.md con las instrucciones puntuales para una tarea. El plugin es el mecanismo de distribución e instalación: agrupa una o más skills (y potencialmente otros componentes) para que se instalen juntos desde un marketplace con los comandos /plugin, según se ve en el propio repositorio de call-notes-to-actions.

Conclusión

Lo que cambia acá no es la tecnología, es el enfoque: en vez de pedirle a Claude que resuma una reunión y cruzar los dedos, alguien se sentó a escribir reglas explícitas contra la invención de datos y las empaquetó en un archivo de texto que cualquiera puede instalar en minutos. Subís el transcript, Claude lo procesa con esas reglas puestas, te devuelve la tabla y el email, vos revisás el bloque “To confirm” antes de mandar nada, y ahí es donde entra tu criterio, no antes.

Si laburás con clientes y hacés este mismo admin después de cada call, probar call-notes-to-actions te lleva diez minutos y no cuesta nada. Si armás tus propias skills, las cuatro reglas anti-invención y el checklist de autoverificación de este proyecto son un buen punto de partida, más allá de si terminás usando exactamente esta skill o no.

Fuentes

• How I designed a Claude skill that turns call notes into action items – dev.to, publicación original del autor sobre el diseño de la skill
• Repositorio call-notes-to-actions-skill en GitHub – código MIT, instrucciones de instalación y ejemplo de input/output