La habilidad /tdd

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

Qué hace

tdd construye una funcionalidad o arregla un error con pruebas primero: una prueba que falla, luego el código justo para pasarla, luego el siguiente comportamiento. Trae los estándares que hacen que ese bucle produzca pruebas que vale la pena conservar: qué es una buena prueba, dónde van las pruebas, para qué son los mocks y los tres antipatrones que arruinan una suite en silencio.

No escribe ninguna prueba en una costura que no hayas acordado antes. Antes de que exista ninguna prueba, nombra los límites públicos donde pretende probar y se detiene a por tu confirmación, porque el esfuerzo de pruebas es finito y aquí es donde lo gastas en las rutas críticas en vez de en cada caso borde. La otra cosa que hay que saber es que tdd es una referencia, no un conductor. Guarda las reglas del bucle, y algo más (tú, o implement) corre la sesión que las aplica.

Cuándo recurrir a ella

Escribe /tdd, o el agente la usará automáticamente cuando la tarea encaje: construir una funcionalidad o arreglar un error con pruebas primero, o cuando digas «red-green-refactor».

Recurre a ella cuando haya un comportamiento concreto que construir, con una entrada y una salida observable, y quieras pruebas que sobrevivan a una refactorización.

Tu situación	A dónde ir
Un comportamiento con entradas y salidas definidas (lógica de negocio, un contrato petición/respuesta, una transformación, validación)	tdd
El comportamiento aún no está fijado	to-spec, que también acuerda las costuras de prueba antes de escribir código
La pregunta es realmente la forma de la interfaz, no las pruebas	codebase-design
Tienes una especificación o tickets y quieres que toda la construcción corra por ti	implement, que impulsa tdd por ticket
Configuración, cableado, pegamento, anotaciones de tipos, delegación CRUD directa	Nada aquí encaja bien; ver el hueco abierto abajo

Esa última fila es un hueco real, no una preferencia de estilo. La habilidad decide dónde van las costuras; nada en ella decide si un cambio vale el bucle. Ejecutarla en un cambio sin fuente independiente de verdad contra la cual afirmar y obtienes una prueba que reformula la implementación: el antipatrón tautológico contra el que la propia habilidad advierte, llegado desde la otra dirección. Es el issue #746 y está abierto. Hasta que se cierre, ese juicio es tuyo o de tu CLAUDE.md.

Requisitos previos

codebase-design tiene que estar instalado. tdd solía traer sus propias notas de módulos profundos y diseño de interfaces; en v1.0 se eliminaron a favor de la habilidad compartida, y tdd ahora se apoya en ella para el vocabulario de diseño de interfaces. Nada más; la habilidad es sin estado y no escribe archivos propios.

El bucle, y la costura donde corre

Tres palabras sostienen esta habilidad.

Rojo-verde. Escribe la prueba que falla, luego solo el código suficiente para pasarla. Sin anticipar la prueba siguiente. No hay fase de refactorización: se quitó en junio de 2026 porque los agentes esencialmente nunca la hacían, y porque la revisión y la implementación funcionan mejor como sesiones separadas. Refactorizar pertenece a code-review.

Segmento vertical. Una costura, una prueba, una implementación mínima, y repetir, siendo el primer ciclo una bala trazadora que prueba un único camino de extremo a extremo. Lo opuesto es el corte horizontal: todas las pruebas primero, luego todo el código. Las pruebas en bloque verifican comportamiento imaginado, comprueban la forma de las cosas más que lo que un usuario hace, y te comprometen con una estructura de pruebas antes de entender la implementación.

Costura preacordada. Una costura es el límite público donde observas el comportamiento sin meterte dentro. La regla es absoluta: ninguna prueba en una costura sin confirmar. En la cadena completa las costuras se acuerdan antes, durante to-spec: «a /tdd se le dice que solo trabaje en costuras de prueba preacordadas, /code-review comprueba que solo se usaron costuras acordadas». Invocada sola, tdd te pregunta directamente.

Los tres antipatrones que está escrita para prevenir:

Antipatrón	La señal
Acoplado a implementación	La prueba se rompe cuando renombras una función interna, aunque el comportamiento no cambió. Colaboradores internos con mock, conteos de llamadas afirmados, consultas a base de datos usadas para verificar en vez de la interfaz.
Tautológico	El valor esperado se calcula como lo calcula el código, así que la prueba pasa por construcción. Los valores esperados tienen que venir de otro lado: un literal conocido-bueno, un ejemplo trabajado, la especificación.
Corte horizontal	Un lote de pruebas aterrizó antes de cualquier implementación.

Los mocks son solo para límites del sistema: API externas, tiempo, aleatoriedad, a veces el sistema de archivos o la base de datos. No tus propios módulos.

Preguntas comunes

¿Por qué no refactoriza? La descripción dice «red-green-refactor».

Porque el paso de refactorización se eliminó y la descripción no. La eliminación fue deliberada: los agentes esencialmente nunca lo hacían, y mantener implementación y revisión en sesiones separadas funciona mejor. Si el resultado sigue contando como TDD de manual importa menos que si el bucle produce mejor código. El desajuste entre la frase disparadora y el cuerpo está archivado como issue #589 y sigue abierto, así que «red-green-refactor» sigue funcionando como frase que dispara la habilidad. Lo que obtienes es rojo → verde, y refactorización en code-review.

Me pidió elegir una costura de prueba y no tenía idea cuál elegir.

Es la fricción más reportada con la habilidad (issue #607). El prompt lista candidatas de costuras solo por nombre, sin nada sobre qué atrapa o pierde cada una, así que eliges entre etiquetas. Aún no hay arreglo distribuido. La solución práctica es pedir al agente los trueques antes de responder: qué pierde la costura a nivel de componente que la costura de integración atrapa, y cuánto más lenta es. También por eso la cadena acuerda costuras por adelantado en to-spec, donde tienes la funcionalidad completa a la vista en vez de un solo prompt.

Escribió la implementación antes que la prueba, aunque la habilidad dice rojo primero.

Pasa. Un usuario presionó al modelo y obtuvo una respuesta inusualmente honesta: «Sabía que la habilidad decía “una prueba a la vez, mírala fallar por la razón correcta”. Lo leí. Solo volví a mi hábito normal». La habilidad está escrita para vivir con esto. Ninguna instrucción hace que un agente cumpla el 100% de las veces, y forzar más el punto restringe la creatividad del agente con poca ganancia; el bucle vale la pena aun cuando no se sigue estrictamente, porque los resultados siguen siendo mejores en general. Si la adherencia estricta importa para un segmento concreto, vigila la ejecución en vez de confiar en que la habilidad lo imponga.

¿Debería escribir primero pruebas de navegador o end-to-end?

Normalmente no, y la habilidad no lo impedirá. Un usuario reportó al agente escribiendo primero una prueba de Playwright, luego quemando un bucle largo reejecutándola y concluyendo que la prueba estaba rota para una funcionalidad que aún no existía. Configura esto en tu CLAUDE.md. Las pruebas de navegador son lo bastante lentas para que el bucle de retroalimentación rojo-verde deje de rentar; declara en el CLAUDE.md de tu repositorio que se escriben después de que el comportamiento funciona.

¿/tdd reemplaza a /implement, o al /do-work del curso?

No. /tdd documenta la metodología; /implement es un bucle muy simple de trabajo→retroalimentación→commit y es el sustituto directo de /do-work. El único paso /do-work del curso ahora está dividido en /implement, /tdd y /code-review. Si preguntas cuál ejecutar contra un ticket, la respuesta es casi siempre /implement.

¿A dónde se fue la guía de módulos profundos y diseño de interfaces?

A codebase-design en v1.0, generalizada para que varias habilidades compartan un vocabulario. refactoring.md salió a la vez; refactorizar ahora es trabajo de code-review, y esa habilidad trae la base de olores de Fowler.

¿Conoce mis otros tickets?

No. Ejecutada contra un ticket, propondrá con gusto trabajo que pertenece a un ticket hermano, porque no ve el resto del grafo de incidencias (issue #129). La posición de Matt es que ese no es trabajo de tdd. Pasar la especificación junto al ticket ayuda; dimensionar bien los tickets desde el inicio ayuda más.

Funciona si

• Se detiene y nombra las costuras donde pretende probar, y espera, antes de que exista ningún archivo de pruebas.
• Aparece una prueba, se pone en rojo, recibe el código justo para pasar, y solo entonces aparece la siguiente prueba, no un lote de pruebas seguido de un lote de código.
• Los nombres de pruebas se leen como capacidades («el usuario puede pagar con carrito válido»), no como internos («checkout llama a paymentService.process»).
• Los valores esperados en las aserciones son literales rastreables a la especificación, no valores recalculados como los calcula el código.
• Renombrar una función interna no rompe nada en la suite.
• Los mocks aparecen solo en límites externos (la API de pagos, el reloj) y nunca alrededor de tus propios módulos.

Dónde encaja

tdd es el motor dentro del paso de construcción de la cadena principal, más que un paso propio:

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

to-spec acuerda las costuras de prueba por adelantado, implement impulsa tdd por ticket, y code-review comprueba después que solo se usaron las costuras acordadas, y es dueña de la refactorización que tdd ya no hace. Su otra vecina es codebase-design, la fuente compartida del vocabulario de costuras y módulos profundos que tdd habla. También puedes recurrir a ella sola, cuando haya un comportamiento concreto que construir y no haya especificación completa en juego. Cuando dudes qué habilidad encaja en tu situación, ask-matt te dirige.