Agent skill · software engineering · affaan-m
tdd-workflow
Usar este skill al escribir nuevas funcionalidades, corregir bugs o refactorizar código. Aplica el desarrollo guiado por pruebas con 80%+ de cobertura incluyendo pruebas unitarias, de integración y E2E.
Why this skill is useful
Provides a detailed TDD workflow with specific testing strategies and coverage requirements that the AI wouldn't reliably generate on its own.
What it needs
About 8k tokens when loaded. Last updated 2026-08-06. 238,342 stars on the source repository.
What this skill does
Flujo de Trabajo de Desarrollo Guiado por Pruebas Este skill garantiza que todo el desarrollo de código siga los principios TDD con cobertura de pruebas completa. Cuándo Activar Escribir nuevas funcionalidades Corregir bugs o problemas Refactorizar código existente Agregar endpoints de API Crear nuevos componentes Principios Fundamentales 1. Pruebas ANTES del Código SIEMPRE escribir primero las pruebas, luego implementar el código para que pasen. 2. Requisitos de Cobertura Mínimo 80% de cobertura (unit + integración + E2E) Todos los casos borde cubiertos Escenarios de error probados Condiciones de frontera verificadas 3. Tipos de Prueba Pruebas Unitarias Funciones y utilidades individuales Lógica de componentes Funciones puras Helpers y utilidades Pruebas de Integración Endpoints de API Operaciones de base de datos Interacciones entre servicios Llamadas a APIs externas Pruebas E2E (Playwright) Flujos críticos de usuario Flujos de trabajo completos Automatización del navegador Interacciones con la UI 4. Checkpoints de Git Si el repositorio está bajo Git, crear un commit de checkpoint después de cada etapa TDD No hacer squash ni reescribir estos commits de checkpoint hasta completar el flujo de trabajo Cada mensaje de commit de checkpoint debe describir la etapa y la evidencia capturada exacta Contar solo commits creados en la rama activa actual para la tarea actual No tratar commits de otras ramas, trabajo anterior no relacionado o historial lejano de ramas como evidencia válida de checkpoint Antes de tratar un checkpoint como satisfecho, verificar que el commit sea alcanzable desde el HEAD actual en la rama activa y pertenezca a la secuencia de la tarea actual El flujo de trabajo compacto preferido es: un commit para la prueba fallida agregada y ROJO validado un commit para la corrección mínima aplicada y VERDE validado un commit opcional para refactor completo No se requieren commits separados solo de evidencia si el commit de prueba claramente corresponde a ROJO y …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills affaan-m/tdd-workflow--e534b8