← Volver al listado de tecnologías ← Índice de gstack

Cap 4: Skills de Planificación

Por: Artiko
gstackplanningoffice-hoursautoplan

Visión general

Los skills de planificación de gstack aplican diferentes lentes al mismo problema antes de codificar. El flujo natural es:

flowchart TD
    OH[/office-hours/] -->|genera DESIGN.md| CEO[/plan-ceo-review/]
    CEO -->|valida scope| DSN[/plan-design-review/]
    DSN -->|valida UX| ENG[/plan-eng-review/]
    ENG -->|arquitectura bloqueada| IMPL[Implementación]

    AUTO[/autoplan/] -->|ejecuta los 3 en secuencia| IMPL

/office-hours

El skill más importante. Actúa como socio de YC en session de office hours.

Qué hace:

Cuándo usarlo: Antes de iniciar cualquier feature nueva o trabajo significativo.

Preguntas que plantea:

  1. ¿Qué evidencia tienes de que esto es un problema real?
  2. ¿Qué hace el usuario HOY sin esta solución?
  3. ¿Cuál es el cambio más pequeño que valida el supuesto?
  4. ¿Qué te haría abandonar esta idea completamente?
  5. ¿Qué hace esta solución 10x mejor que lo existente?
  6. ¿Quién más tiene este problema y en qué magnitud?

/plan-ceo-review

Actúa en “founder mode”: visión holística, menos consenso, más convicción.

4 modos de operación:

ModoCuándo usarlo
Scope ExpansionEl problema real es mayor que el planteado
Selective ExpansionExpandir solo partes específicas
Hold ScopeEl scope actual es correcto, no tocar
Scope ReductionDemasiado ambicioso, reducir para lanzar rápido

Qué produce:

/plan-eng-review

Engineering lead que bloquea la arquitectura antes de codificar.

Qué produce:

Principio: “Hacer la idea construible”, no más pequeña.

Ejemplo de matriz de tests:

| Escenario | Tipo | Prioridad |
|-----------|------|-----------|
| Usuario sin auth accede a recurso privado | Seguridad | Alta |
| Red lenta en upload de archivo grande | Performance | Media |
| Dos usuarios editan el mismo registro | Concurrencia | Alta |

/plan-design-review

Senior designer revisando el plan antes de la implementación.

Sistema de rating 0-10 por dimensión:

radar
    title Rating de diseño pre-implementación
    "Claridad visual" : 7
    "Jerarquía información" : 6
    "Consistencia" : 8
    "Estados vacíos" : 4
    "Estados de error" : 5
    "Accesibilidad" : 6

Para cada dimensión con rating bajo, el skill:

  1. Explica qué sería un 10
  2. Edita el plan directamente para alcanzarlo
  3. Marca los riesgos de diseño pre-código

Especialmente útil para detectar:

/autoplan

Ejecuta CEO → Design → Eng review en secuencia automática.

# Equivalente a ejecutar los 3 en orden
/autoplan

Solo sube al usuario las decisiones de taste — el resto lo decide automáticamente usando principios codificados.

Cuándo usar /autoplan vs la secuencia manual:

Flujo completo de ejemplo

Usuario: "Quiero agregar notificaciones push a mi app"

/office-hours →
  Pregunta 1: ¿Qué evento específico dispara la notificación?
  Pregunta 2: ¿Cómo se entera el usuario de ese evento ahora?
  Pregunta 3: ¿Cuántos usuarios activos tienes para validar esto?
  ...
  Output: DESIGN.md con "El problema real es retención en D7,
  no notificaciones. Primer paso: email digest diario,
  medir apertura antes de push."

/plan-ceo-review →
  Modo: Selective Expansion
  "Agregar preferencias de frecuencia desde el inicio —
  sin eso el churn de notificaciones destruye el canal"

/plan-eng-review →
  Arquitectura: Worker + Queue + Webhook receiver
  Edge cases: usuario desinstala, token expirado, rate limiting
  Matriz: 8 scenarios de test identificados
← Volver al listado de tecnologías ← Índice de gstack