AIDive

Pack de vídeo

Superpowers para Claude Code: tabla de veredicto, fuentes, checklist y guía avanzada

9 min de lectura

TL;DR

  • Superpowers es un proceso, no una caja de herramientas: catorce skills en markdown que condicionan cada feature a una sesión de brainstorming, un plan escrito y una cadena de subagentes nuevos, todos revisados.
  • Instálalo si tus sesiones de Claude Code construyen features que llevan horas. Descártalo si tu uso son scripts desechables y arreglos de dos líneas: la comprobación de entrada se ejecuta en cada tarea y nunca se apaga.
  • El argumento de los tokens es real, pero sale de una sola sección de un solo skill: Model Selection. El orquestador asigna el modelo más barato capaz de cubrir el rol, así que el modelo caro solo toca la arquitectura y la revisión final de la rama.
  • El repo está sano: 280,597 stars, 25,138 forks, 681 commits en main, release v6.3.0 el 2026-08-12, creado el 2025-10-09.
  • La queja que originó el vídeo, estadísticas de uso del 1 al 3 por ciento, no es un bug: significa que los skills nunca se activan con tu trabajo, así que pagas el gate y no recibes nada a cambio.
  • El camino intermedio es una frase en tu prompt: dile al agente que se salte el proceso en los arreglos pequeños, y deja que brainstorming funcione solo unos días antes de adoptar el resto.

Qué dicen las fuentes

Las cifras del repositorio se leyeron el 2026-09-02: 280,597 stars, 25,138 forks y 681 commits en la rama main, con el último commit en main fechado el 2026-08-12 (v6.3.0) y un push posterior el 2026-08-31 a una rama que no es main s1. La pestaña Issues mostraba 125 issues abiertas ese día; la cifra de 350 de la API incluye las 225 pull requests abiertas, así que cita la pestaña, no la API, cuando lo compares con otros plugins s6. El proyecto se creó el 2025-10-09 y trae catorce skills s2. El post de lanzamiento del autor resume la apuesta en una línea: a los agentes de código no les falta capacidad, les falta disciplina, y esa disciplina se puede distribuir como simples archivos markdown que cualquiera puede leer, forkear y editar s5. El plugin está en la marketplace oficial, así que la instalación es un solo comando y las actualizaciones siguen a la marketplace s4.

El punto de entrada es un skill que el hook de inicio de sesión carga antes que nada. Le dice al agente que, si hay la mínima duda sobre si un skill aplica, debe cargarlo y comprobarlo antes de responder o escribir código. Esa regla es la fuente tanto del beneficio como del coste fijo s14.

Brainstorming arranca con un HARD-GATE: nada de código, nada de scaffolding, ningún skill de implementación hasta que hayas validado una intención explícita. Después clasifica la petición en uno de tres caminos: spike, cuando el resultado es una respuesta y no código; bounded, para un cambio pequeño dentro de un flujo que el repo ya tiene; architectural, para todo lo que reestructure el proyecto. El agente anuncia la clasificación para que puedas contradecirla, y el trinquete va en un solo sentido: la complejidad oculta descubierta a mitad de tarea sube el camino, nunca lo baja s9.

El skill de redacción de planes pide un plan escrito para un desarrollador competente que no sabe nada de tu codebase y, en palabras del propio archivo, tiene gusto cuestionable. El trabajo se divide en tareas cuyos pasos duran de dos a cinco minutos cada uno: escribir el test que falla, ejecutarlo para verlo fallar, escribir el código mínimo, volver a ejecutar los tests, commit. Cada tarea lista los archivos exactos que crear o modificar, hasta los números de línea, y el plan abre con una cabecera obligatoria s10.

La ejecución es el skill subagent-driven development: un subagente nuevo por tarea, una revisión tras cada tarea, una revisión de toda la rama al final. La sesión principal deja de programar y despacha. Cada subagente recibe solo el contexto de su tarea, nunca el historial de tu sesión, lo que mantiene libre tu propia ventana para coordinar. Cuando el subagente implementa, prueba, hace commit y se autorrevisa, el orquestador lanza una revisión en dos partes, primero cumplimiento de la spec y luego calidad del código, con un puesto de revisor reservado para cada tarea. El archivo limita el bucle a un máximo de cinco rondas por tarea s11. El aislamiento del trabajo se delega en un skill de worktree, así que un plan nunca se ejecuta sobre tu checkout actual s13.

La sección Model Selection empieza con una regla: usa el modelo menos capaz que pueda cubrir el rol. Una tarea mecánica bien especificada que toque uno o dos archivos va a un modelo pequeño; cuando el plan ya contiene el código a escribir, implementar es transcripción más tests, así que basta el nivel más barato. La coordinación multiarchivo y el debugging van a un modelo estándar. La arquitectura y la revisión final de la rama piden el modelo más capaz disponible. Dos detalles importan en la práctica: nombra siempre el modelo de forma explícita al despachar, y deja que el orquestador valore la dificultad de cada tarea antes de elegir s12. Este es el mecanismo que hace asequible el modelo caro en el plan Pro de veinte dólares: solo trabaja en las decisiones que lo merecen.

La ganancia en documentación es un efecto secundario del proceso. Las specs y los planes no son mensajes de chat que desaparecen; son archivos markdown guardados en el repo y commiteados con el trabajo, de modo que un revisor lee después por qué se hizo un cambio, no solo qué cambió s3.

El coste es el que el repo no anuncia. El hilo que originó el vídeo cuenta estadísticas de uso del 1 al 3 por ciento y pregunta cuál es el inconveniente más allá de no usarlo s7. La respuesta en los archivos es que brainstorming adapta su ceremonia a la tarea pero nunca se salta la validación humana s9. En un arreglo de dos líneas sigues respondiendo preguntas de encuadre, aprobando un diseño de dos frases y esperando el ciclo completo. Los briefs de despacho, las dos revisiones por tarea y el registro de seguimiento son tokens que pagas siempre, y eso se nota en las tareas más pequeñas. Unas estadísticas de uso bajas significan que los skills no encajan con tu trabajo, que es la señal real que hay que leer.

Veredicto según el uso

Tu uso de Claude Code ¿Instalar? Por qué
Features que llevan horas, varios archivos, una rama Sí El encuadre evita construir lo equivocado, las tareas cortas alejan al agente de la saturación de contexto, la selección de modelo estira la cuota, la documentación sale del proceso
Mixto: features algunos días, arreglos casi siempre Sí, con una regla de salto Mantén el gate para las features, dile al agente en el prompt que se salte el proceso en los arreglos pequeños
Scripts desechables, typos de config, arreglos de dos líneas No El coste fijo del gate se ejecuta en tareas que no lo necesitan
Curioso pero no listo para adoptar todo el método Solo brainstorming Aporta la mayor parte de la ganancia; los demás skills se enganchan con naturalidad después

Haz esto el lunes

  • Instala desde la marketplace oficial y abre la caché del plugin: lee una vez los catorce archivos SKILL.md, son cortos y son todo el producto.
  • Pasa una feature real por el gate de principio a fin: brainstorming, plan, despacho de subagentes, revisión de rama. Juzga el proceso con eso, no con un arreglo.
  • Revisa tus estadísticas de uso después de una semana. Por debajo de unos pocos por ciento, los skills no encajan con tu trabajo: o tus tareas son demasiado pequeñas o tienes que formular las peticiones como features.
  • Añade una regla de salto a las instrucciones de tu proyecto: en arreglos de un solo archivo de pocas líneas, ve directo al cambio, sin brainstorming.
  • Copia la escala de Model Selection en tus propios prompts de subagentes aunque abandones el plugin: nombra el modelo de forma explícita en cada despacho.
  • Haz commit de las specs y los planes que escribe el plugin en lugar de borrarlos; son tu registro de diseño.
  • Cuenta las issues abiertas en la pestaña Issues, no con la cifra de la API, antes de comparar el proyecto con otro plugin.

Para ir más lejos

  • Lee el post de lanzamiento para entender la intención de diseño antes de los archivos de skills: explica por qué la disciplina se distribuye como markdown y no como código s5.
  • La sección philosophy del README es la versión corta del método y el lugar para comprobar si encaja con tu forma de trabajar s3.
  • La sección skills library lista los catorce skills con una línea de propósito cada uno; es más rápido que recorrer el directorio s16.
  • El máximo de cinco rondas por tarea del skill de subagentes es un freno duro que vale la pena copiar en cualquier orquestación que escribas a mano s11.
  • Un hilo pregunta si este tipo de plugin sobrevive a modelos más fuertes; lo que sobrevive es el gate de encuadre y los planes commiteados, lo que los modelos absorben es la mecánica s19.
  • Un relato de un límite de uso semanal quemado por la ceremonia de orquestación es el contraejemplo que hay que leer antes de adoptarlo en trabajo pequeño s20.
  • La comparación con otro conjunto de instrucciones muestra el compromiso: menos skills pero más estrictos, frente a un gran catálogo de reglas s18.
  • La lista de issues abiertas es la lectura más rápida de lo que les falla hoy a otros usuarios s6.

Fuentes

FAQ

¿Superpowers ahorra tokens o los quema?

Ambas cosas. En las features, la selección de modelo manda las tareas mecánicas a modelos pequeños y reserva el modelo caro para la arquitectura y la revisión de rama, así que la cuota se estira. En los arreglos pequeños, los briefs, las dos revisiones por tarea y el registro son puro overhead.

¿Qué significan unas estadísticas de uso del 1 al 3 por ciento?

Los skills solo se activan cuando una situación encaja con ellos. Una cifra baja significa que tus tareas no son features en el sentido del plugin, así que pagas la comprobación de entrada y nunca llegas a la parte que compensa.

¿Puedo quedarme con una parte?

Sí. Brainstorming solo aporta la mayor parte de la ganancia, y la escala de Model Selection funciona en cualquier prompt de subagente escrito a mano. Dile al agente que se salte el proceso en los arreglos mínimos y conservas el control.