Cook-First Skills: primero cocinas con tu agente, luego escribes la skill

Nadie escribe una receta antes de haber cocinado el plato.

Pues con las skills de agentes de IA lo hacemos constantemente. Instalamos la receta de otra persona sin haber pisado su cocina, o nos sentamos a escribir un SKILL.md imaginando cómo debería salir algo que todavía no hemos hecho nunca.

Quiero proponer otra forma de trabajar. La llamo Cook-First Skills:

🔑 Cook-First Skills: una skill no se diseña, se cocina. Primero resuelves la tarea con tu agente, después escribes la skill a partir de lo que ha pasado en esa sesión, y solo la das por buena cuando la has vuelto a cocinar en una segunda sesión real.

Esa última parte es la que más importa, y tiene nombre propio: la regla de la segunda sesión. Una skill que no se ha usado en una segunda sesión real no está validada. Está escrita, que no es lo mismo.

En este artículo vas a encontrar:

• Qué es Cook-First Skills y por qué va a contracorriente de los catálogos de skills
• La regla de la segunda sesión y por qué es la única validación que de verdad importa
• El ciclo de trabajo: destila, repite, refina
• Por qué el campo description es un disparador y no una descripción
• Ejemplos reales, dentro y fuera del código

¿Qué es Cook-First Skills? ¶

Cook-First Skills es una forma de trabajar con agentes de IA en la que las skills nacen de sesiones de trabajo reales, se validan repitiendo la tarea y se refinan corrigiéndolas a ellas, no solo a la salida.

Da igual el agente: Claude Code, Codex, OpenCode, Pi, Cursor, Antigravity. Y da igual el tipo de tarea. Puede ser una batería de tests, un módulo o una sección de la web. Pero también una presentación de diapositivas, un montaje de vídeo, unas facturas o la conciliación de un extracto bancario.

Todas esas sesiones siguen el mismo patrón:

1. Le pides al agente una tarea concreta.
2. Hay idas y venidas: le corriges, le das contexto, descubrís juntos qué funciona.
3. La tarea sale bien.
4. Sabes que vas a tener que volver a hacerla.

En el punto 4 la mayoría cerramos la sesión y nos olvidamos. Dentro de dos semanas tocará explicárselo todo otra vez. Cook-First Skills propone aprovechar ese momento para escribir la skill:

Crea una skill a partir de lo que hemos hecho en esta sesión.
Recoge los pasos que han funcionado, las correcciones que te he hecho
y el formato de salida que hemos acordado. Usa skill-creator.

Hasta aquí, nada que no haga ya mucha gente. En el minicurso de skills lo llamé SDSD, Session-Driven Skill Development: tienes la conversación una vez y le pides a skill-creator que la convierta en skill. Cook-First es ese mismo gesto llevado al siguiente nivel, con un ciclo completo y una regla para saber cuándo una skill está de verdad validada.

Lo que convierte esto en un método es lo que viene después.

¿Qué es la regla de la segunda sesión? ¶

Una skill no está validada hasta que la has usado en una segunda sesión real.

Parece obvio, pero va contra la intuición de casi todo el mundo. Cuando el agente te genera un SKILL.md limpio, bien estructurado y con buena pinta, la tentación es darlo por terminado. Incluso le pides que lo revise y te dice que está estupendo.

Eso no valida nada. Es como leer una receta y decir que el plato está bueno.

La segunda sesión es la que te dice la verdad, porque la tarea nunca se repite exactamente igual. Otro fichero, otro cliente, otra fecha, otro matiz. Ahí descubres si la skill captura el oficio o solo captura aquel día concreto.

💡 Si solo te llevas una cosa de este artículo: la validación de una skill no es que esté bien escrita. Es que vuelvas a hacer la tarea y tengas que corregir al agente menos que la vez anterior.

Hay un corolario que me parece igual de importante: cuando corrijas al agente en esa segunda sesión, corrige la receta, no solo el plato. Si arreglas la salida y sigues adelante, la próxima vez cometerá el mismo error. Si arreglas la skill, no.

¿Por qué cocinar primero y no instalar recetas de otros? ¶

Porque una receta ajena puede ser excelente y aun así no ser la tuya.

Las skills de catálogo están escritas para la cocina de otra persona: sus herramientas, sus manías, sus convenciones. Las skills diseñadas desde cero tienen otro problema: describen cómo crees que se hace la tarea, no cómo la has hecho.

Es la diferencia entre conocimiento a priori y a posteriori. Las dos primeras son recetas a priori. Cook-First produce recetas a posteriori: nacen de la experiencia y se corrigen con ella.

No te digo que dejes de instalar skills de otros. Te digo que las mejores skills que vas a tener son las que salen de tu propia cocina. Y que una skill ajena también puedes hacerla tuya con este mismo ciclo: úsala en una sesión real, corrige, y reescríbela.

Lo curioso es que la propia skill-creator de Anthropic ya contempla este camino. En su fase de captura de intención prevé que la conversación en curso ya contenga el flujo que quieres capturar, y en ese caso indica que hay que extraer primero de ahí las herramientas usadas, la secuencia de pasos y las correcciones del usuario. Cook-First no inventa la técnica: la convierte en hábito y le pone una regla de validación.

¿Cómo encaja con Spec-Driven Development? ¶

Si sigues Web Reactiva sabes que le dedico mucho tiempo a SDD. Y te preguntarás si esto lo contradice. Al revés: se complementan porque miran en direcciones opuestas.

• La spec es el menú. Se escribe antes de que el agente trabaje y define qué tiene que salir de la cocina esta vez.
• La skill es la receta. Se escribe después de que el agente haya trabajado y captura cómo se hace para la próxima vez.

Una es prospectiva y la otra retrospectiva. De hecho, muchas de las skills que uso para trabajar con specs nacieron de sesiones en las que estaba escribiendo specs.

¿Cuál es el ciclo de Cook-First Skills? ¶

El ciclo tiene tres verbos: destila, repite, refina. Destilar ocurre en la primera sesión; repetir y refinar, en todas las siguientes.

Destila: escribe la skill al terminar de cocinar ¶

Resuelve el problema sin pensar en la skill. No intentes que la sesión “quede bonita”: lo valioso son los tropiezos y las correcciones, porque son justo lo que el agente no sabía hacer solo.

Al terminar, pídele que escriba la skill. Ayuda mucho tener instalada skill-creator o cualquier skill que sepa crear skills. No es imprescindible, pero conoce la anatomía del SKILL.md, la carga progresiva y los errores típicos.

Un truco que me funciona: antes de pedirle una skill concreta, pregúntale qué skills ve en la conversación. A veces encuentra patrones que tú ni habías verbalizado.

En este paso decides también dónde vive la receta:

• A nivel de proyecto, versionada con el código, si el conocimiento es de ese proyecto: cómo se despliega esta app, cómo se organizan estos tests.
• A nivel de usuario, disponible en todos tus proyectos, si el conocimiento es tuyo: cómo te gusta revisar un PR, cómo planificas tu semana.

Repite: aplica la regla de la segunda sesión ¶

La siguiente vez que toque esa tarea, hazla con la skill cargada. No releas la skill para ver si “está bien”. Úsala y observa dónde tienes que corregir al agente.

Esas correcciones son oro. Te dicen exactamente qué le falta a la receta.

Refina: corrige la receta, no solo el plato ¶

Cuando tengas que corregir, pídele al propio agente que actualice la skill:

Hemos usado la skill pending-work y he tenido que corregirte dos veces:
no quiero ver las tareas etiquetadas como "algún día" y quiero el
nombre del proyecto delante de cada tarea. Actualiza la skill para que
la próxima vez no pase.

Los ficheros Markdown no están escritos en piedra. Cada sesión real es una iteración: la receta se va ajustando a tu cocina, una anotación detrás de otra.

¿Y cuándo partir una skill en varias? ¶

A veces una sesión no da para una receta, da para varias. Igual que un sofrito acaba siendo la base de diez platos distintos, una parte de una skill puede acabar mereciendo vida propia.

Decidir cómo fragmentar una skill en responsabilidades diferentes es una decisión de ingeniería, como decidir cuándo partir una clase en dos. Mi consejo: divide cuando duela, no antes. Cuando la skill se haga pesada o cuando veas que una parte se reutiliza en otro contexto. Fragmentar antes de repetir es diseñar para casos imaginarios.

¿Por qué el campo description es un disparador y no una descripción? ¶

Este es el punto técnico donde más skills fallan.

El campo description del frontmatter no está ahí para describir la skill. Está ahí para que el agente sepa cuándo invocarla. Es lo que te permite no escribir siempre /nombre-de-la-skill y decir simplemente “quiero hacer tal cosa”, y que esa “tal cosa” sea la repetición de lo que ya hiciste otro día.

La documentación de skill-creator lo deja claro: la description es el mecanismo principal de activación, y como los modelos tienden a quedarse cortos invocando skills, recomiendan escribirla un poco “insistente”.

Cook-First te da una ventaja enorme aquí: tienes la frase exacta con la que empezaste la sesión. Si la sesión arrancó con “¿qué tengo pendiente hoy?”, esa frase tiene que estar en la description.

---
name: pending-work
description: Review my pending work in the task manager and summarize what needs attention. Use this whenever I ask "qué tengo pendiente", "qué me toca hoy", "what's on my plate" or want to plan my day, even if I don't mention the task manager by name.
---

# Pending work

1. Fetch open tasks from the task manager, "Web Reactiva" project first.
2. Group them: overdue, due today, this week, no date.
3. Flag tasks untouched for more than 14 days.
4. Output a short list (max 10 items), most urgent first.

## Margin notes

<!-- Anotaciones al margen: crecen con cada sesión real en la que corriges al agente -->
- Skip tasks tagged "someday".
- Show the project name before each task.

Fíjate en la última sección. No es obligatoria, pero es el patrón Cook-First por excelencia: las notas al margen de la receta. Como esas recetas de la familia con anotaciones a boli (“menos sal”, “mejor 10 minutos más”). Hacen visible cómo ha evolucionado la skill y te ayudan a detectar cuándo una nota se ha vuelto lo bastante importante como para subir al cuerpo de la receta.

⚠️ Cuidado con lo que se cuela en la receta. Una sesión real puede contener nombres de clientes, rutas internas, tokens o datos personales. Revisa la skill antes de guardarla, sobre todo si es de proyecto y va a acabar en un repositorio compartido.

¿Qué niveles de validación existen más allá de la segunda sesión? ¶

La regla de la segunda sesión es el centro, pero no el único control de calidad. Hay cuatro niveles, de más barato a más caro.

Nivel 0: la primera sesión. La tarea salió bien antes de que existiera la skill. Sabes que el plato es posible.

Nivel 1: la segunda sesión real. Lo pruebas tú, en tu cocina, con ingredientes distintos. Es la validación que más vale y la que define el método.

Nivel 2: la cata a ciegas. skill-creator permite lanzar evaluaciones: genera prompts de prueba, ejecuta la tarea con y sin la skill y te ayuda a comparar resultados. También puede optimizar la description probando qué frases la activan y cuáles no. Es útil cuando la salida es verificable (transformaciones de ficheros, código generado, flujos de pasos fijos). Para salidas subjetivas, como un estilo de escritura, sigue ganando tu paladar.

Nivel 3: el jurado. Lanza varios agentes, o el mismo con modelos diferentes, para que cocinen con tu receta y te devuelvan recomendaciones. Los agentes entienden qué es una skill y pueden decirte dónde se atascaron, qué instrucción era ambigua o qué paso sobraba.

🛡️ No te saltes el nivel 1 para ir directo al 2 o al 3. Una skill que pasa evals sintéticas pero nunca se ha usado en una segunda sesión real está validada contra casos inventados.

¿Qué pasa cuando la receta ya está escrita? ¶

Que ya no hace falta que la cocines tú.

Una skill con una buena description puede invocarla cualquier proceso que sepa que existe: un agente programado que se ejecuta cada mañana, un loop que procesa issues uno detrás de otro, un subagente que revisa cada PR. Es el paso del plato que preparas tú al menú del día que sale de la cocina sin que estés mirando.

Lo que empezó como “hazme esto ahora” acaba siendo “haz esto cada vez que pase aquello”. Y sin escribir un script nuevo, porque las instrucciones ya están escritas y probadas en sesiones reales.

¿Qué ejemplos reales tiene Cook-First Skills? ¶

Vamos con casos concretos. Algunos de código y otros no, a propósito.

El trabajo pendiente ¶

Cada mañana le preguntas al agente qué tienes pendiente. Tiene acceso a tu gestor de tareas, o puedes dárselo. La primera vez le explicas qué proyectos mirar, qué etiquetas ignorar y cómo quieres el resumen. La segunda ya no quieres explicarlo.

Esa receta es tuya. No necesitas la que publicó otra persona con su gestor, sus etiquetas y sus manías. Necesitas la que sabe las tuyas.

El planificador de viajes ¶

Es una de mis favoritas. Cuando planifico un viaje por carretera quiero saber cosas que ninguna app me da juntas: las mejores paradas a pie de carretera, dónde está la gasolinera más barata de una marca concreta y qué tiempo va a hacer justo cuando prevea pasar por cada punto, no el de la ciudad de destino.

La primera vez fue una conversación larga, con búsquedas, correcciones y formatos descartados. De ahí salió una skill que ahora genera el recorrido con tiempos, meteorología por tramo, paradas y combustible. No la diseñé. La cociné primero.

El patrón de revisión ¶

En un flujo de desarrollo descubres un patrón, o crees que lo tienes, o le preguntas al agente si lo ve. Un caso típico: cómo quieres que el agente revise su propio trabajo antes de darlo por terminado. Qué criterios aplica, cómo te responde, qué pruebas ejecuta y qué evidencias te enseña.

Lo vas afinando sesión a sesión hasta que te das cuenta de que lo repites de memoria. Ese es el momento de escribir la skill. Algunas de mis skills de revisión empezaron así: un panel con diferentes lentes (pre-mortem, arquitectura, sobreingeniería) que nació de pedirle al agente, muchas veces seguidas, que mirara el mismo cambio desde ángulos distintos.

La receta que se anota sola ¶

Hay una variante que me parece la expresión más pura del método: incluir el refinamiento dentro de la propia skill. Tengo una skill para resolver issues de GitHub cuyo último paso es una reflexión: qué ha ido mal en esta ejecución y qué habría que cambiar en las instrucciones. Y lo aplica sobre su propio SKILL.md.

No es magia y conviene revisar esos cambios como revisarías un PR. Pero el ciclo deja de depender de que tú te acuerdes de refinar.

Más allá del código ¶

Las mismas reglas valen para:

• Montar las diapositivas de una charla con tu estructura de siempre.
• Editar un vídeo siguiendo tus cortes, rótulos y ritmo habituales.
• Generar facturas a partir de las horas registradas.
• Procesar un extracto bancario y clasificar los movimientos como lo hace tu gestoría.

Si lo has cocinado una vez con un agente y lo vas a volver a cocinar, es candidato.

¿Qué errores conviene evitar? ¶

Estos son los tropiezos que más veo (y que más he cometido):

1. La receta que solo sale con los tomates de aquel día. La skill describe exactamente lo que pasó en aquella sesión, con aquel fichero y aquel cliente. La segunda sesión la rompe. La propia skill-creator insiste en generalizar a partir del feedback en lugar de meter parches muy específicos.
2. Escribir recetas que nunca vuelves a cocinar. Creas veinte skills en una semana y no repites ninguna. Eso no es Cook-First, es coleccionismo.
3. Description vaga. “Helps with tasks” no activa nada. Usa las frases reales con las que pides esa tarea.
4. Separar elaboraciones demasiado pronto. Cinco skills de diez líneas que siempre se usan juntas son una skill con problemas de identidad.
5. No revisar lo que se ha colado. Datos sensibles, rutas absolutas de tu máquina, nombres de clientes.
6. Dar la receta por terminada. Una skill Cook-First está viva. Si lleva tres meses sin cambiar y la usas a menudo, o es perfecta o has dejado de corregir al agente cuando falla.

¿Cómo empiezo mañana? ¶

Un experimento de dos semanas:

1. Instala skill-creator (o la skill de creación de skills que use tu agente).
2. Elige una tarea que hagas al menos una vez por semana con un agente.
3. La próxima vez que la hagas, al terminar, pregunta: “¿qué skills ves en esta sesión?”.
4. Escribe la que más sentido tenga, con la description en tus palabras reales.
5. La semana siguiente, aplica la regla de la segunda sesión: repite la tarea con la skill cargada y corrige la receta, no solo el plato.

Al cabo de tres o cuatro iteraciones tendrás algo que ningún catálogo te puede dar: instrucciones que conocen tu forma de trabajar porque han salido de ella.

🔑 Cook-First Skills en una frase: cocina con el agente, escribe la skill, y no la des por buena hasta que la hayas vuelto a cocinar.

Preguntas frecuentes ¶

¿Qué es Cook-First Skills? ¶

Es una forma de trabajar con agentes de IA en la que las skills nacen de sesiones de trabajo reales. Primero resuelves la tarea con el agente, después la conviertes en un SKILL.md y la validas usándola en una segunda sesión real, refinándola cada vez que tienes que corregir al agente.

¿Qué es la regla de la segunda sesión? ¶

Es el principio central del método: una skill no está validada hasta que la has usado en una segunda sesión real. Revisar el texto o pedirle al agente que lo valore no sustituye a volver a hacer la tarea con otros datos y comprobar si aguanta.

¿Funciona con cualquier agente de IA? ¶

Sí, con cualquier agente compatible con el estándar Agent Skills: Claude Code, Codex, OpenCode, Cursor y otros. El formato SKILL.md es abierto, así que la receta que escribes en uno suele funcionar en los demás con ajustes mínimos.

¿Necesito skill-creator? ¶

No es imprescindible, pero es recomendable. Cualquier agente puede escribir un SKILL.md si le explicas el formato. skill-creator aporta buenas prácticas, evaluaciones automáticas y optimización de la description, lo que ahorra iteraciones.

¿En qué se diferencia de Spec-Driven Development? ¶

La spec se escribe antes de que el agente trabaje y define qué construir esta vez. La skill Cook-First se escribe después y captura cómo repetirlo. Una es el menú y la otra la receta, y se combinan bien.

¿Cuándo merece la pena convertir una sesión en una skill? ¶

Cuando sabes que la tarea se va a repetir y en la sesión has tenido que dar contexto o correcciones que no quieres volver a dar. Si la tarea es puntual o el agente la resuelve bien sin ayuda, no hace falta.

¿Dónde guardo la skill, en el proyecto o a nivel de usuario? ¶

Si el conocimiento depende del proyecto (su arquitectura, su despliegue, sus convenciones), en el proyecto. Si depende de ti (tu forma de revisar, de planificar, de escribir), a nivel de usuario.

¿Cómo escribo una description para que la skill se active sola? ¶

Describe cuándo debe usarse, no qué es. Incluye las frases reales con las que pides esa tarea, en los idiomas en los que las pides, y los contextos en los que debería activarse aunque no la nombres.

¿Cuándo debo dividir una skill en varias? ¶

Cuando se vuelve difícil de mantener o cuando una parte se reutiliza en otro contexto. No lo hagas en la primera versión: divide cuando duela, no antes.

¿Puede una skill mejorarse sola? ¶

Puede incluir un paso final de reflexión en el que el agente propone o aplica cambios sobre su propio SKILL.md. Funciona, pero conviene revisar esos cambios como revisarías un PR para evitar que la skill derive hacia instrucciones raras.

Fuentes ¶

• skill-creator: SKILL.md en el repositorio de Anthropic
• Agent Skills: especificación y página oficial
• Catálogo de skills en skills.sh
• Agent Skills: guía completa para Claude Code, Codex, Cursor y OpenCode
• Buenas prácticas para crear skills de agentes de IA