Superpowers (plugin)

/plugin install superpowers@claude-plugins-official

Superpowers es un plugin muy popular para Claude Code, escrito por Jesse Vincent, que añade más de veinte skills probadas y listas para usar. Las skills se autoactivan según el contexto de lo que estás haciendo: si arrancas una funcionalidad nueva entra la de brainstorming, si pides escribir tests entra la de TDD estricto, si aparece un error entra la de debugging sistemático. Trae además comandos directos como /brainstorm, /write-plan y /execute-plan para forzar fases concretas del flujo cuando quieres marcar el paso a mano.

La idea de fondo es sencilla: en vez de que el agente improvise y escriba código a la primera, lo obliga a pensar, planear, escribir tests, ejecutar y revisar. Convierte la conversación con Claude Code en algo que se parece a cómo trabaja un equipo serio de desarrollo, con disciplina de método aunque estés solo.

Le rinde a cualquier persona que use Claude Code y haya sentido la frustración de pedir un cambio “rápido” y recibir doscientas líneas sin tests, sin plan y con errores evitables. Si esa escena te resulta familiar, Superpowers es probablemente el primer plugin que deberías instalar.

Por qué importa

Antes de Superpowers, la calidad del trabajo con Claude Code dependía mucho de la disciplina propia. Tenías que acordarte de pedir brainstorming antes de codear, de exigir tests, de revisar el resultado y de dejar trazabilidad de las decisiones. Si tenías un día flojo o ibas con prisa, te saltabas pasos y el código salía peor. El agente cumplía órdenes, pero el método tenías que ponerlo tú.

Con Superpowers instalado, el método viene incorporado. El plugin detecta en qué fase del trabajo estás y mete la skill que toca: te frena cuando intentas codear sin pensar, te pide tests antes del código de producción, te obliga a depurar con hipótesis en lugar de a parchear a ciegas. La consecuencia práctica es que el código sale más mantenible y, sobre todo, que ahorras horas de retrabajo posterior porque los errores se cazan antes.

Cómo se usa en la práctica

El primer paso es instalarlo desde dentro de Claude Code con el comando del marketplace oficial. Es un proceso de un par de segundos y deja el plugin disponible en cualquier proyecto donde uses Claude Code. No necesitas configuración adicional: las skills vienen empaquetadas y listas para autoactivarse desde el primer momento.

Una vez instalado, la forma más natural de usarlo es no usarlo de forma explícita. Cuando arrancas una conversación nueva con una tarea de desarrollo, Superpowers detecta que estás en fase inicial y mete la skill de brainstorming para que el agente te haga preguntas antes de escribir nada. Cuando ya hay un plan claro, entra la de planificación; cuando tocas código, la de TDD estricto. El plugin se siente como si Claude Code hubiera ganado intuición sobre el ciclo de desarrollo.

Cuando quieras forzar una fase concreta, los comandos directos están ahí. /brainstorm arranca una sesión estructurada de exploración del problema, ideal cuando entras a un proyecto nuevo o a una funcionalidad ambigua. La sesión termina con un enfoque elegido y los supuestos asumidos por escrito.

/write-plan toma el enfoque acordado y lo convierte en un plan de implementación con pasos concretos, dependencias y orden de ataque. Este plan queda como referencia: si la conversación se alarga o se interrumpe, puedes retomar exactamente donde lo dejaste sin perder el hilo. Para tareas no triviales, este artefacto vale oro.

/execute-plan ejecuta ese plan paso a paso, con TDD activado por defecto y revisión incluida. El agente escribe el test primero, lo ve fallar, escribe el código mínimo para que pase, refactoriza y revisa antes de saltar al siguiente paso. Es lento comparado con escribir todo del tirón, pero el código que sale tiene tests reales y muchas menos sorpresas en producción.

El flujo completo (brainstorm, plan, execute) está pensado para tareas serias. Para cambios pequeños tipo arreglar un typo o ajustar un margen, dejar que las skills se autoactiven es más que suficiente y no necesitas invocar comandos. La gracia es saber cuándo subir el nivel de disciplina y cuándo dejar que el plugin trabaje en modo ligero.

Cuando aparece un bug, la skill de debugging sistemático entra sola si dices algo del tipo “esto falla”. En lugar de saltar a parchear, el agente formula hipótesis, las prioriza, las descarta una a una y solo entonces propone una solución.

Casos de uso reales

Un desarrollador empieza una nueva funcionalidad de autenticación en un proyecto existente. En vez de pedir directamente “añade login con Google”, invoca /brainstorm y deja que el agente le pregunte por requisitos de seguridad, integración con el sistema actual de usuarios y casos límite (cuentas duplicadas, emails distintos, primera vez frente a usuario recurrente). De ahí sale un enfoque pensado, no improvisado.

Un equipo arrastra un bug intermitente en producción que cada uno ha intentado parchear de una forma distinta sin éxito. Una persona del equipo abre Claude Code con Superpowers, describe el síntoma y la skill de debugging sistemático arranca el proceso: hipótesis ordenadas, evidencias necesarias para confirmar o descartar cada una, y un plan de comprobaciones. El bug aparece en la tercera hipótesis y se arregla con datos, no con suposiciones.

Una desarrolladora que arranca un proyecto personal quiere mantener disciplina de TDD aunque no tenga a nadie revisándola. Con Superpowers instalado, cada vez que pide código nuevo, la skill correspondiente le exige el test primero. Mantiene el método sin esfuerzo de voluntad, que es justo cuando los métodos se pierden.

Errores comunes y cómo evitarlos

• Forzar comandos en cada paso. Si invocas /brainstorm, /write-plan y /execute-plan para cambiar el color de un botón, pierdes tiempo. Reserva el ritual para tareas no triviales.
• Saltarse el brainstorming en tareas nuevas. Empezar a codear sin pensar genera planes flojos y código que hay que rehacer. Cinco minutos de exploración inicial ahorran horas después.
• Apurar la fase de tests en TDD estricto. Escribir tests vagos o saltarse el “ver el test fallar” rompe el ciclo y vuelve los tests poco fiables.
• Pelearse con las skills cuando deciden activarse. Si Superpowers entra en debugging sistemático, sigue el flujo en lugar de pedirle que vaya directo a una solución; suele tener razón.
• No actualizar el plugin. Las skills mejoran y aparecen nuevas con el tiempo. Revisa actualizaciones cada cierto tiempo desde el marketplace para no quedarte con una versión vieja.
• Mezclar Superpowers con flujos manuales contradictorios. Si tu equipo ya tiene un proceso propio incompatible con TDD estricto, decide qué método sigues y respétalo; tirar de los dos a la vez genera fricción.

Cuándo NO usarla

Si tu trabajo con Claude Code es exploratorio puro (probar ideas rápidas, hacer pruebas de concepto descartables, jugar con APIs), Superpowers puede pesar más de lo que aporta. Para tirar código de usar y tirar, el método estricto es un freno innecesario.

Tampoco encaja si trabajas en un entorno donde el método está completamente prescrito desde fuera y choca con lo que propone el plugin. En ese caso, o te ciñes al método externo o usas Superpowers solo en tus proyectos personales.

Combinarla con otras herramientas

Superpowers convive bien con otras skills y plugins de Claude Code: el método es transversal y se apoya en lo que el agente ya sabe hacer con el resto del entorno. Si tienes skills propias o de terceros para revisión de seguridad, generación de documentación o integración con tu CI, todas se activan junto a las de Superpowers sin pisarse. La combinación con un buen control de versiones y un proceso de pull requests cierra el círculo: el plugin asegura método al escribir, el repo asegura método al integrar.

Mini-ejercicio

Abre un proyecto pequeño donde puedas hacer cambios sin miedo. Instala Superpowers si no lo tienes. Elige una funcionalidad mínima que quieras añadir (por ejemplo, una utilidad que valide formato de correo electrónico). Invoca /brainstorm, después /write-plan y después /execute-plan. Deja que el plugin lleve el ritmo sin saltarte fases.

Sabrás que está bien si al terminar tienes un archivo con la función nueva, al menos un par de tests que pasan y una conversación donde se ven las hipótesis y decisiones tomadas por el camino, no solo el código final.