Elcano Superpowers

Facilita desarrollo estructurado con sub-agentes para features, refactors grandes y cambios multi-archivo siguiendo diseño aprobado y TDD.

Security Scan

The skill's instructions align with its stated goal (structured TDD-driven multi-file changes) but they expect unrestricted access to repository files, git operations, test/runtime commands, and process restarts while declaring no required credentials or environment details — an incoherence that could lead to unintended or dangerous actions if run autonomously.

Purpose & Capability

The name/description (structured development with sub-agents, TDD, multi-file changes) matches the SKILL.md: it describes planning, tests-first tasks, commits, and sub-agent execution. However, the skill declares no required env vars, binaries, or config paths even though its workflow explicitly requires filesystem and VCS access, a test runner (npm), and deployment/runtime control (PM2). The missing declarations are a proportionality/visibility gap rather than a direct mismatch in purpose.

Instruction Scope

The SKILL.md instructs the agent to read repository files and recent commits, create and modify exact file paths, run tests (npm test), commit, git push, and restart PM2 — plus produce screenshots for UI tasks. It also prescribes spawning fresh sub-agents per task. Those are powerful actions that go beyond passive guidance: they are operational steps that can modify code and production state. The instructions do not explicitly require an explicit human approval gate for git push / PM2 restart (the plan approval gate exists but could be automated), nor do they limit what paths/branches may be modified. This broad operational scope is noteworthy and could be dangerous if executed without strict human control.

Install Mechanism

Instruction-only skill with no install spec and no code files — lowest install risk. Nothing will be written to disk by an installer as part of skill setup.

Credentials

The skill requests no environment variables or credentials in its manifest, but its runtime instructions require capabilities that typically depend on credentials or privileged access: git push (SSH keys or git credentials), running npm tests (node/npm installed), and restarting PM2 (server/process control). The absence of declared required credentials/config paths is an incoherence: a legitimate implementer should document what credentials, user accounts, or host access the skill expects and what minimum privileges are needed.

Persistence & Privilege

always is false (good) and autonomous invocation is allowed (the platform default). The real risk is operational: the skill's normal flow includes git push and PM2 restarts, which can be executed by an agent if allowed. That combination (autonomous invocation + ability to perform repo pushes and process restarts) increases blast radius but is not in itself flagged by the skill metadata — users should ensure manual gating or least-privilege controls before enabling autonomous runs.

What to consider before installing

This skill is coherent in purpose (it prescribes careful planning, tests-first implementation, and reviews) but it instructs the agent to perform powerful repo and runtime operations while declaring no credentials or environment requirements. Before installing or enabling this skill: - Require explicit human approval for any 'git push', 'deploy' or 'PM2 restart' steps (do not allow automatic pushes to protected branches or automatic restarts without manual confirmation). - Restrict agent permissions: give it read-only access where possible during planning; provide narrowly scoped deploy keys/accounts for any required pushes and restarts; prefer CI/CD for final pushes and deploys. - Verify local tooling: ensure node/npm, test runners, and PM2 are available in the runtime environment and understand which user account will execute commands. - Audit and review every generated plan before execution; insist on the 'design approved' HARD GATE and keep the approval manual and auditable. - Limit sub-agent network access and model choices if possible; avoid allowing sub-agents to exfiltrate repository contents or secrets. If you cannot enforce these controls (manual gating, least-privilege deploy keys, CI-based deploys), treat this skill as risky and avoid enabling autonomous execution. If you can enforce them, the skill can be useful but still requires operational safeguards.

Superpowers — Desarrollo estructurado con sub-agentes

Adaptado de 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:

### 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 ... && git commit -m "feat: descripción"`

Al terminar el plan, preguntar:

"Plan guardado en docs/plans/.... ¿Ejecuto con sub-agentes o prefieres revisarlo primero?"

---

3. EXECUTE — Sub-agente por tarea

Un sessions_spawn por tarea del plan. Sub-agente fresco = sin contaminación de contexto.

Prompt del sub-agente implementador:

Eres un implementador. Tu ÚNICA tarea es ejecutar exactamente lo que dice el plan.

REGLAS:
- Sigue el plan al pie de la letra
- Si algo no está claro, PARA y pregunta (no improvises)
- Test primero, implementación después
- Commit al terminar
- NO hagas nada que no esté en el plan

TAREA:
[texto completo de la tarea del plan]

CONTEXTO DEL PROYECTO:
[archivos relevantes, stack, convenciones]

Después de cada tarea — doble review:

Review 1: Spec compliance (¿hace lo que dice el plan?)

• ¿Se crearon/modificaron los archivos correctos?
• ¿Los tests pasan?
• ¿Se añadió algo que NO estaba en el plan? → revertir
• ¿Falta algo del plan? → completar

Review 2: Calidad (¿está bien hecho?)

• ¿El código es limpio?
• ¿Los tests cubren edge cases?
• ¿Hay code smells?

Si falla un review:

• Lanzar nuevo sub-agente con el feedback específico
• Re-review hasta que pase ambos

---

4. REVIEW FINAL

Después de todas las tareas:

• Verificar que el build pasa
• Screenshot de verificación (si hay UI)
• Review completo del diff total
• Documentar en daily notes

---

5. SHIP

• git push
• Restart PM2 si aplica
• Notificar a Chema con resumen

---

Principios

• YAGNI — No construir lo que no se ha pedido
• DRY — No repetir código ni lógica
• TDD — Test primero, siempre
• Fresh context — Sub-agente nuevo por tarea
• Evidence over claims — Verificar antes de declarar victoria
• El plan es ley — Si hay que desviarse, parar y re-planificar

---

Para Elicita específicamente

• CERO datos demo/ficticios — regla absoluta
• Build + PM2 restart + screenshot después de cada tarea con UI
• Modelo sub-agentes: anthropic/claude-sonnet-4-6
• Si algo rompe el build: git checkout y documentar