Communitygithub.com

kktbur/Inicio-VibeCoding

Una habilidad de gobernanza para Vibe Coding que evita que los proyectos se conviertan en desorden ingobernable generado por IA, estableciendo desde el primer día documentación clara, conocimiento del proyecto reutilizable, puertas de calidad, revisión independiente, pruebas, observabilidad y flujos de trabajo listos para reversión.

¿Qué es Inicio-VibeCoding?

Este skill proporciona un sistema de ingeniería ligero para Codex, desde la primera sesión del proyecto hasta el lanzamiento y la observación. Su objetivo es garantizar que cualquier sesión futura pueda entender, revisar, verificar, aceptar y continuar el proyecto de manera segura sin necesidad de repetir todo el historial del chat. Está diseñado para plataformas como Codex (y potencialmente Claude Code o Cursor) y establece un esqueleto mínimo de documentos (AGENTS.md, docs/INDEX.md, CURRENT.md, PRODUCT.md, PRD.md, ACCEPTANCE.md, CODEMAP.md) que define claramente el porqué, el qué y el cómo demostrar el proyecto. Además, impone puertas de ingeniería secuenciales (G0 a G9) que van desde el alcance inicial hasta la observación posterior al lanzamiento, promoviendo la reutilización sobre la construcción personalizada y requiriendo revisión adversarial independiente, verificación automatizada y aceptación humana antes de cualquier lanzamiento.

Compatible con~Claude Code✓Codex CLI~Cursor
npx skills add kktbur/VibeCoding-Start

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

¿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:

  1. docs/INDEX.md
  2. docs/CURRENT.md
  3. docs/PRODUCT.md
  4. docs/PRD.md
  5. docs/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.md y CODEMAP.md.
  • La complejidad cambia la profundidad del documento y la robustez de las puertas; no elimina el esqueleto.
  • PRODUCT.md explica el porqué, PRD.md explica el qué y ACCEPTANCE.md explica cómo demostrarlo. No combines estas responsabilidades en silencio.
  • Actualiza PRD.md cuando 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 a docs/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:

  1. Preserva los detalles sin procesar de la sesión y la salida grande en el directorio local .project-memory/.
  2. Selecciona y actualiza CURRENT.md y los documentos activos relevantes.
  3. Actualiza CODEMAP.md cuando la estructura cambie.
  4. Actualiza PRD.md cuando cambien los requisitos, funcionalidades, no-objetivos, restricciones o escenarios de usuario.
  5. Registra las decisiones materiales en un ADR.
  6. Actualiza los índices y el registro de trabajo.
  7. 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-knowledge para los procedimientos INIT, UPDATE o AUDIT.

Skills relacionados