Habilidades Workflow Patterns
📦

Workflow Patterns

Seguro

Domina el Flujo de Trabajo TDD con Conductor

Luchas con un flujo de desarrollo desorganizado y una cobertura de pruebas deficiente. Esta habilidad proporciona un marco TDD estructurado con puntos de control de fase, gestión de commits de git y protocolos de verificación para asegurar la calidad del código durante toda la implementación.

Soporta: Claude Codex Code(CC)
📊 69 Adecuado
1

Descargar el ZIP de la skill

2

Subir en Claude

Ve a Configuración → Capacidades → Skills → Subir skill

3

Activa y empieza a usar

Pruébalo

Usando "Workflow Patterns". Ayúdame a crear un commit de punto de control después de completar la Fase 1

Resultado esperado:

  • Ejecutando verificación automatizada...
  • Suite de pruebas: 47 pruebas pasaron
  • Cobertura: 87% (objetivo: 80%)
  • Linting: Sin errores
  • Commit de punto de control creado: def5678
  • Plan actualizado con SHA del punto de control
  • Esperando aprobación de verificación manual

Usando "Workflow Patterns". Guíame a través del flujo de trabajo TDD para la Tarea 2.1

Resultado esperado:

  • Paso 1: Seleccionar siguiente tarea - Tarea 2.1 marcada
  • Paso 2: Marcar como en progreso [~] en plan.md
  • Paso 3: RED - Escribir pruebas que fallan (test_validate_user_email)
  • Paso 4: GREEN - Implementar código mínimo (método validate_email)
  • Paso 5: REFACTOR - Extraer patrones, mejorar nombres
  • Paso 6: Verificar cobertura >= 80%
  • Paso 7: Documentar cualquier desviación
  • Paso 8: Crear commit estructurado
  • Paso 9: Adjuntar git notes con resumen
  • Paso 10: Actualizar plan.md con commit SHA
  • Paso 11: Hacer commit de actualización del plan

Auditoría de seguridad

Seguro
v1 • 2/25/2026

Static analysis detected 80 potential security issues in resources/implementation-playbook.md, all of which are false positives. The file contains Markdown documentation with bash code examples for educational purposes. The external_commands patterns are git command examples in code blocks (lines 25-571), not executable code. The weak_crypto findings are documentation text, not cryptographic implementations. This skill contains only documentation and no executable code, posing no security risk.

1
Archivos escaneados
622
Líneas analizadas
1
hallazgos
1
Auditorías totales
Problemas de riesgo medio (1)
resources/implementation-playbook.md:25-571
External Command Patterns in Documentation
Static scanner detected Ruby/shell backtick execution patterns at 65 locations in resources/implementation-playbook.md. These are all bash code examples within Markdown code blocks demonstrating git commands (git commit, git notes, git diff, pytest, etc.) for educational purposes. No executable code exists.
Auditado por: claude

Puntuación de calidad

38
Arquitectura
100
Mantenibilidad
87
Contenido
21
Comunidad
100
Seguridad
83
Cumplimiento de la especificación

Lo que puedes crear

Implementar Nueva Característica con TDD

El desarrollador implementa una nueva característica de autenticación de usuarios siguiendo el ciclo rojo-verde-refactor, con la cobertura de pruebas adecuada y commits de git en cada paso.

Establecer Puntos de Control de Fase

El líder del equipo crea puntos de control de verificación al final de cada fase de desarrollo para asegurar que se cumplan las puertas de calidad antes de continuar.

Rastrear el Progreso de Implementación

El desarrollador rastrea la finalización de tareas actualizando plan.md con los SHAs de commit y manteniendo la trazabilidad desde la planificación hasta el código.

Prueba estos prompts

Iniciar Implementación de Tarea TDD 
Estoy comenzando la Tarea 2.1: Implementar validación de usuario. Ayúdame a seguir el flujo de trabajo TDD para escribir primero las pruebas que fallan, luego implementar el código mínimo para pasar, y refactorizar para mayor claridad.
Crear Punto de Control de Fase 
He completado todas las tareas en la Fase 1. Ayúdame a crear un commit de punto de control con verificación: ejecutar la suite de pruebas completa, verificar cobertura por encima del 80%, y generar lista de verificación manual.
Formatear Commit de Git Estructurado 
Ayúdame a crear un mensaje de commit estructurado para la finalización de la Tarea 2.1 siguiendo el formato: type(scope): subject, body con viñetas, y footer con referencias a task/track.
Manejar Desviación de Implementación 
Durante la implementación descubrí que necesitamos un enfoque diferente al planeado. Ayúdame a documentar esta desviación apropiadamente en plan.md y tech-stack.md.

Mejores prácticas

  • Escribe siempre primero las pruebas que fallan (RED) antes de la implementación (GREEN) - nunca saltes la fase RED
  • Crea commits atómicos - un cambio lógico por commit con las pruebas pasando después de cada commit
  • Espera la aprobación explícita del usuario antes de continuar más allá de los puntos de control de fase - no saltes las puertas de verificación
  • Actualiza plan.md inmediatamente después de completar cada tarea con el SHA del commit para trazabilidad

Evitar

  • Escribir código de implementación antes de las pruebas - esto viola los principios de TDD y reduce la efectividad de las pruebas
  • Agrupar múltiples tareas en un solo commit - esto rompe la trazabilidad y hace difícil la reversión semántica
  • Proceder a la siguiente fase sin aprobación de punto de control - esto evita las puertas de calidad y arriesga acumular deuda técnica
  • Actualizar plan.md solo después de múltiples tareas - esto pierde trazabilidad y hace difícil la auditoría de progreso

Preguntas frecuentes

¿Qué es el ciclo RED-GREEN-REFACTOR?
RED significa escribir primero las pruebas que fallan. GREEN significa escribir el código mínimo para pasar las pruebas. REFACTOR significa mejorar la estructura del código manteniendo las pruebas en verde. Este ciclo asegura que las pruebas impulsen el desarrollo y el código se mantenga limpio.
¿Por qué necesito registrar los SHAs de commit en plan.md?
Registrar los SHAs de commit crea trazabilidad del plan al código. Permite operaciones de reversión semántica, auditoría de progreso, y ayuda a entender qué código implementa qué tarea específica.
¿Puedo proceder a la siguiente fase sin aprobación del punto de control?
No. La aprobación del punto de control es una puerta de calidad crítica. Proceder sin aprobación arriesga acumular problemas no detectados. Siempre espera la aprobaci��n explícita antes de pasar a la siguiente fase.
¿Qué debo hacer si la implementación se desvía del plan?
Documenta la desviación en plan.md con la razón y el impacto. Actualiza tech-stack.md si cambiaron las dependencias. Actualiza spec.md si cambiaron los requisitos. Esto mantiene la trazabilidad de decisiones.
¿Por qué usar git notes en lugar de poner todo en el mensaje del commit?
Git notes preservan contexto rico sin saturar los mensajes de commit. Permiten consultas semánticas a través de commits y soportan operaciones basadas en tracks mientras mantienen los commits concisos y escaneables.
¿Qué es el objetivo de cobertura del 80% y por qué es importante?
El objetivo de cobertura del 80% asegura pruebas exhaustivas del nuevo código. Equilibra minuciosidad con pragmatismo - 100% a menudo no es rentable, pero por debajo del 80% se arriesga perder caminos críticos.

Detalles del desarrollador

Autor

sickn33

Licencia

MIT

Repositorio

https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/workflow-patterns

Ref.

main

Estructura de archivos

📁 resources/

📄 implementation-playbook.md

📄 SKILL.md