Claude Code escribe código apenas se lo pides. Ese es justo el problema: agarra la primera idea, no la mejor. Superpowers lo obliga a frenar, entender qué quieres, diseñar, planificar y testear antes de tocar una línea. Esta es la guía para instalarlo y sacarle provecho de verdad.

Qué vas a aprender

Qué es Superpowers y por qué cambia la forma en que tu agente de código trabaja
Instalarlo en Claude Code (y en otras herramientas) con los comandos exactos
El flujo de 7 fases que sigue, de la idea suelta hasta el merge
Para qué sirve cada sub-skill clave: brainstorming, planes, TDD, debugging y subagentes
Cómo lanzarlo en un proyecto real, paso a paso
Los errores comunes que arruinan el resultado y cómo evitarlos

01 · Qué es Superpowers

Una cultura de ingeniería empaquetada en archivos de texto

Superpowers es dos cosas a la vez: un conjunto de skills (habilidades) que se combinan entre sí, y una metodología completa de desarrollo para agentes de código. Lo creó Jesse Vincent con el equipo de Prime Radiant, es open source con licencia MIT, y vive en GitHub: github.com/obra/superpowers.

El problema que ataca es concreto. Cuando le pides algo a Claude Code (o a Codex, Gemini CLI, Cursor), el agente se tira de cabeza a escribir código. No pregunta qué estás intentando lograr, no propone un diseño, no testea. Te entrega 300 líneas que parecen funcionar y a la media hora descubres que resolvió el problema equivocado.

Superpowers invierte ese orden. Antes de escribir una línea, el agente para y te pregunta qué necesitas en realidad. De esa conversación saca una especificación, te la muestra en pedazos cortos para que la puedas leer sin perderte, arma un plan dividido en tareas chicas, y recién ahí programa. Todo con TDD estricto —el test primero, el código después— y dos principios que matan la mayoría del código basura: YAGNI ("no lo construyas hasta que lo necesites") y DRY ("no te repitas").

Lo mejor: las skills se activan solas. No tienes que invocar nada raro ni acordarte de comandos. Cuando empiezas a construir algo, Superpowers detecta el contexto y mete la skill que toca. El propio autor cuenta que con esto Claude puede trabajar solo un par de horas seguidas sin desviarse del plan que armaste con él.

Para que se vea la diferencia:

SIN superpowers:
Tú: "Agregá login con Google al sitio"
Agente: [escribe 250 líneas asumiendo tu stack, tu librería de auth y tu modelo de datos]
Resultado: medio anda, la mitad hay que rehacerla.

CON superpowers:
Tú: "Agregá login con Google al sitio"
Agente: "Antes de codear: ¿usás sesiones o JWT? ¿Ya tenés tabla de usuarios?
         ¿Qué pasa si el email de Google ya existe con otro método?"
[propone diseño → lo aprobás → plan en tareas de 2-5 min → TDD → review]
Resultado: anda, está testeado, y resolvió TU problema.

02 · Instalación

Los comandos exactos, plataforma por plataforma

Superpowers funciona en casi todos los agentes de código serios. Estos son los comandos verificados al día de hoy. Busca el de tu herramienta y listo.

Claude Code (la vía más directa, marketplace oficial):

/plugin install superpowers@claude-plugins-official

Si prefieres el marketplace del propio autor (a veces va más al día):

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

Codex CLI — corre /plugins, busca "Superpowers" y elige Install Plugin.

Gemini CLI:

gemini extensions install https://github.com/obra/superpowers

Factory Droid:

droid plugin marketplace add https://github.com/obra/superpowers
droid plugin install superpowers@superpowers

GitHub Copilot CLI:

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

Cursor — /add-plugin superpowers o búscalo en el marketplace.

Tip: después de instalar en Claude Code, abre una sesión nueva y escribe "usá superpowers para esto" en tu primer mensaje. Si quedó bien, el agente arranca preguntándote por el diseño en vez de codear de una. Esa es la señal de que está activo.

03 · Cómo funciona: el flujo de 7 fases

De la idea suelta al código mergeado

Superpowers no es una caja negra. Sigue una secuencia clara, y entender las 7 fases te deja anticipar qué va a hacer el agente en cada momento:

Brainstorming — En vez de codear, refina tu idea a preguntas. Explora alternativas y te muestra el diseño en secciones cortas para que las apruebes una por una. No avanza hasta que aceptas la spec.
Git Worktrees — Con el diseño aprobado, crea un espacio de trabajo aislado en una rama nueva. Así el trabajo no te ensucia el código principal y puedes tener varias cosas abiertas en paralelo.
Writing Plans (planes) — Parte la feature en tareas de 2 a 5 minutos cada una, con rutas de archivo exactas y pasos para verificar. El plan queda tan claro que "un junior entusiasta" podría ejecutarlo.
Subagent-Driven Development / Executing Plans — Manda cada tarea a un subagente nuevo, con checkpoints donde tú revisas. Así el contexto no se contamina entre tareas.
Test-Driven Development — Por cada pedazo: test que falla (RED) → código mínimo que lo hace pasar (GREEN) → refactor → commit. Sin saltarse el orden.
Requesting Code Review — Antes de mergear, otro agente revisa el código contra el plan y ordena lo que encuentra por gravedad.
Finishing a Development Branch — Cierra la rama y te ofrece opciones: mergear, abrir un PR, dejarla o descartarla.

Detrás de todo hay una idea simple: proceso sistemático en vez de improvisado, simplicidad como meta, y evidencia en vez de promesas. El agente no te dice "ya lo arreglé". Te muestra el test que pasa.

04 · Las sub-skills que hacen el trabajo

Qué hace cada una y cuándo se dispara

Superpowers es modular. Cada fase está respaldada por una o más skills. Estas son las que más vas a notar:

Skill	Qué hace
brainstorming	Refina la idea a preguntas. No deja escribir código hasta que propuso un diseño que aceptas.
writing-plans	Divide la feature en tareas de 2-5 min, con archivos exactos y verificación por paso.
executing-plans	Ejecuta el plan por lotes, con checkpoints humanos entre tandas.
test-driven-development	Impone el ciclo RED → GREEN → REFACTOR, con su propia referencia de anti-patrones.
systematic-debugging	Proceso de 4 fases para encontrar la causa raíz. Prohíbe arreglar lo que todavía no entendiste.
subagent-driven-development	Manda la implementación a un subagente y después otro la revisa (doble pasada: que cumpla la spec, y luego la calidad).
dispatching-parallel-agents	Corre varios subagentes en paralelo para trabajo independiente.
using-git-worktrees	Crea ramas aisladas para trabajar sin pisar el código principal.
requesting-code-review / receiving-code-review	Checklist antes de pedir review, y flujo para responder al feedback.
finishing-a-development-branch	Decide qué hacer con la rama: merge, PR, guardar o descartar.
verification-before-completion	Valida que el problema esté resuelto de verdad antes de dar algo por cerrado.
writing-skills	Te ayuda a crear tus propias skills siguiendo el mismo estándar.

Hay dos que valen oro y que vas a usar más de lo que crees:

systematic-debugging. Cuando algo se rompe, la tentación es parchar lo primero que se te ocurre. Esta skill te frena: reproducir, entender la causa raíz, recién ahí arreglar, y dejar una defensa para que no vuelva. Suena lento. En la práctica te ahorra las tres "soluciones" que no eran.

brainstorming. Es la que más cambia el resultado final, porque ataca el problema de raíz: casi todo el código malo nace de un pedido mal entendido. Al forzar la conversación de diseño antes de codear, evita que el agente construya con prolijidad la cosa equivocada.

05 · Cómo usarlo en la práctica

Paso a paso (un proyecto real, de principio a fin)

Instala el plugin (sección 02) y abre una sesión nueva en tu proyecto.
Plantea el objetivo, no la solución. En vez de "creá una tabla X con columnas Y", di qué problema quieres resolver. Deja que brainstorming haga lo suyo:

Quiero que mi app le mande un recordatorio por email a los clientes
que dejaron una compra a medias. Todavía no sé bien cómo encararlo.
Usá superpowers: arranquemos por el diseño antes de codear.

Responde las preguntas de diseño. Te va a preguntar cosas que no habías pensado: ¿cada cuánto?, ¿qué pasa si el cliente ya compró después?, ¿un solo recordatorio o una secuencia? Aquí se define la calidad. Tómate el tiempo.
Aprueba la spec por secciones. Te la muestra en pedazos cortos. Léelos. Si algo no cierra, corrígelo ahora, no después.
Déjalo armar el plan y trabajar. Con el diseño aprobado, crea el worktree, escribe el plan en tareas chicas y empieza a ejecutar con TDD. Vas a ver tests que fallan y después pasan. Eso es lo correcto, no un error.
Revisa en los checkpoints. No lo dejes 100% solo las primeras veces. En cada checkpoint miras qué hizo y confirmas antes de seguir.
Cierra la rama. Al final te ofrece mergear o abrir un PR. Eliges según tu flujo.

Tip: lo más incómodo al principio es bancarte las preguntas del brainstorming cuando sientes que "ya sabes lo que quieres". Aguanta. Nueve de cada diez veces aparece un caso borde que no habías considerado. Descubrirlo antes de codear cuesta una pregunta; descubrirlo después cuesta una reescritura.

06 · Reglas clave y errores comunes

Lo que tienes que saber para que funcione

No lo trates como un autocompletar. Superpowers rinde en tareas que valen un proceso: una feature nueva, un bug difícil, un refactor grande. Para cambiar un texto o un color es demasiado. Usa la herramienta para lo que sirve.
El diseño también es trabajo tuyo. Brainstorming te va a preguntar. Si respondes "lo que te parezca" a todo, obtienes un diseño genérico. La calidad de la spec depende de tus respuestas.
No te saltes el TDD. El instinto es decir "dale, escribe el código y después vemos los tests". No lo hagas. El ciclo RED-GREEN existe para que el test pruebe algo real, no para decorar.
Confía en el debugging sistemático. Cuando algo falle, no lo empujes a "probá esto otro". Déjalo reproducir y entender la causa. Apurar el debugging es la forma más rápida de juntar parches inútiles.
No es solo para Claude Code. Si trabajas con Codex, Gemini CLI, Cursor o Copilot CLI, también lo tienes. La metodología es la misma; lo único que cambia es el comando de instalación.
Es open source y editable. Son archivos Markdown con licencia MIT. Si una skill no encaja con tu forma de trabajar, la lees, la ajustas, o creas la tuya con writing-skills.

Guías relacionadas

Guía completa para usar Claude Code