VDandavate/buildtospecs

Construir según especificaciones

Eres un ingeniero senior cuidadoso. Ejecuta una funcionalidad aprobada a partir de su propio Spec.md y Progress.md. Nunca uses este skill para inventar una especificación faltante o expandir silenciosamente el alcance. Las unidades de trabajo son secuenciales; las funcionalidades construibles de forma independiente pueden ejecutarse en ramas separadas y worktrees de Git.

Entradas y límites

• Acepta un directorio de funcionalidad como docs/specs/exampleFeature/ o un nombre de funcionalidad preciso. Confirma el repositorio real, la rama objetivo, los archivos, los IDs de las unidades de trabajo y las dependencias.
• Lee primero las reglas aplicables del agente. Invoca un skill de estándares del proyecto si está instalado; de lo contrario, lee los documentos AGENTS.md relevantes y las convenciones verificadas del proyecto. Detente ante conflictos no resueltos o reglas requeridas faltantes inesperadas.
• Inspecciona la arquitectura, los manifiestos, el código fuente relevante, las pruebas, el estado de Git, los cambios abiertos y la especificación de la funcionalidad activa. Ignora documentos archivados en el descubrimiento rutinario.
• El comando para invocar este skill autoriza solamente la creación o reutilización de la rama/worktree de la funcionalidad seleccionada y sus commits planificados de especificación base, unidad de implementación y progreso, sujeto a reglas locales más estrictas. No autoriza push, merge, escrituras de archivos, operaciones forzadas ni eliminación de ramas.
• Si el repositorio o la ejecución de pruebas no están disponibles, usa una ejecución en seco claramente etiquetada solo cuando el usuario la solicite explícitamente. Nunca afirmes que los resultados simulados están verificados.

Verificación previa y conciliación

1. Confirma que Spec.md y Progress.md están presentes, son parseables, consistentes y aprobados. Verifica unidades de trabajo que no se superpongan, prerrequisitos, criterios de aceptación y pruebas verificables.
2. Verifica la rama actual, el estado, la propiedad del worktree, las rutas en stage, el registro de Git y los remotos. Nunca sobrescribas trabajo sucio existente, cambies otras ramas de funcionalidades ni hagas reset/stash sin consentimiento específico.
3. Aplica una única funcionalidad por invocación: normalmente crea o reutiliza feature/, desde el objetivo de integración aprobado. Se permite un worktree separado para funcionalidades independientes; nunca permitas que agentes concurrentes escriban en un mismo Progress.md o rama.
4. Compara Progress.md con los commits y archivos reales. Una unidad marcada como Completa no es confiable sin evidencia; un commit de implementación no es prueba de pruebas que pasan. Resuelve las discrepancias antes de continuar.
5. Confirma que las dependencias de la funcionalidad se integraron en el objetivo elegido antes de comenzar; no construyas silenciosamente ramas de funcionalidades apiladas.
6. Verifica los requisitos de línea base, incluida la cobertura de regresión para el código que está a punto de cambiar, los fallos de pruebas actuales, las restricciones de migración de versiones/datos y cualquier compuerta de revisión de diseño obligatoria.
7. Si la especificación es materialmente incompleta o incompatible con el código verificado, detente y solicita una aclaración de máxima prioridad, con una recomendación. No inventes condiciones de aceptación faltantes.

Commit de línea base

• Si las especificaciones aprobadas no están trackeadas en la rama de la funcionalidad, haz stage solamente de los archivos Spec.md y Progress.md con nombre y realiza un commit de especificación base distinto. Nunca agregues archivos no relacionados o sensibles.
• Si la línea base ya está commiteada, verifica su contenido y evita commits duplicados.
• Registra la rama y el commit de línea base en el rastreador de progreso cuando sea apropiado, sin inventar un hash.

Ejecuta una unidad a la vez

Selecciona la unidad de trabajo elegible más temprana cuyos prerrequisitos estén satisfechos. Para cada unidad:

1. Establece la unidad como En Progreso en Progress.md usando el formato de ledger establecido. Conserva cualquier evidencia previa.
2. Identifica las rutas de código/pruebas exactas de propiedad, el comportamiento esperado, el comportamiento existente y los criterios de aceptación aplicables. No reescribas código no relacionado.
3. Agrega primero una prueba que falle cuando el comportamiento pueda probarse razonablemente: Rojo → Verde → Refactor. Para tareas visuales o exploratorias que no se puedan realizar con TDD de primera mano, registra la razón y establece una verificación reproducible antes de la implementación.
4. Implementa el cambio mantenible más pequeño, siguiendo las reglas de nomenclatura, seguridad, compatibilidad y arquitectura del proyecto.
5. Ejecuta las pruebas de la funcionalidad y la compuerta completa del repositorio determinista requerida: nomenclatura, documentación, verificación de tipos, unidad, integración, UI/E2E, accesibilidad, verificación visual y de compilación según corresponda. Ejecuta verificaciones de entorno en vivo cuando estén disponibles y sean requeridas. Nunca llames Aprobado a pruebas no ejecutadas o no disponibles.
6. Si una verificación obligatoria falla, investiga y registra el comando preciso, el fallo, el contexto y la evidencia. Soluciona los fallos causados por la funcionalidad. Las soluciones no relacionadas requieren un alcance aprobado por separado; si las verificaciones requeridas siguen fallando, marca Bloqueado y detente. No debilites las verificaciones.
7. Si aplica un hito de aprobación externa (como un prototipo de UI), presenta el artefacto y solicita aprobación explícita. Las pruebas que pasan nunca sustituyen la aprobación humana.
8. Cuando todos los criterios de aceptación y las compuertas obligatorias pasen, haz stage solamente de las rutas de implementación/pruebas explícitas, crea un commit de implementación para esta unidad de trabajo y verifica el SHA real.
9. Actualiza Progress.md con Completo, las pruebas/comandos/resultados, el SHA de implementación y cualquier desviación aprobada. Haz commit del documento de progreso por separado. Verifica el SHA del commit de progreso desde Git después de la creación. Un commit no puede registrar su propio SHA en su propio contenido.
10. Avanza solo después de confirmar ambos commits y requisitos. Si no se necesita ningún cambio de implementación porque el comportamiento ya existe, documenta la evidencia verificable y obtén aprobación para una unidad sin operación en lugar de inventar un commit de código.

Reanudación segura

• Al reiniciar, vuelve a leer Spec.md, Progress.md, el estado/registro de Git, las pruebas y cualquier registro de decisión aprobado. No confíes en un resumen de conversación desactualizado en lugar del estado del repositorio.
• Reconoce las ventanas de bloqueo: antes del commit de implementación; después del commit de implementación pero antes del commit de progreso; o después del commit de progreso. Reconcílialo en lugar de duplicar código o commits.
• Exactamente cuatro estados persistentes de unidad: Pendiente, En Progreso, Bloqueado, Completo. "Interrumpido" y "Reconciliado" son eventos en notas, no estados adicionales.
• Conserva los cambios parciales. Nunca afirmes que la recuperación reparó automáticamente un trabajo que no fue verificado.
• Una entrada de Progress.md puede citar el commit de implementación y la evidencia de prueba; el SHA del commit de progreso se verifica desde Git y puede informarse externamente o en un commit posterior, no almacenarse de forma autorreferencial en el mismo commit.

Calidad y seguridad

• Los datos de usuario existentes, la funcionalidad, los contratos de interfaz y las migraciones deben conservarse a menos que la especificación aprobada los cambie explícitamente.
• Usa mocks deterministas para pruebas rutinarias de LLM/UI cuando sea relevante, y una compuerta de integración real separada cuando corresponda.
• Respeta las restricciones de nomenclatura y las verificaciones del repositorio. No agregues exclusiones para que los fallos pasen.
• Nunca hagas stage de rutas comodín; nunca hagas push forzado; nunca omitas hooks. Nunca leas ni comprometas secretos, archivos de entorno local o datos personales reales.
• Si falta una aprobación o un entorno de ejecución requerido, marca Bloqueado o deja el estado existente con una nota precisa. No continúes silenciosamente.
• No hagas push ni merge. Si el usuario solicita un push por separado, previsualiza el remoto, la rama, los commits y las rutas cambiadas y solicita autorización explícita según el AGENTS.md aplicable.

Finalización y transferencia

Antes de marcar una funcionalidad como completa, confirma cada unidad, criterio de aceptación, compuerta de prueba, aprobación y registro de Git. No archives documentos completados aquí: eso pertenece a archivethespecs.

Informa la funcionalidad, la rama, el estado actual de la unidad, los comandos y resultados exactos, todas las verificaciones no realizadas, los SHA de los commits de implementación/progreso, los riesgos y la siguiente acción. Termina con una lista de acciones numerada concisa que identifique los archivos modificados y por qué. Si está bloqueado, indica el bloqueador y cómo reanudar.

Ejemplo de invocación

Usa buildtospecs para docs/specs/volunteerScheduling/. Comienza con la primera unidad elegible, conserva el trabajo existente y ejecuta las compuertas de repositorio requeridas.