Superpowers para Claude Code: el plugin que obliga a tu agente a diseñar, planificar y testear antes de programar

Superpowers es un plugin de skills para agentes de programación (Claude Code, Codex, Cursor, Gemini CLI, Copilot CLI y una docena más) que cambia *cómo* trabaja el agente: antes de escribir código te pregunta qué quieres de verdad, redacta un diseño, lo convierte en un plan de tareas pequeñas, lo ejecuta con subagentes, exige tests que fallen primero y no da nada por terminado sin pruebas. Lo mantiene Jesse Vincent con su empresa Prime Radiant y se publica con licencia MIT.

Lo hemos instalado en Claude Code 2.1.301, leído sus 15 skills y lanzado dos pruebas reales para ver si el agente se comporta como promete. Aquí tienes qué hace, cómo instalarlo, qué pasó en las pruebas y cuándo merece la pena.

Si es la primera vez que oyes hablar de skills, empieza por la guía de skills de Claude Code: Superpowers es, en el fondo, un paquete de skills con un arranque automático.

Qué es Superpowers y quién lo hace

El propio README lo define como "una metodología completa de desarrollo de software para tus agentes de programación, construida sobre un conjunto de skills componibles". La primera versión salió el 9 de octubre de 2025; un año después va por la v7.0.0 (9 de octubre de 2026), con más de 680 commits e instrucciones de instalación para 16 entornos distintos.

Datos que comprobamos en el repositorio obra/superpowers:

La diferencia con una skill suelta es que Superpowers no añade una capacidad concreta (dibujar, auditar SEO, publicar en redes). Añade disciplina de proceso: impone un orden de trabajo y reglas que el agente no puede saltarse con una excusa.

Cómo funciona por dentro

Superpowers se apoya en dos piezas:

1. Un hook SessionStart. Al abrir una sesión (y tras /clear o una compactación), el script hooks/session-start inyecta en el contexto el contenido completo de la skill using-superpowers, envuelto en <EXTREMELY_IMPORTANT>You have superpowers..
2. Las skills en sí, en skills/<nombre>/SKILL.md. Claude ve la descripción de cada una y las carga con la herramienta Skill cuando encajan con la tarea.

La skill de arranque es corta (65 líneas) pero muy agresiva a propósito. Su regla central dice que si hay "aunque sea un 1 % de probabilidad" de que una skill aplique, el agente debe invocarla antes de responder, incluso antes de hacer preguntas aclaratorias. Incluye una tabla de "red flags" con las excusas típicas del modelo ("es una pregunta simple", "primero miro el código", "la skill es excesiva") y la respuesta a cada una.

Un detalle importante: la misma skill deja claro que tus instrucciones mandan. El orden de prioridad es: instrucciones del usuario (CLAUDE.md, AGENTS.md, peticiones directas), luego las skills, luego el comportamiento por defecto. Si tu CLAUDE.md dice "no uses TDD en este repo", gana tu CLAUDE.md.

Las 15 skills de Superpowers, una por una

El README las agrupa en cuatro bloques. Esto es lo que hace cada una según su SKILL.md:

Diseño y planificación

• brainstorming: se activa antes de crear cualquier cosa. Pregunta qué quieres y por qué, te devuelve lo que entendió en bloques de 200-300 palabras y decide el tamaño del trabajo (tarea rápida, cambio pequeño o proyecto con documento de diseño en docs/superpowers/specs/). Tiene una "puerta dura": no se escribe código hasta que apruebas la descripción.
• writing-plans: convierte el diseño aprobado en un plan en docs/superpowers/plans/ con pasos de una sola acción y resultado comprobable: firmas exactas, aserciones de los tests y comandos de verificación.
• using-git-worktrees: crea un espacio aislado (worktree de Git o la herramienta nativa del entorno) y comprueba que los tests pasan antes de empezar.

Ejecución

• subagent-driven-development: lanza un subagente nuevo por tarea, con una revisión de cumplimiento del plan y de calidad después de cada una, y una revisión de toda la rama al final. No para a preguntar entre tareas salvo por cuatro motivos: algo irreversible, algo sensible de seguridad, un efecto fuera del worktree (merge, push, publicar) o un plan roto.
• executing-plans: la alternativa barata; el agente hace todas las tareas en la misma sesión y pide una sola revisión al final.
• dispatching-parallel-agents: reparte en paralelo tareas independientes sin estado compartido.

Calidad y depuración

• test-driven-development: ciclo RED-GREEN-REFACTOR con una "ley de hierro": NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST. Si el agente escribió código antes que el test, lo borra.
• systematic-debugging: cuatro fases obligatorias (investigar la causa raíz, analizar patrones, hipótesis y prueba, implementación). Si tres arreglos seguidos fallan, obliga a cuestionar la arquitectura antes de intentar un cuarto.
• verification-before-completion: NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE. Nada de "ya está arreglado" sin haber ejecutado el comando que lo demuestra.
• requesting-code-review y receiving-code-review: pedir revisión contra el plan con severidades, y recibirla con rigor técnico en vez de darle la razón al revisor por cortesía.
• finishing-a-development-branch: verifica los tests y ofrece exactamente tres opciones: merge local, push con pull request o dejar la rama como está.

Meta

• using-superpowers: la skill de arranque descrita arriba.
• writing-skills: guía para crear skills nuevas aplicando TDD a la propia documentación (con 681 líneas, es la más larga del paquete).
• diagnosing-superpowers: lee el registro de una sesión que salió mal y explica con evidencia qué falló, por ejemplo una skill que no saltó o un agente que ignoró su plan.

El flujo de trabajo completo

En la práctica, una funcionalidad nueva pasa por estas fases sin que tengas que pedir ninguna:

1. brainstorming → hablas con el agente hasta que el diseño está claro y lo apruebas.
2. using-git-worktrees → rama aislada con la línea base de tests en verde.
3. writing-plans → plan de tareas pequeñas y verificables.
4. subagent-driven-development o executing-plans → ejecución con revisiones.
5. test-driven-development → cada tarea empieza con un test que falla.
6. requesting-code-review → revisión entre tareas; los problemas críticos bloquean.
7. finishing-a-development-branch → merge, PR o dejarlo para después.

El README afirma que no es raro que el agente trabaje "un par de horas" seguidas sin desviarse del plan. No lo hemos medido; lo que sí comprobamos es que las dos primeras puertas (diseñar antes de construir y depurar antes de arreglar) funcionan.

Cómo instalar Superpowers

En Claude Code

Está en el marketplace oficial de plugins de Claude:

/plugin install superpowers@claude-plugins-official

O desde el marketplace del propio proyecto, que incluye otros plugins relacionados:

/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

Para probarlo sin instalarlo de forma permanente (es lo que hicimos nosotros), clona el repositorio y cárgalo solo para esa sesión:

git clone https://github.com/obra/superpowers
claude --plugin-dir ./superpowers

En otros agentes

Si usas varios agentes, hay que instalarlo en cada uno por separado.

Comprobar que funciona

El README propone una prueba sencilla: abre una sesión nueva y escribe algo como "hagamos una lista de tareas en React". Si la instalación es correcta, se activa brainstorming antes de que se escriba una sola línea de código. Es justo la primera prueba que hicimos.

Prueba real 1: brainstorming antes de programar

En una carpeta vacía con Git, lanzamos Claude Code en modo no interactivo con el plugin cargado y una petición típica de "vibe coding":

claude -p --plugin-dir ./superpowers "Quiero hacer una app de lista de tareas en React"

Sin Superpowers, lo normal es que el agente empiece a generar create-vite, componentes y estilos. Con el plugin, esto fue lo que pasó:

El agente anunció "Using superpowers:brainstorming", cargó la skill y su respuesta fue exactamente lo que pide el SKILL.md de la v7.0: una línea ofreciendo saltarse las preguntas y una única pregunta abierta sobre un momento concreto ("¿en qué momento te dan ganas de tener esta lista de tareas, y qué te falta en las que ya has probado?"). No creó ningún archivo. Coste: 3 turnos y 0,08 USD.

Si contestas "sáltate las preguntas", la skill se da por terminada: el agente anuncia en una línea las decisiones técnicas que toma (plataforma, lenguaje) y pasa al flujo normal.

El visual companion

Cuando la conversación trata de algo que se ve (una pantalla, un diagrama, dos diseños alternativos), brainstorming ofrece abrir un visual companion: un pequeño servidor Node local que muestra en el navegador las maquetas que escribe el agente y registra en qué opción haces clic.

Lo arrancamos con el script del propio plugin y le pasamos una pantalla de ejemplo con dos distribuciones para la app de tareas:

bash skills/brainstorming/scripts/start-server.sh --project-dir .

El servidor devuelve una URL con una clave de sesión (?key=…) y rechaza peticiones sin ella, se apaga solo tras 4 horas de inactividad y guarda las pantallas en .superpowers/brainstorm/ (conviene añadir esa carpeta a tu .gitignore). Al hacer clic en la opción A, el archivo de eventos registró {"type":"click","choice":"lista",...}.

Un aviso de privacidad: por defecto, el logo de Prime Radiant de esa página se carga desde su web e incluye la versión de Superpowers, para que el equipo sepa cuánta gente lo usa. No envía nada de tu proyecto. Para desactivarlo, define SUPERPOWERS_DISABLE_TELEMETRY=1. También respeta DISABLE_TELEMETRY y CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC de Claude Code.

Prueba real 2: depuración sistemática

Segunda prueba: un mini proyecto Node con un bug real. La función precioConIva(100) debería devolver 115, pero devuelve solo el impuesto:

export function precioConIva(base, iva = 15) {
  return Math.round(base * iva / 100 * 100) / 100;
}

Le pedimos al agente que explicara la causa del test que falla antes de tocar nada:

claude -p --plugin-dir ./superpowers "El test falla al ejecutar npm test. Explícame la causa raíz antes de tocar nada."

El agente cargó systematic-debugging, anunció que seguía la Fase 1 (reproducir y leer el error sin modificar nada), leyó precio.js y precio.test.js y entregó un informe con:

• La causa raíz con la línea exacta (precio.js:2) y una tabla siguiendo el valor paso a paso hasta el 15 !== 115.
• Una sección de qué no es la causa (el redondeo, la configuración de ESM, una regresión reciente: el repo solo tiene un commit).
• La pregunta que solo puede responder una persona: ¿está mal la función o el test? Y su recomendación razonada (la función, por su nombre y el título del test).

Lo más revelador fue un detalle de honestidad: en modo -p sin permisos, npm test no llegó a ejecutarse, y el agente lo dijo al principio en lugar de inventar la salida. Eso es verification-before-completion en estado puro. Coste: 8 turnos y 0,10 USD.

Ventajas y límites

Lo que nos gustó

• Corta de raíz el fallo más caro del vibe coding: construir rápido algo que no era lo que querías.
• Es texto plano. Puedes leer cada SKILL.md, entender por qué el agente hace lo que hace y sobrescribirlo desde tu CLAUDE.md.
• Funciona igual en Claude Code, Codex, Cursor o Gemini CLI, así que el equipo puede compartir metodología aunque cada uno use un agente distinto.
• Se mantiene de verdad: las notas de la v6.4.2 explican que rehicieron writing-plans porque algunos modelos punteros (citan a Opus 5.5) intentaban implementar el proyecto entero mientras escribían el plan. Los planes nuevos tardan una cuarta parte y gastan un tercio de tokens.

Lo que hay que tener en cuenta

• Más tokens y más turnos. Subagente por tarea más revisión por tarea cuesta más que dejar al agente ir a lo loco. Para un script de 20 líneas, sobra; por eso brainstorming hace directamente las tareas claras y rápidas.
• Es estricto a propósito. Si odias el TDD o trabajas en prototipos de usar y tirar, pídeselo explícitamente ("esto es un spike") o desactívalo en tu CLAUDE.md.
• No acepta skills nuevas de la comunidad. El README dice que en general no admiten contribuciones de skills nuevas; las mejoras deben funcionar en todos los agentes soportados.
• En Hermes Agent, una sesión muy larga que compacta su primer turno pierde el arranque; el README recomienda abrir una sesión nueva si las skills dejan de saltar.

Errores frecuentes

• "Las skills no se activan". Abre una sesión nueva tras instalar: el hook SessionStart solo corre al arrancar, tras /clear o tras compactar. En Muse y Hermes hay que reiniciar las sesiones activas.
• El hook falla en Windows. La v7.0.0 corrigió run-hook.cmd para encontrar Git for Windows instalado por usuario (%LOCALAPPDATA%\Programs\Git) y saltarse los lanzadores bash.exe de WSL. Actualiza antes de depurar.
• invalid hook "hooks": command hook must specify 'command' en Antigravity. Ocurría en versiones anteriores, cuando agy importaba el repo como extensión de Gemini. Desde la v7.0.0 hay manifiesto nativo; el comando de instalación es el mismo.
• "Gasta demasiado". Pídele al agente "averigua qué salió mal con superpowers en esta sesión": la skill diagnosing-superpowers lee el registro y te dice con evidencia dónde se fue el presupuesto.

Preguntas frecuentes

¿Superpowers es gratis?

Sí. Es open source con licencia MIT: puedes usarlo, modificarlo y redistribuirlo, también en proyectos comerciales, manteniendo el aviso de copyright. Prime Radiant ofrece soporte comercial para empresas, pero el plugin es el mismo.

¿Funciona con Codex, Cursor o Gemini CLI?

Sí. El mismo repositorio trae instrucciones y archivos de plugin para 16 entornos. En los que no tienen hook de arranque (como Antigravity), el arranque funciona porque la descripción de using-superpowers le dice al modelo que la cargue al empezar cualquier conversación.

¿Puedo usar solo algunas skills?

El plugin se instala completo, pero las skills solo se cargan cuando encajan. Si quieres excluir un comportamiento concreto (por ejemplo, TDD), indícalo en tu CLAUDE.md: las instrucciones del usuario tienen prioridad sobre las skills.

¿Superpowers está en español?

Las skills están en inglés, pero el agente te responde en tu idioma. En nuestras pruebas, con peticiones en español, todas las respuestas llegaron en español.

¿En qué se diferencia de find-skills?

find-skills busca e instala skills de terceros cuando le pides algo que el agente no sabe hacer. Superpowers no añade capacidades nuevas: impone una forma de trabajar. Se pueden usar juntos.

Conclusión

Superpowers es lo más parecido a darle a tu agente las costumbres de un ingeniero senior: entender antes de construir, planificar en pasos verificables, test primero y nada de "ya funciona" sin pruebas. En nuestras pruebas, las dos puertas principales se activaron solas y el agente fue más honesto con lo que no pudo comprobar. Si usas Claude Code o Codex para algo más que scripts sueltos, instálalo en un proyecto real durante una semana y compara.

Siguiente paso: si quieres adaptar el método a tu equipo, repasa cómo funcionan las skills de Claude Code y crea las tuyas con la skill writing-skills del propio paquete.