La habilidad /implement

Fuente: The /implement Skill — traducción comunitaria no oficial al español.

Qué hace

implement construye trabajo que ya está decidido. Le apuntas a un ticket, a una especificación o al plan que acabas de acordar en la conversación, y escribe el código, aplica tdd en las costuras, verifica tipos sobre la marcha, ejecuta code-review al final y publica un commit en la rama actual.

Nunca reabre el plan. No hay entrevista, ni ronda de aclaraciones, ni propuesta de un enfoque distinto. Lo que se acordó antes es la entrada, y todo el trabajo de la habilidad es convertirlo en un commit. Eso es lo que la separa de escribir «construye esto» a un agente nuevo, que con gusto rediseñará el trabajo mientras lo construye.

Cuándo recurrir a ella

La invocas escribiendo /implement tú mismo: el agente no la usará por su cuenta. Se distribuye con disable-model-invocation: true, así que ninguna otra habilidad puede llamarla tampoco. Donde ask-matt o to-tickets dicen «luego /implement por ticket», eso es una instrucción para ti, no algo que el agente hará sin que se lo pidas.

Dónde vive ahora el trabajo decide si esta es la habilidad correcta:

El trabajo es…	Recurre a
Un ticket en el gestor	/implement #42, un ticket por sesión, limpiando el contexto entre tickets
Una especificación, aún sin dividir, y la construcción abarca varias sesiones	to-tickets primero, luego /implement por ticket
Una especificación, y la construcción es pequeña	/implement directamente contra la especificación
Solo está en la conversación que acabas de tener, y sigue siendo pequeña	/implement ahí mismo, en la misma ventana
Aún no está escrito en ningún lado	grill-with-docs, o grill-me si no hay base de código
Un comportamiento concreto que quieres con pruebas primero, sin especificación	tdd directamente
Ya está construido y quieres que se revise	code-review directamente

El caso de la misma sesión vale la pena porque la primera línea de la habilidad no lo cubre. SKILL.md dice «la especificación o los tickets», lo que empuja al modelo a buscar un archivo que no existe. Si el plan solo vive en el hilo, dilo al invocarla.

Requisitos previos

implement publica el commit en la rama en la que estás. No crea una rama ni pregunta. Comprueba que estás en la rama donde quieres el trabajo antes de empezar.

Si los tickets vienen de to-tickets, el gestor donde viven lo configuró setup-matt-pocock-skills. code-review lee la misma configuración para encontrar la especificación de origen al cerrar.

Qué hace una ejecución

Una ejecución son cinco tiempos, en orden:

1. Leer el ticket o la especificación y detectar las costuras.
2. Aplicar tdd en las costuras preacordadas, un segmento rojo-verde a la vez.
3. Verificar tipos a menudo, ejecutar archivos de prueba individuales sobre la marcha.
4. Ejecutar la suite completa de pruebas una vez, al final.
5. Ejecutar code-review y luego publicar el commit en la rama actual.

Una ejecución cubre un ticket. Los tickets que produce to-tickets son segmentos verticales trazadores dimensionados para caber en una ventana de contexto nueva, así que el ritmo previsto es: limpiar el contexto, implementar un ticket, publicar el commit, limpiar de nuevo. Cada ticket es autocontenido, que es lo que hace desechable el contexto del ticket anterior.

Costuras preacordadas

La idea sobre la que corre la habilidad es la costura: el límite público donde observas el comportamiento, sin meterte dentro. Las pruebas viven en las costuras. Trabajar en una costura acordada antes de escribir código es lo que mantiene las pruebas duraderas, porque la implementación de abajo puede reescribirse sin que las pruebas se muevan.

La palabra «preacordada» hace un trabajo real, y también es la junta más débil de la habilidad. Nada dentro de implement acuerda las costuras. tdd es la habilidad que pregunta, y se niega a escribir una prueba en una costura sin confirmar. Así que en la práctica el acuerdo ocurre o bien antes en la especificación, o bien en el primer intercambio de la ejecución. Si no ocurre en ningún lado, la precondición nunca se dispara y la ejecución se convierte silenciosamente en «solo escribe el código». Nombrar las costuras en la especificación es lo que evita eso.

Preguntas comunes

Terminó, pero mi ticket sigue abierto y los criterios de aceptación siguen sin marcar.

Correcto y esperado. implement no tiene paso de cierre. Termina en el commit y nunca toca el elemento de trabajo, confirmado en GitHub Issues y en el gestor local de markdown, así que no es un problema de integración con el gestor. Tampoco actúa sobre los hallazgos que produjo code-review, ni marca las casillas - [ ] de la incidencia de origen. Cierra el ticket y concilia los criterios tú mismo. Esto muerde más en una cadena de dependencias, porque to-tickets define la frontera como los tickets cuyos bloqueadores están todos cerrados. Si nada se cierra, nada queda visiblemente desbloqueado.

¿Puedo apuntarla a todos mis tickets a la vez, o ejecutar varios en paralelo?

No. Una invocación, un ticket. El despacho por lotes sobre una cola de tickets y el despliegue en abanico con subagentes se piden repetidamente, y ninguno existe. Ejecutar varias sesiones de /implement en paralelo en la misma copia de trabajo es peor que no soportado: un reporte de campo describe un git commit --amend en una sesión cayendo sobre el commit de otra sesión, un stash desapareciendo de refs/stash y commits aterrizando en la rama equivocada, todo en una sola tarde con tres incidencias. Las sesiones comparten un directorio de trabajo, un índice y un HEAD. Los worktrees de git son la solución de la comunidad, y ten en cuenta que refs/stash se comparte entre worktrees también, así que solo con worktrees no se arregla el caso del stash. Si hoy quieres paralelismo, lo montas tú.

¿Puede abrir una pull request en vez de publicar un commit?

No viene integrado. Publica el commit directo en la rama actual, lo que a varias personas les parece demasiado ansioso: el código aterriza antes de que hayan podido verificar que funciona. No hay bandera de configuración ni modo PR. La gente lo cambia en la invocación («publica el commit en una rama y abre una PR») o editando su copia local de la habilidad.

code-review dice que no puede ver mis cambios.

code-review revisa git diff <punto-fijo>...HEAD, lo que excluye los cambios en stage y en el árbol de trabajo. implement la ejecuta antes de publicar el commit, así que salvo que ya exista un commit intermedio no hay nada en ese diff para revisar. Varias personas lo han reportado y sigue sin arreglarse en ninguno de los dos lados. Publica primero el commit y luego revisa contra el punto del que partió la rama.

Aparte, algunas personas deliberadamente no quieren la revisión dentro de la ejecución, porque un agente que revisa el código que acaba de escribir está sesgado hacia su propia solución. Ejecutar code-review en una sesión nueva contra un punto fijo es una alternativa legítima, y es la misma razón por la que esa habilidad ejecuta sus dos ejes en subagentes separados.

Un ticket quemó 150k tokens. ¿Lo estoy usando mal?

Probablemente el ticket es demasiado grande más que un mal uso de la habilidad. Una ejecución hace exploración de la base de código, un bucle rojo-verde por costura, una suite completa y una revisión, así que un ticket no trivial que supere los 100k tokens es normal y no señal de que algo se rompió. La palanca está antes: dimensiona bien los tickets en to-tickets para que cada uno quepa en una ventana nueva. Si un solo ticket sigue desbordándose, divídelo en vez de subir el nivel de esfuerzo.

/implement #2 en una sesión nueva trabajó en algo totalmente distinto.

#2 se resuelve contra cualquier lista numerada que el agente pueda ver, que en una sesión nueva puede ser un archivo de pendientes, una checklist u otra lista de trabajo en vez del gestor configurado. La resolución es segura en vez de fallar cerrado, así que el error no es obvio hasta que ya empezó. Pasa la referencia completa, la URL de la incidencia u owner/repo#2, y pídele que te confirme el título antes de empezar.

Funciona si

• La sesión abre leyendo el ticket o la especificación y reformulando lo que va a construir, en vez de preguntarte qué construir.
• Puedes ver una invocación real a /tdd en la traza, no solo pruebas apareciendo en el diff.
• Las verificaciones de tipos y los archivos de prueba individuales se ejecutan repetidamente durante la ejecución, y la suite completa se ejecuta una vez cerca del final.
• La ejecución llega a un commit en tu rama actual sin que tengas que pedirle que continúe.
• El diff es el cambio de un ticket: un segmento vertical por todas las capas, no varios tickets barridos juntos.

Dónde encaja

implement es el paso de construcción de la cadena principal, el segundo desde el final:

grill-with-docs → to-spec → to-tickets → implement → code-review

Sus vecinas son to-tickets, que produce los tickets que consume y declara los bordes de bloqueo que deciden su orden; tdd, que impulsa internamente en cada costura; y code-review, que ejecuta antes de publicar el commit. Está después de las habilidades de planificación y confía en ellas. No revalida la forma de lo que recibió, así que un mapa mal estructurado o un ticket por capas horizontales se construye tal como está escrito.

Esa confianza es por lo que wayfinder se incorpora a la cadena en to-spec en vez de llevar su mapa directo a implement. Ve directo a implement desde un mapa solo cuando el esfuerzo resultó genuinamente pequeño.

ask-matt es el enrutador sobre todo el conjunto cuando no estás seguro en qué flujo estás.