joris887/exosuit

---

build

Construye un proyecto a partir de una descripción en lenguaje natural. Orquesta la configuración, planificación e implementación automáticamente.

Toda la salida dirigida al usuario DEBE ser en español sencillo. Sin jerga: sin "TDD", "sprint", "PR", "squash merge", "CI/CD", "ORM", "middleware". Si un término técnico es inevitable, explícalo entre paréntesis.

Argumentos

$ARGUMENTS — una descripción en español sencillo de lo que se va a construir (p. ej., "una aplicación de gestión de tareas con cuentas de usuario y fechas límite").

Fase 0: Verificar Configuración

Lee el perfil actual desde CLAUDE.md. Si no es lean, anota el perfil pero continúa — /build siempre usa estilo lean internamente sin importar el perfil del proyecto.

Fase 1: Descomponer

Muestra: "Planificando lo que hay que construir..."

Descompón internamente la descripción en historias ordenadas usando la lógica /ideate:

1. Identifica las entidades y funcionalidades principales descritas
2. Divide en pasos de implementación ordenados por dependencias
3. Clasifica cada uno como funcionalidad, infraestructura o prueba
4. Dimensiona cada paso (apunta a pasos que toquen ≤5 archivos)

NO muestres nada de esto al usuario. Sin tipos de historia, sin SPIDR, sin etiquetas de prioridad, sin terminología de metodología. Mantén la descomposición interna.

Crea un plan interno simple (no se muestra al usuario):

steps:
  - summary: "Configurar las tablas de la base de datos"
    type: infrastructure
    files: [...]
  - summary: "Construir los endpoints de la API"
    type: feature
    files: [...]
  - summary: "Agregar autenticación de usuario"
    type: feature
    files: [...]
  - summary: "Escribir pruebas"
    type: testing
    files: [...]

Captura de Descubrimiento (Retroactiva)

Captura silenciosamente el contexto de descubrimiento para futuras revisiones de fase — el usuario NO ve esto:

1. Infiere el arquetipo a partir de la descripción (clasificar contra los 10 arquetipos en .claude/skills/discover/references/scale-guide.md)
2. Establece la escala como Quick Build
3. Genera automáticamente un docs/reference/DECISION_LOG.md mínimo (copia la plantilla de .claude/skills/discover/assets/decision-log.md), registrando todas las decisiones técnicas con confianza: ASSUMED
4. Incluye las Historias de Transición de Fase (E0N-REVIEW: variante rápida de 3 historias — E0N-001, E0N-004, E0N-006) como último paso interno
5. Guarda la clasificación en vision/classification.md

Esto asegura que los usuarios de /build obtengan el ciclo de revisión sin fricción inicial.

Fase 2: Ejecutar

Para cada paso en orden de dependencias:

1. Muestra el progreso en español sencillo:

   • "Configurando la base de datos..." / "Construyendo la API..." / "Agregando el inicio de sesión..." / "Escribiendo pruebas para asegurar que todo funcione..."
   • Usa un lenguaje que el usuario entienda. Nunca: "Ejecutando historia E01-003 (tipo: funcionalidad, tamaño: ESTÁNDAR)"

2. Ejecuta usando el comportamiento Lean del ciclo de historia:

   • Planifica (ligero — sin puntuación de confianza)
   • Construye con TDD cuando sea no trivial (ejecuta pruebas, no expliques la metodología TDD)
   • Verifica que las pruebas pasen
   • Haz commit con formato convencional (no expliques las convenciones de commit)

3. Toma todas las decisiones técnicas en silencio:

   • Elecciones de framework/biblioteca: elige la mejor opción, documéntala en un resumen final
   • Arquitectura: sigue patrones estándar para el stack detectado
   • Estructura de archivos: sigue las convenciones existentes del proyecto o los valores predeterminados del stack detectado
   • Solo detente para ambigüedades genuinas de producto: "El diseño podría ir por dos caminos: [A] o [B]. ¿Cuál prefieres?"
   • Nunca te detengas por: elección de base de datos, estilo de API, nombres de archivos, framework de pruebas, estructura de carpetas

4. Maneja los fallos con elegancia:

   • Si un paso falla después de 2 intentos, saltalo con una nota: "No pude hacer que [X] funcionara automáticamente. Esto es lo que hay que hacer manualmente: [descripción]"
   • Continúa con los pasos restantes — no bloquees toda la construcción

Fase 3: Completar

3A. Lanzar y Verificar (si aplica)

Verifica los Comandos de CLAUDE.md para un comando dev:. Si hay uno configurado:

1. Muestra: "Iniciando tu proyecto..."
2. Ejecuta el comando dev en segundo plano usando Bash con run_in_background: true
3. Espera unos segundos. Lee cualquier salida — busca URLs, puertos, rutas de archivo o mensajes de estado.
4. Muestra lo que produzca el comando. Si genera una URL, resáltala. Si es una CLI, muestra la salida de ayuda. Si inicia un servidor, muestra la dirección.
5. Pregunta: "¡Échale un vistazo y dime qué te parece!"
6. Espera la respuesta. Positiva → continúa con el informe de finalización. Problemas → corrige y vuelve a ejecutar.

Si no hay un comando dev configurado (librerías, paquetes, pipelines, etc.) → salta este paso. Las pruebas ya verificaron la construcción.

NO asumas localhost ni ninguna URL específica. Lee la salida real del comando. Diferentes proyectos producen diferentes resultados.

3B. Informe de Finalización

Muestra un informe de finalización en español sencillo:

## ¡Todo Listo!

### Lo Que Se Construyó
- [Funcionalidad 1]: [descripción en español sencillo de lo que hace]
- [Funcionalidad 2]: [descripción]
- ...

### Archivos Creados/Modificados
- `src/models/user.ts` — Modelo de datos de usuario
- `src/api/auth.ts` — Endpoints de inicio de sesión y registro
- ...

### Pruebas
- [N] pruebas escritas, todas pasando

### Decisiones Técnicas Tomadas
- **Base de datos:** PostgreSQL (confiable, gratuita, funciona bien con [framework])
- **Autenticación:** [enfoque elegido] — [razón de una línea]
- ...

### Pruébalo
[Si el comando dev se ejecutó: "Tu proyecto está funcionando — mira arriba"]
[Si el comando dev existe pero no se lanzó: "Ejecuta `[comando dev]` para iniciar"]
[Si no hay comando dev: omite esta sección]

### Próximos Pasos
- [Sugerencia 1, p. ej., "Agrega un sistema de pagos con /build 'Integración de pagos con Stripe'"]
- [Sugerencia 2]

Reglas

• Solo español sencillo — cada mensaje dirigido al usuario debe ser comprensible para alguien que nunca ha programado
• Decisiones técnicas silenciosas — elige buenos valores predeterminados, documéntalos en el informe de finalización, nunca preguntes
• Detente solo para preguntas de producto — "¿Los usuarios deberían poder eliminar su cuenta?" es válida. "¿REST o GraphQL?" no lo es.
• Los hooks de seguridad aún se ejecutan — detección de secretos, protección de git y ejecución de pruebas ocurren de forma invisible
• Ejecución lean — sin envío de agente de calidad, sin especificaciones de sprint, sin retrospectivas, sin generación de documentación más allá de lo necesario para trabajar
• Saltar con elegancia — los pasos fallidos se anotan, no son fatales. La construcción continúa.
• Una sesión — la primera versión de /build se completa en una sola sesión. Las construcciones multi-sesión son trabajo futuro.