vibe-build

Vibe Build

Un flujo de construcción completo que el agente ejecuta de forma autónoma. El usuario toma decisiones de producto; tú tomas decisiones de proceso. Nunca le pidas al usuario que explique el flujo de trabajo — síguelo. Pregúntale al usuario solo sobre qué construir, preferencias y aprobación en los puntos de control.

La única regla

Decisiones de producto = aporte del usuario. Proceso = tuyo. Antes de preguntarle algo al usuario, verifica si es una decisión de producto. Si no lo es, decídela tú mismo y continúa.

Fase 0 — Inicio (solo proyectos nuevos)

1. Identifica la pila. Si el proyecto está completamente indefinido, haz exactamente una pregunta: "¿Qué deberíamos construir? (una frase es suficiente)". No hagas una entrevista.
2. Investiga la pila tú mismo: versiones actuales de frameworks, configuración recomendada y estructura de proyecto estándar, usando búsqueda web y documentación de frameworks (usa la capacidad de consulta de documentación del proyecto o búsqueda web). Resume las decisiones en máximo 5 líneas — no pegues muros de investigación al usuario.
3. Escribe AGENTS.md en la raíz del proyecto usando la plantilla en references/agentsmd-template.md. Esta es la constitución del proyecto: cada fase posterior la lee antes de decisiones estructurales, para que el usuario nunca tenga que re-explicar convenciones.
4. Instala habilidades temporales que el proyecto necesite (máximo 5), siguiendo references/temp-skills.md. Omite la instalación de habilidades si el proyecto es simple o tus habilidades existentes lo cubren.
5. Reporta el inicio en ≤ 15 líneas, presenta tu plan numerado propuesto y espera la aprobación antes de escribir cualquier código del proyecto.

Fase 1 — Planificar

• Produce un plan numerado y con alcance definido. Tareas pequeñas que puedas hacer en una sesión, elementos explícitamente diferidos para después.
• Obtén aprobación explícita. Si el usuario edita el plan, los cambios ganan.
• Cuidado con la intercalación: no empieces a construir mientras el plan sigue abierto.

Fase 2 — Construir

• Sigue la disciplina de pruebas cuando sea adecuada para el proyecto: pruebas para lógica, verificación manual para pegamento desechable. No inventes marcos de pruebas pesados para construcciones simples; no omitas pruebas para lógica donde un error podría causar daño.
• Mantén las dependencias al mínimo. Cada dependencia es una responsabilidad que el usuario hereda — prefiere stdlib/sin dependencias a menos que haya un beneficio claro.
• Revisa AGENTS.md antes de cada decisión estructural. Haz commits en pasos pequeños y con nombre para que el trabajo sea biseccionable.

Fase 3 — Verificar (antes de declarar "listo")

Ejecuta el proyecto, luego demuestra que funciona:

• Si existe interfaz de usuario → navega por ella en un navegador real (Playwright o la herramienta de navegación de tu agente), verifica errores de consola, comprueba los flujos principales de extremo a extremo.
• Si hay interfaz web → audita la accesibilidad y la calidad de interacción (estados de foco, formularios, modo oscuro, táctil): usa una habilidad de revisión de pautas de diseño si está disponible, si no, haz la autoverificación.
• Si se tocan autenticación, secretos, pagos o entrada de usuario → realiza una revisión de seguridad: validación de entrada, manejo de secretos (nunca commits de secretos; usa sustitución de entorno), valores predeterminados de mínimo privilegio.
• Evidencia antes de afirmaciones: informa qué se ejecutó y qué pasó, o admite que falló y primero arréglalo.

Fase 4 — Desplegar

• "Desplegar / publicar en vivo / enlace de vista previa" → despliega a través de la ruta documentada del proyecto. Para proyectos alojables en Vercel, haz git-push al proyecto vinculado, recurre a vercel deploy --temporary cuando no exista inicio de sesión, y devuelve la URL.
• Pull requests: cuerpo conciso — qué cambió, por qué, cómo probar — no narración del diff.
• Un commit "listo" significa que la compilación + pruebas pasan con la evidencia que acabas de recopilar.

Fase 5 — Higiene de habilidades temporales

Las habilidades temporales (Fase 0 paso 4) tienen alcance de proyecto. Al final del proyecto o cuando una habilidad temporal demuestre ser ampliamente útil, recomienda promocionarla al directorio de habilidades compartidas del usuario (o eliminarla). Nunca permitas que las habilidades temporales muten silenciosamente en instalaciones globales permanentes.

Ahorro de tokens (todas las fases)

Lee el rango de archivo más pequeño suficiente; no vuelvas a leer archivos completos que ya hayas visto. Resume una fase completada una vez en lugar de narrar cada paso. Prefiere ejecutar scripts y herramientas en lugar de pegar su contenido en el chat. Permite que las habilidades se carguen de forma perezosa según el desencadenante — nunca vuelques el cuerpo de una habilidad en la conversación.

Referencias

• references/agentsmd-template.md — lee y completa durante la Fase 0 paso 3.
• references/temp-skills.md — lee durante la Fase 0 paso 4, antes de instalar cualquier habilidad temporal.