Elcano Superpowers

# Superpowers — Desarrollo estructurado con sub-agentes

Adaptado de [obra/superpowers](https://github.com/obra/superpowers) para OpenClaw.

## Cuándo activar

Cuando Chema o Luis pidan una **feature nueva, refactor grande, o cambio multi-archivo** en cualquier proyecto (Elicita, FlightCBT, etc.). NO para fixes de una línea o cambios cosméticos.

## El flujo

```
1. BRAINSTORM → 2. PLAN → 3. EXECUTE → 4. REVIEW → 5. SHIP
```

---

## 1. BRAINSTORM (obligatorio)

**HARD GATE: NO escribir código hasta tener diseño aprobado.**

Incluso si parece simple. "Simple" es donde las asunciones matan.

### Pasos:
1. **Explorar contexto** — leer archivos relevantes, commits recientes, estado actual
2. **Preguntar** — UNA pregunta a la vez, preferir opciones múltiples
3. **Proponer 2-3 enfoques** — con trade-offs y tu recomendación
4. **Presentar diseño** — en secciones digeribles, esperar OK antes de avanzar
5. **Guardar diseño** — `docs/plans/YYYY-MM-DD-<feature>-design.md`

### Qué cubrir:
- Arquitectura / componentes afectados
- Flujo de datos
- Manejo de errores
- Cómo se testea
- Impacto en lo existente

---

## 2. PLAN

Después del diseño aprobado, escribir plan de implementación.

### Reglas del plan:
- Guardar en `docs/plans/YYYY-MM-DD-<feature>-plan.md`
- Cada tarea = **2-5 minutos** de trabajo
- **Paths exactos** de archivos a crear/modificar
- **Código completo** en el plan (no "añadir validación")
- **Comandos exactos** con output esperado
- DRY, YAGNI, commits frecuentes

### Estructura de tarea:

```markdown
### Tarea N: [Nombre]

**Archivos:**
- Crear: `ruta/exacta/archivo.ts`
- Modificar: `ruta/exacta/existente.ts`
- Test: `tests/ruta/test.ts`

**Paso 1:** Escribir test que falle
[código completo del test]

**Paso 2:** Verificar que falla
Ejecutar: `npm test -- --grep "nombre"`
Esperado: FAIL

**Paso 3:** Implementación mínima
[código completo]

**Paso 4:** Verificar que pasa
Ejecutar: `npm test -- --grep "nombre"`
Esperado: PASS

**Paso 5:** Commit
`git add ......