# 5 Agent Skills que Gobiernan Todo Mi Flujo de Código > Grilling, PRDs, vertical slices, TDD condicional y un AGENTS.md mínimo: el pipeline de cinco skills que aplico en cada feature, sobre las de Matt Pocock. → 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 la clave no es "usar IA para programar". Eso ya lo hace todo el mundo. La clave es darle un **proceso**. Repetible. Que no dependa de que tú estés inspirado un martes a las cinco. Que le obligue a pensar antes de tocar archivos como si fuera viernes en producción. [Matt Pocock](https://github.com/mattpocock/skills) 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. 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. Cinco etapas. Vamos. ## 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. ¿Por qué? Porque el modo de fallo por defecto de Claude Code es venirse arriba. 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. Lo que saco de aquí es oro puro: - **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. ¿Es incómodo? Sí. Mejor. Si tu idea no aguanta unas preguntas antes de construirla, espera a que la toquen usuarios de verdad. Cuando termina el grilling, la idea ya no es una nube. Tiene aristas. ## 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**. Y ese detalle lo cambia todo. El contexto deja de vivir en una sesión temporal de Claude. Ahora tiene URL. Tiene historial. Está donde vive el trabajo de verdad. 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. Importa más de lo que parece. 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. Menos magia. Más trazabilidad. ## 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" Parece ordenado, ¿verdad? Pero 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](https://framework.scaledagile.com/story). 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](https://www.aihero.dev/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.** No es dogma. Es ingeniería con contexto. 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. ¿Y el agente? No se lo lee bien. Lo escanea. 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`. Una sola fuente de verdad. Menos tokens quemados. Menos contradicciones. Menos "pero esto estaba en una línea perdida del documento gigante". Es un cambio pequeño, pero se nota. Sobre todo cuando usas agentes a diario. Las instrucciones no son un vertedero. Son una interfaz. ## La idea de fondo: el proceso es el foso Nada de esto es ciencia espacial. Interrogas la idea. La documentas. La cortas en slices pequeñas. Implementas con disciplina. Mantienes las instrucciones limpias. Lo potente no es ninguna skill concreta. Lo potente es convertir tu forma de trabajar en algo invocable. Repetible. Hasta aburrido. Y en programación, "aburrido" suele ser un piropo. Porque un agente puede ser muy capaz, pero no tiene contexto permanente. No tiene memoria de equipo. No sabe por qué existe una decisión vieja. No recuerda la guerra que hubo alrededor de un componente hace medio año. Tú sí. O deberías. Así que no lo trates como un oráculo. Trátalo como un dev fuerte que ha entrado al proyecto esta misma mañana y necesita un proceso para no romper cosas con seguridad. Dale un camino estricto y produce trabajo muy bueno. Déjalo suelto y te monta una abstracción genérica para un problema que todavía no había entendido. La idea base es de Matt Pocock, y su [repositorio de skills](https://github.com/mattpocock/skills) es el mejor sitio para empezar. No copies mi pipeline. De hecho, mejor no lo copies: lo interesante es construir el tuyo. Pero hazlo explícito. Porque en la era de los agentes tu ventaja ya no es solo escribir código. Es diseñar el sistema que hace que el código salga bien más de una vez. **Lectura relacionada:** estas skills se disfrutan más en un proyecto real. Aquí tienes [cómo construí ga4-manager para automatizar Google Analytics](/blog/ga4-manager-automatiza-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 [Twitter/X](https://x.com/garbarok).