¿Qué hace Inicio-VibeCoding?
Utiliza este Skill para dotar a Codex de un sistema de ingeniería ligero desde la primera sesión del proyecto hasta el lanzamiento y la observación. El resultado deseado es un proyecto que una sesión posterior pueda entender, revisar, verificar, aceptar y continuar de forma segura sin tener que repetir todo el chat.
Primera acción
Lee el archivo AGENTS.md del proyecto y luego sigue este orden de Contexto Activo:
docs/INDEX.mddocs/CURRENT.mddocs/PRODUCT.mddocs/PRD.mddocs/ACCEPTANCE.md
Lee docs/CODEMAP.md, ADRs activos, planes, registros de trabajo, estándares y evidencia local sin procesar solo cuando la tarea los requiera. Si falta el esqueleto de seis documentos, utiliza el modo INIT del skill compañero vibecoding-project-knowledge antes de la implementación.
Límite del proyecto no negociable
- Cada proyecto recibe el mismo esqueleto mínimo:
AGENTS.md,docs/INDEX.md,PRODUCT.md,PRD.md,ACCEPTANCE.md,CURRENT.mdyCODEMAP.md. - La complejidad cambia la profundidad del documento y la robustez de las puertas; no elimina el esqueleto.
PRODUCT.mdexplica el porqué,PRD.mdexplica el qué yACCEPTANCE.mdexplica cómo demostrarlo. No combines estas responsabilidades en silencio.- Actualiza
PRD.mdcuando la sesión cambie un requisito, funcionalidad, no-objetivo, restricción o escenario de usuario significativo. - Mantén las sesiones sin procesar, registros, intentos fallidos, investigaciones y evidencia de forma local por defecto en
.project-memory/. Promueve solo ejemplos depurados e intencionalmente seleccionados adocs/examples/. - Prefiere las capacidades existentes del proyecto, la biblioteca estándar, SDKs/APIs/herramientas oficiales, proyectos de código abierto maduros, paquetes, adaptadores o composición antes que la infraestructura personalizada.
- No construyas una base de datos de memoria, base de datos vectorial, motor de búsqueda, marco de pruebas, marco de despliegue, servicio de CI o backend de observabilidad como parte de este flujo de trabajo.
Puertas de ingeniería
Usa el mismo vocabulario para cada proyecto mientras escalas la profundidad según el riesgo:
G0 Alcance
→ G1 Intención
→ G2 Reutilización
→ G3 Plan
→ G4 Construcción
→ G5 Revisión Adversarial
→ G6 Verificación
→ G7 Aceptación Humana
→ G8 Lanzamiento
→ G9 Observación
G0 Alcance
Clasifica el trabajo como aplicación/producto, integración/adaptador o infraestructura/seguridad/tiempo de ejecución. Cuanto más cercano a infraestructura, más sólida debe ser la evidencia de reutilización, revisión y recuperación.
G1 Intención
Haz explícita la cadena:
PRODUCTO (Por qué) → PRD (Qué) → ACEPTACIÓN (Cómo demostrar)
Registra el problema, los usuarios, los estados actual y deseado, los requisitos funcionales, los no-objetivos, las restricciones, la aceptación y los riesgos antes de la implementación.
G2 Reutilización
Para cualquier capacidad general no trivial, busca antes de construir y decide en este orden:
USAR → ADAPTAR → COMPONER → CONSTRUIR → DETENER
Si se selecciona CONSTRUIR, registra las alternativas buscadas, las rutas de reutilización rechazadas, la responsabilidad de mantenimiento y el método de aceptación del propietario en un ADR. La capacidad de un modelo para escribir código no es evidencia de que el código personalizado sea la opción correcta.
G3 Plan
Divide el trabajo complejo en pequeños hitos con un punto de verificación después de cada hito. Detente y replanifica cuando el alcance, la arquitectura o el riesgo cambien materialmente.
G4 Construcción
Mantén la implementación pequeña y reversible. Utiliza el conjunto de herramientas existente y evita abstracciones, dependencias e infraestructura especulativas.
G5 Revisión Adversarial
Un revisor independiente examina PRODUCT.md, PRD.md, ACCEPTANCE.md, las decisiones activas, la estructura relevante, el diff y las pruebas. Busca omisiones, suposiciones incorrectas, regresiones, capacidades duplicadas, sobre-diseño, riesgos de seguridad/datos, brechas en las pruebas y fallos de reversión. El autor no debe ser el revisor final de un cambio importante.
G6 Verificación
Cubre los caminos normal, de error, de límite, de entrada no válida, de regresión y de recuperación en proporción al riesgo. Reporta evidencia automatizada y una explicación legible por el propietario; una marca verde prueba solo el invariante que realmente verifica.
G7 Aceptación Humana
El propietario confirma que el resultado es el producto previsto y que su comportamiento observable es comprensible. Las comprobaciones automatizadas y la revisión independiente no reemplazan este paso.
G8 Lanzamiento
Registra la versión, el último estado conocido bueno, las notas de la versión, la copia de seguridad, el método de reversión, el riesgo de migración y el objetivo de lanzamiento exacto antes del uso real.
G9 Observación
Después del lanzamiento, observa la salud y la evidencia del usuario. Continúa solo cuando esté saludable; detente y revierte o avanza cuando la evidencia muestre un problema. Realimenta el resultado en las pruebas, el registro de trabajo, el ADR, la intención del producto, la aceptación o una autopsia según corresponda.
Cierre de conocimiento
Al final de cada sesión sustancial, utiliza el modo UPDATE del skill compañero vibecoding-project-knowledge:
- Preserva los detalles sin procesar de la sesión y la salida grande en el directorio local
.project-memory/. - Selecciona y actualiza
CURRENT.mdy los documentos activos relevantes. - Actualiza
CODEMAP.mdcuando la estructura cambie. - Actualiza
PRD.mdcuando cambien los requisitos, funcionalidades, no-objetivos, restricciones o escenarios de usuario. - Registra las decisiones materiales en un ADR.
- Actualiza los índices y el registro de trabajo.
- Ejecuta las auditorías deterministas relevantes.
No reclames finalización sin evidencia automatizada, una explicación legible por humanos y un método de aceptación del propietario.
Referencias
- Lee Estándar v1.3 para las reglas normativas y el límite de lanzamiento.
- Lee el skill compañero
vibecoding-project-knowledgepara los procedimientosINIT,UPDATEoAUDIT.