5 Agent Skills que Gobiernan Todo Mi Flujo de Código

Un agente de IA es como tener a un dev muy bueno sentado a tu lado. Razona, escribe código, pilla patrones, a veces hasta te sorprende.

Tiene un problema: cada mañana se despierta sin memoria.

No recuerda nada. Ni la feature de ayer, ni por qué ese componente es así, ni la decisión que tomasteis hace seis meses entre lágrimas. Y si no le das contexto, ¿sabes qué hace? Se lo inventa. Con una seguridad pasmosa. Ahí empieza el espectáculo.

Por eso le doy un proceso que puedo repetir sin depender de estar inspirado un martes a las cinco. Le obliga a pensar antes de tocar archivos como si fuera viernes en producción.

Matt Pocock lo explicó de una forma muy limpia con las agent skills: instrucciones pequeñas, con nombre, que invocas cuando quieres que el agente siga un camino concreto. Leí su enfoque, me lo llevé a mi terreno, y acabó convertido en un pipeline que uso en casi cada feature. Las skills son una capa de lo que después llamé el harness: todo lo que rodea al modelo para que no se salga del carril.

Ojo: las skills no me las invento ni las modifico. Las uso tal cual vienen. Lo mío es el flujo: el orden en que las invoco y cómo las encadeno. Algunas son de Matt; otras vienen de otros sitios. De él me llevé la regla base: no dejes que el agente programe hasta que se haya ganado el derecho.

1. /grill-with-docs: clavar la idea antes de tocar código

Cada feature empieza igual: tengo una idea a medio hacer y, por mucho que me pique, no dejo que el agente escriba el plan todavía.

Claude Code suele venirse arriba cuando le pido un plan. Le dices “planifica esto” y te suelta un plan precioso, lleno de secciones y bullets, con una confianza que asusta. El problema: planifica sobre suposiciones. Y una suposición es un bug con buena gramática.

grill-with-docs le da la vuelta. En vez de planificar, me interroga.

Pregunta. Baja un nivel. Espera. Vuelve a preguntar. No quiere resolverlo todo de golpe: recorre el árbol de decisiones poco a poco: el “design tree” que Matt saca de The Design of Design de Fred Brooks. Vas bajando por las ramas hasta entender qué narices vas a construir antes de escribir una línea.

Y lo de “with-docs” no es decoración. Si algo se puede responder mirando el código, no me lo pregunta a mí: lo busca. Abre componentes, lee convenciones, mira tipos y APIs que ya existen. Si puede comprobarlo, no me hace perder el tiempo.

Del interrogatorio saco:

• Primero la foto completa. Antes de decidir si esto es un hook, un endpoint o un componente, entiendo la feature como sistema.
• Las preguntas incómodas. Estados vacíos, errores, condiciones de carrera, permisos, qué pasa si dos cosas ocurren a la vez. Lo que nadie piensa hasta que producción te lo explica con una captura a las 3 de la mañana.
• El scope, explícito. Esta es la parte que más me importa. Aquí digo: esto entra, esto no, y esto lo dejamos fuera a propósito. No “se nos olvidó”. Decidido, escrito, cerrado.

Si mi idea no aguanta unas preguntas antes de construirla, prefiero enterarme antes de que la toquen usuarios de verdad.

2. /to-prd: convertir la conversación en un documento en GitHub

Después del grilling ya hay algo que merece escribirse. Ahí entra to-prd.

La skill coge toda la conversación y la convierte en un Product Requirements Document. Pero no lo deja muriéndose en el chat: lo crea directamente como GitHub Issue.

La issue conserva el contexto, la URL y el historial fuera de la sesión de Claude. Cierro la terminal, cambio de rama, abro otra conversación… y la decisión sigue ahí. No se evapora.

El PRD gira en torno a las user stories: qué tiene que pasar para el usuario, en lenguaje humano, no una lista de archivos a tocar. Un buen PRD no dice “crea este hook y este servicio”. Dice qué comportamiento esperas y qué casos hay que cubrir. El cómo viene después.

Como el grilling ya hizo el trabajo sucio, esta fase no reabre el debate. Solo convierte decisiones en un artefacto que la siguiente etapa puede masticar.

3. /to-issues: cortar el destino en un trayecto

Un PRD te dice a dónde quieres llegar. No te dice cómo avanzar sin estrellarte por el camino.

Decirle a un agente “implementa este PRD entero” es invitarlo a hacer una mudanza con una bolsa del super. Igual sale bien. Pero no es un plan.

to-issues coge el PRD y lo parte en issues pequeñas de GitHub. Cada una entendible, ejecutable y revisable por separado.

La regla de oro: cortes verticales, no horizontales.

Nada de:

• “crear la capa de datos”
• “crear la lógica de negocio”
• “crear la UI”

Separar así el trabajo no entrega nada hasta que juntas las tres piezas. Mientras tanto tienes tres issues que por separado no sirven para nada. Eso es arquitectura en diferido.

Un vertical slice hace lo contrario: atraviesa UI, lógica y datos para entregar un comportamiento pequeño funcionando de punta a punta. Igual no es toda la feature. Pero ya es algo real, que se puede tocar.

Este hábito me viene de currar en un entorno SAFe. Y mira, SAFe tiene lo suyo. No nos engañemos, nadie se levanta feliz pensando en el PI Planning. Pero una idea se me quedó grabada a fuego: una story debería ser un corte vertical pequeño del comportamiento del sistema. Cortar por valor, no por tecnología. Si necesitas tres slices antes de que alguien vea algo útil, lo has cortado mal.

(Y no, esto no es Scrum, aunque mucha gente lo mezcla. SAFe va por encima de los equipos: varios equipos forman un Agile Release Train que se sincroniza cada 8 a 12 semanas. Abajo, en el equipo, la cosa funciona estilo Scrum, con iteraciones de dos semanas. La parte que me llevé es la de las stories.)

Y con agentes esto importa todavía más. to-issues no solo parte el trabajo: define dependencias. Qué bloquea a qué. Qué se puede coger ya. Qué puede ir en paralelo.

Eso es clave si quieres lanzar varios agentes a la vez. Una issue autocontenida se asigna sin que el agente tenga que entender medio universo. Si dos no se pisan, avanzan en paralelo. Y si están bien cortadas, revisarlas también duele mucho menos.

La idea tiene parentesco con las tracer bullets: disparos finos que atraviesan todas las capas para descubrir pronto lo que no sabías que no sabías. Porque los unknown unknowns no aparecen diseñando la capa perfecta en abstracto. Aparecen cuando algo funciona de verdad.

4. Implementar: TDD condicional, más una pasada nuclear de calidad

Ahora sí. Código. Pero no siempre igual: depende del codebase.

¿Proyecto nuevo? TDD desde el minuto uno.

En greenfield uso /tdd, la skill de Matt. Red, green, refactor. Sin dramas.

Primero el test. Que falle. Luego el mínimo código para que pase. Luego limpiar. Y otra vez, hasta cerrar el comportamiento.

Con agentes esto funciona de maravilla porque les das una diana. Ya no están “implementando una idea”: están intentando pasar un test concreto. Y eso recorta muchísimo la tentación de inventarse scope, montar abstracciones raras o tocar cosas que nadie pidió. Un test en rojo es la conversación más clara del mundo: esto todavía no funciona, arréglalo.

¿Codebase grande y heredado? No fuerzo TDD.

Aquí me bajo del púlpito. En una app legacy grande, meter TDD a mitad de feature es más teatro que ingeniería. Los límites no están claros, los mocks son una selva, el harness de tests parece construido por una civilización perdida… y acabas peleándote más con la infraestructura que entregando valor.

Así que en brownfield implemento de forma más directa. Pero no lo dejo pasar sin control: ahí entra /thermo-nuclear-code-quality-review.

El nombre es ridículo. También es bastante exacto.

Es una pasada agresiva de calidad sobre lo recién escrito. Busca simplificaciones, duplicación, nombres flojos, código que parece funcionar pero huele raro, casos sin cubrir, complejidad accidental. Es como pedirle al agente que deje de ser el autor y se convierta, durante diez minutos, en el reviewer más insoportable del equipo.

Y en legacy eso compensa un montón. No siempre puedo construir con TDD desde el principio, pero sí puedo obligar al resultado a pasar una revisión dura antes de darlo por bueno.

Mi regla queda así: greenfield, TDD; brownfield, implementación normal + revisión nuclear. El objetivo es el mismo: que el código final sea algo que yo firmaría en una PR sin mirar al suelo.

5. /setup-matt-pocock-skills: un AGENTS.md mínimo y un CLAUDE.md que solo apunta a él

La última skill no construye features. Construye el entorno para que las otras cuatro funcionen mejor.

setup-matt-pocock-skills instala el kit. Pero lo que de verdad me importa es con qué la combino: una limpieza seria de las instrucciones del proyecto.

Antes tenía, en cada proyecto, un CLAUDE.md gigante. El clásico: empiezas con cuatro reglas útiles, luego una convención, luego una excepción, luego “acuérdate de no tocar esto”, luego “cuando trabajes en tests, haz aquello”. Tres meses después tienes un documento que parece la Constitución de un país con demasiados microservicios.

El agente lo escanea y pierde detalles. Las reglas importantes quedan enterradas bajo el ruido.

La solución fue quitarle épica al asunto.

Ahora las instrucciones de verdad viven en un AGENTS.md deliberadamente pequeño: el estándar que ya entienden varias herramientas, lo bastante corto como para que el agente se lo lea entero. Y el CLAUDE.md se queda casi en un puntero: ve y lee AGENTS.md.

Así evito repetir reglas, gastar tokens en instrucciones duplicadas y mantener versiones que se contradicen.

El repositorio de skills de Matt Pocock es un punto de partida para montar tu propio flujo. Elige el orden de las skills según tu proyecto y déjalo escrito en sus instrucciones.

Lectura relacionada: estas skills se disfrutan más en un proyecto real. Aquí tienes cómo construí ga4-manager para automatizar Google Analytics, uno de los codebases sobre los que corre este pipeline.

P.D. Si has montado tu propio pipeline de skills, quiero verlo. ¿Qué has codificado que a mí me falta? Escríbeme en LinkedIn.