功能描述

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

使用说明 (SKILL.md)

Superpowers — Desarrollo estructurado con sub-agentes

Name: Elcano Superpowers
Author: elcanoclaw

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:

Explorar contexto — leer archivos relevantes, commits recientes, estado actual
Preguntar — UNA pregunta a la vez, preferir opciones múltiples
Proponer 2-3 enfoques — con trade-offs y tu recomendación
Presentar diseño — en secciones digeribles, esperar OK antes de avanzar
Guardar diseño — docs/plans/YYYY-MM-DD-\x3Cfeature>-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-\x3Cfeature>-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

安全使用建议

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.

功能分析

Type: OpenClaw Skill Name: elcano-superpowers Version: 1.0.0 The skill bundle defines a structured software development workflow (Brainstorm, Plan, Execute, Review, Ship) designed to manage complex coding tasks through sub-agents. It emphasizes Test-Driven Development (TDD), rigorous planning in Markdown files, and specific deployment steps like PM2 restarts and Git commits. No indicators of data exfiltration, malicious execution, or prompt injection attacks were found; the instructions in SKILL.md are focused on project management and code quality for specific internal projects (Elicita, FlightCBT).

能力评估

ℹ 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.

版本历史

v1.0.0

Structured dev workflow with sub-agents for OpenClaw. Brainstorm → Plan → Execute → Review → Ship. Adapted from obra/superpowers.

元数据

Slug elcano-superpowers

版本 1.0.0

许可证 —

累计安装 0

当前安装数 0

历史版本数 1

常见问题

Elcano Superpowers 是什么？

Facilita desarrollo estructurado con sub-agentes para features, refactors grandes y cambios multi-archivo siguiendo diseño aprobado y TDD. 它是一个面向 Claude Code / OpenClaw 的 AI Agent Skill 插件，目前累计下载 312 次。

如何安装 Elcano Superpowers？

在 OpenClaw 或 Claude Code 对话框中运行命令「/install elcano-superpowers」即可一键安装，无需额外配置。

Elcano Superpowers 是免费的吗？

是的，Elcano Superpowers 完全免费（开源免费），可自由下载、安装和使用。

Elcano Superpowers 支持哪些平台？

Elcano Superpowers 跨平台运行，可在任意部署了 OpenClaw / Claude Code 的环境中使用（cross-platform）。

谁开发了 Elcano Superpowers？

由 elcano（@elcanoclaw）开发并维护，当前版本 v1.0.0。

Elcano Superpowers