El pack de skills de Matt Pocock: un flujo de interrogar, spec, ticket, implementar y revisar

El vibe coding es muy divertido hasta que el código tiene que enfrentarse a un producto real. Describes una funcionalidad, el agente asiente y produce una montaña de código, y aparece un pull request que parece muy ajetreado. Entonces afloran los problemas. El comportamiento no es del todo el que el equipo tenía en mente, la explicación está llena de jerga, un caso límite rompe el checkout y el código existente se ha vuelto, en silencio, más difícil de cambiar.

Que un agente escriba código malo no es la parte que da miedo, porque la gente también lo hace. La parte que da miedo es que un agente acelera un malentendido. Una petición difusa se convierte en un error grande, convincente y caro.

El repositorio de skills de Matt Pocock es una respuesta práctica a esto. Su README se llama a sí mismo «Skills For Real Engineers» (skills para ingenieros de verdad): pequeñas instrucciones que se pueden invocar cuando hace falta un tipo concreto de ayuda. La idea no es entregar todo el proceso de desarrollo a un framework gigante. Es darle al agente un puñado de movimientos fiables para los momentos en que cuenta el criterio de ingeniería.

El agente se gana el sueldo frenando primero en los tramos peligrosos de un trabajo y solo después acelerando el tecleo.

Qué contiene el pack

El repositorio es un conjunto de skills combinables para trabajar con un agente dentro de una base de código existente. Una skill cuestiona una idea, otra la convierte en una spec, otra divide la spec en tickets, y la implementación y la revisión tienen cada una su propia skill enfocada.

Esa promesa es más pequeña que «pasar toda la empresa por esta metodología», y es más útil. El repo conserva sus propias convenciones, su tracker, su documentación y su arquitectura, y las skills ayudan al agente a moverse por ellos.

Hace falta una configuración única por repositorio. Instala el pack con una de estas dos opciones, nunca con ambas:

claude plugins install mattpocock-skills

o:

npx skills@latest add mattpocock/skills

Luego ejecuta esto una vez dentro del repo:

/setup-matt-pocock-skills

Durante la configuración el agente aprende la estructura local, incluidos el tracker de issues, las etiquetas de triage y las rutas de documentación. No es una rutina diaria. Es contexto que, de otro modo, habría que redescubrir, adivinar u olvidar.

Por qué un prompt no basta, y un proceso enorme tampoco

Un prompt enuncia un deseo. No puede cargar de forma fiable todas las decisiones escondidas dentro de una frase corta de producto.

«Añadir carritos guardados a la tienda» suena claro hasta que alguien pregunta qué guarda un carrito guardado, quién puede verlo, qué pasa cuando cambia el stock, si los precios se bloquean y dónde encaja la funcionalidad. Un solo prompt entierra esas preguntas bajo una orden: constrúyelo.

La reacción contraria es un proceso pesado que afirma tratar cada proyecto igual. Cambia la ambigüedad por ceremonia, incluso cuando la tarea es diminuta o el repo ya tiene una buena rutina. El proceso se convierte en el producto.

Este pack se sitúa entre ambos. Skills enfocadas apuntan a modos de fallo enfocados. Una idea se puede interrogar, una spec duradera se puede escribir cuando se justifica, y los tickets se pueden ajustar al tracker en uso. Para una errata de una línea, casi todo eso se puede saltar. Comparadas con un framework que se adueña de todo el flujo, las skills pequeñas son más fáciles de combinar, leer y reemplazar.

Los fallos a los que apunta

El README ayuda porque nombra fallos concretos y no trata la programación con IA como una única actividad mágica.

• Desalineación. El agente construye una lectura plausible que no es la que se pretendía. grill-me interroga la idea directamente, y grill-with-docs trae a la conversación la documentación del repositorio y el contexto del dominio.
• Jerga verbosa. Una respuesta puede sonar segura y aun así dejar el producto más confuso que antes. El flujo orientado a documentación puede registrar contexto en CONTEXT.md y en ADRs, y domain-modeling hace explícitos los conceptos clave para que no se disuelvan en nombres como data, item o manager.
• Código que no funciona. Para la implementación guiada por tests el flujo apunta a /tdd, y a diagnosing-bugs cuando un comportamiento que falla necesita investigación en lugar de otro parche especulativo.
• Una bola de barro. Cuando una funcionalidad no encaja en ningún sitio, otra abstracción no siempre es la cura. to-spec, improve-codebase-architecture y codebase-design hacen visible la forma del sistema y ayudan a mejorarla a propósito.

Unas pocas skills de enrutado y coordinación redondean el conjunto. ask-matt ayuda a elegir un camino, wayfinder da soporte a planes que abarcan varias sesiones, handoff preserva el estado, wait-what comprueba la comprensión y triage ordena qué debería pasar a continuación.

El pipeline

El flujo central encadena cinco pasos:

/grill-with-docs -> /to-spec -> /to-tickets -> /implement -> /code-review

Por debajo, /implement impulsa /tdd. Cada paso tiene un solo trabajo, y su salida le da al siguiente paso algo concreto con lo que trabajar.

1. Interrogar la idea

Empieza con /grill-with-docs cuando una funcionalidad abarque preocupaciones de producto y técnicas. Describe lo que quieres y pide al agente que ponga en duda los supuestos usando la documentación del repositorio.

En el ejemplo del carrito guardado, las preguntas útiles llegan antes que cualquier código. ¿Está un carrito guardado atado a una cuenta? ¿Puede un cliente tener varios? ¿Restaurar uno vuelve a comprobar stock y precio? ¿Es una instantánea o un puntero al catálogo en vivo? ¿Se puede compartir? ¿Qué ve el usuario cuando un producto se ha descatalogado?

El objetivo no es una entrevista interminable. Es sacar a la luz las decisiones que, si se dejan abiertas, tomaría por defecto la implementación.

Cuando la idea ya se entiende bien, basta con el más ligero grill-me. Si el agente empieza a usar términos que el equipo no usa, pide un CONTEXT.md, un ADR o una pasada de domain-modeling. Un vocabulario compartido y corto vale más que una respuesta larga.

2. Convertir las decisiones en una spec

Con las respuestas en la mano, ejecuta /to-spec. Una spec enuncia qué hace la funcionalidad, qué no hace y cómo reconocerá el éxito el sistema existente.

Toma una tienda en TypeScript. Su spec podría describir un carrito guardado como una lista con nombre que pertenece a un cliente con sesión iniciada. Solo se guardan los IDs de producto y las cantidades, sin precios congelados ni recuentos de stock. Al restaurar, se vuelve a comprobar la disponibilidad, y las líneas que no se pueden cumplir pasan por el manejo de errores que ya existe. A los invitados se les pide iniciar sesión.

Eso es mucho más valioso que «añadir carritos guardados». El equipo obtiene algo concreto que revisar, y el agente obtiene límites. Si compartir en público no está en la spec, nadie debería leerlo como una invitación a inventarlo. Una spec hace revisables las decisiones importantes antes de que se conviertan en código.

3. Convertir la spec en tickets

Ejecuta /to-tickets una vez que la spec sea lo bastante estable para dividirla. Los tickets deberían describir porciones que se puedan construir y revisar, y no una lista de departamentos vagos. Una forma razonable de trocear esta funcionalidad:

1. Modelo de dominio y capa de almacenamiento para carritos que pertenecen a clientes con sesión iniciada.
2. Comandos más validación que cubran guardar, listar, renombrar, borrar y restaurar.
3. Un paso de restauración que vuelve a comprobar el stock y los precios de hoy.
4. Pantallas de la tienda, incluidos los estados de carga, vacío y error.
5. Tests de integración para las reglas de acceso, los productos ausentes y una restauración limpia.

El formato de los tickets debería seguir el tracker y las convenciones del repo, lo que es una razón por la que importa el comando de configuración: las skills pueden usar el tracker del proyecto, las etiquetas y las rutas de documentación. Los tickets también funcionan como un punto de parada natural. Quizá el primer lanzamiento solo necesite guardar y restaurar. Recortar el alcance aquí es mejor que recortarlo después de la implementación.

4. Implementar con los tests por delante

Ahora ejecuta /implement. Impulsa /tdd, así que el agente parte del comportamiento observable, escribe un test que falla, hace el cambio más pequeño que lo pasa y mantiene la suite en juego mientras avanza por los tickets.

En el caso de la tienda, eso se traduce en tres tests: un cliente con sesión iniciada puede guardar un carrito, un cliente distinto no puede leerlo, y restaurar un carrito rechaza cualquier línea cuyo producto haya desaparecido. El código debería mantenerse dentro de los límites actuales de dominio y persistencia del repositorio. No hace falta una segunda abstracción de carrito en paralelo solo porque el prompt mencionara un «carrito guardado».

Si un test falla, no pidas ediciones al azar hasta que el rojo se vuelva verde. Usa diagnosing-bugs para investigar. Piensa en un test que falla como evidencia sobre el sistema y no como un obstáculo de camino a una marca verde.

A veces el trabajo muestra que la spec estaba equivocada. Entonces lo correcto es volver a ella, porque nada obliga a que este flujo corra en línea recta. El objetivo es mantener decisión, ticket, test y código contando la misma historia, no proteger lo que se escribió primero.

5. Revisar el resultado

Termina con /code-review. Es más que una comprobación de estilo. Los revisores buscan acuerdo entre el comportamiento y la spec, tests que de verdad cubran los casos que importan, respeto por la arquitectura ya existente y una superficie pública mantenida lo más pequeña posible.

Una revisión sólida podría descubrir lógica de restauración que pertenece a un servicio de checkout que ya está en la base de código, un endpoint de listado al que le falta su comprobación de autorización, o una interfaz que deja a la gente comprar un producto que ya no está disponible. También podría encontrar que la funcionalidad es correcta mientras que el límite del módulo se volvió más difícil de seguir. Ahí es cuando improve-codebase-architecture o codebase-design pueden ayudar como seguimiento, y no como un ritual impuesto a cada cambio.

La revisión final protege la base de código de una funcionalidad que solo pasó sus propios tests estrechos.

Qué lo distingue

El flujo separa tipos de pensamiento que los agentes tienden a mezclar. Aclarar una decisión de producto no es diseñar un módulo, diseñar un módulo no es escribir un test, y un test que pasa no prueba que la funcionalidad pertenezca a la arquitectura actual.

El criterio sigue en manos humanas. Puedes detenerte tras el interrogatorio, reescribir la spec, descartar una división de tickets propuesta o dejar que ask-matt sugiera la skill adecuada. wayfinder cubre los planes de varias sesiones, handoff conserva el contexto, wait-what comprueba una petición confusa y triage elige la siguiente pieza de trabajo.

Eso encaja con la ingeniería real mejor que un prompt que dice «sé un desarrollador senior». El agente obtiene comportamientos repetibles sin fingir que la pericia es un rasgo de personalidad.

Cuándo saltárselo

Para una errata de una línea, un pequeño cambio de texto o un experimento local desechable, todo esto es excesivo. La configuración tiene un coste aunque solo se pague una vez por repo, y las pausas deliberadas no son gratis cuando el cambio es de verdad trivial.

Usa el sentido común. Los cambios que tocan reglas de negocio, límites de módulos, datos almacenados, permisos o una API pública justifican la pausa, ya que cuesta menos que limpiar tras un malentendido seguro de sí mismo. Todo lo demás puede tomar el atajo.

Empezar poco a poco funciona bien. Elige una ruta de instalación, ejecuta /setup-matt-pocock-skills en un repositorio real y prueba /grill-me en la próxima funcionalidad que parezca clara pero en realidad no lo sea. Cuando un cambio se gane el camino completo, extiende la ejecución por /grill-with-docs y sigue hacia las specs, los tickets, /implement y /code-review.

El beneficio no es un mayor número de líneas por hora. Simplemente acaban menos supuestos erróneos en el código desde el principio. Esa es una promesa mucho menos glamurosa que el vibe coding, y es la que sigue en pie cuando la tienda ya está en producción y otro ingeniero hereda lo que el agente dejó atrás.