Cap 3: Ciclo Sprint — Think → Ship

Las 7 fases del Sprint

gstack organiza el desarrollo en un ciclo de 7 fases donde cada una alimenta a la siguiente:

flowchart LR
    T[Think] --> P[Plan]
    P --> B[Build]
    B --> R[Review]
    R --> TS[Test]
    TS --> S[Ship]
    S --> RF[Reflect]

Fase 1 — Think

Skill: /office-hours

Antes de escribir una línea de código, reformula el problema. El skill conduce seis preguntas de forcing al estilo YC:

• ¿Qué evidencia tienes de que esto es necesario?
• ¿Cuál es el status quo sin esta feature?
• ¿Qué está haciendo el usuario ahora mismo en su lugar?
• ¿Cuál es el wedge más pequeño para empezar?
• ¿Qué hace que esto sea 10 veces mejor que lo existente?
• ¿Qué te haría abandonar esta idea?

Output: DESIGN.md con el design doc que alimenta todas las fases siguientes.

Fase 2 — Plan

Tres reviews en secuencia, cada uno con un lente diferente:

graph TD
    DM[DESIGN.md] --> CEO[/plan-ceo-review/]
    CEO --> DSN[/plan-design-review/]
    DSN --> ENG[/plan-eng-review/]
    ENG --> ARCH[Arquitectura bloqueada]

Skill	Foco
/plan-ceo-review	Scope correcto — ¿estamos construyendo lo verdaderamente valioso?
/plan-design-review	UX y visual — rating 0-10 por dimensión
/plan-eng-review	Arquitectura, data flow, edge cases, matriz de tests

O todo en uno con /autoplan (CEO → Design → Eng en secuencia).

Fase 3 — Build

Implementación con el contexto completo de los artefactos anteriores. Los skills de diseño generan código real:

• /design-consultation → sistema de diseño + mockups
• /design-shotgun → 3 variantes visuales para elegir
• /design-html → HTML de producción desde mockups aprobados

Fase 4 — Review

Skill: /review

Staff engineer en modo paranóico. Busca bugs que pasan CI pero rompen producción:

• Queries N+1
• Race conditions
• Violaciones de trust boundary
• Enum handlers olvidados
• Problemas de migración de datos

Auto-corrige issues mecánicos, escala los ambiguos.

Segunda opinión: /codex (OpenAI) para cross-model analysis.

Fase 5 — Test

graph LR
    QA[/qa/] --> BUG[Bug encontrado]
    BUG --> FIX[Fix + commit atómico]
    FIX --> REG[Test de regresión generado]
    REG --> QA
    QA --> DONE[Sin bugs]

• /qa — Test en navegador real, diff-aware, auto-genera tests de regresión
• /qa-only — Solo reporta, no modifica código
• /cso — Auditoría OWASP Top 10 + STRIDE threat modeling
• /benchmark — Core Web Vitals y tiempos de carga baseline

Fase 6 — Ship

Skill: /ship

Release machine completa:

1. Sync con main
2. Ejecuta tests
3. Audita cobertura de tests
4. Push al remote
5. Abre PR con resumen de tests (ej: “Tests: 42 → 47 (+5 nuevos)”)

Si no hay framework de tests, lo bootstrapea automáticamente.

Completar el ciclo: /land-and-deploy mergea el PR, espera CI, deploya y verifica producción.

Fase 7 — Reflect

Skill: /retro

Retrospectiva semanal consciente del equipo:

• Breakdown por persona
• Streaks de shipping
• Tendencias de salud de tests
• Los ships más grandes del período

Artefactos que persisten

Cada skill escribe en ~/.gstack/projects/ y los siguientes los leen:

graph LR
    OH[office-hours\nDESIGN.md] --> CEO
    CEO[plan-ceo-review\nscope.md] --> ENG
    ENG[plan-eng-review\narchitecture.md] --> QA
    QA[qa\ntest-matrix.md] --> SHIP
    SHIP[ship\nPR] --> LAND

Ejecución en paralelo

Con Conductor se pueden correr 10-15 sprints simultáneos en workspaces aislados:

• Sesión A: /office-hours para feature nueva
• Sesión B: /review en PR abierto
• Sesión C: implementación del sprint anterior
• Sesión D: /qa en staging

Cada sesión tiene su propio contexto sin interferir con las otras.