Superpowers pone orden en Claude Code (y te cobra por ello)

Superpowers es un plugin para Claude Code escrito por Jesse Vincent, que publica herramientas open source para desarrolladores desde los años 90. Lo lanzó en octubre y, menos de un año después, el repositorio tiene 280.000 estrellas y 25.000 forks, con el último push dos días antes de que grabáramos. El proyecto ya va por su sexta versión mayor, con 681 commits en la rama principal, así que no es una colección de prompts que alguien abandonó tras el pico del lanzamiento.

Señal	Valor
Estrellas en GitHub	280.000
Forks	25.000
Versión mayor	6
Commits en main	681
Issues abiertas	125

La apuesta de Vincent cabe en una frase: lo que les falta a los agentes de código no es capacidad, es disciplina. Esa disciplina se distribuye como simples archivos markdown que cualquiera puede leer, forkear y adaptar. Instalamos el plugin, leímos las catorce skills línea por línea y miramos qué cambia en cuatro frentes: productividad, fiabilidad del código, gasto de tokens y documentación.

Superpowers es un plugin gratuito y open source para Claude Code. Está en el marketplace oficial de plugins de Anthropic y se instala con un solo comando. La misma metodología existe para más de una docena de otras herramientas, entre ellas Cursor, Codex y Gemini, cada una con su propia ruta de instalación.

El núcleo son catorce skills: archivos markdown de instrucciones que el agente carga cuando una situación encaja con ellos. Brainstorming, redacción de planes, desarrollo con subagentes, desarrollo guiado por tests y depuración sistemática codifican cada uno una forma completa de trabajar, con sus propias checklists y barreras. La skill de depuración prohíbe proponer un arreglo antes de aislar la causa raíz. Una skill de verificación obliga al agente a demostrar que un trabajo está terminado en vez de afirmarlo. Cada skill se anuncia al cargarse, así que siempre sabes en qué modo está trabajando el agente.

Un hook al inicio de la sesión obliga a Claude a comprobar, antes de cada tarea, si aplica alguna de estas skills. La regla está escrita en la skill de entrada: si hay aunque sea un uno por ciento de probabilidad de que una skill sea relevante, el agente tiene que cargarla. El resultado se comporta menos como una caja de herramientas y más como una metodología de desarrollo inyectada en el agente.

Vincent cuenta el origen en su blog. Construyó las skills explotando 2.249 archivos markdown de lecciones que sus propios agentes habían aprendido, y luego puso a prueba los borradores contra esos mismos archivos. La metodología se extrajo de fallos reales de agentes en lugar de escribirse desde la teoría.

Brainstorming es la skill por la que pasa todo. En cuanto pides una funcionalidad, Claude la carga y actúa como experto en requisitos durante toda la conversación de encuadre. Todo el método cabe en un archivo legible.

El archivo abre con una barrera dura: nada de código, nada de andamiaje, ninguna skill de implementación de ningún tipo hasta que hayas aprobado una intención explícita. Nada se construye por intuición, y la barrera aplica a toda tarea, por pequeña que parezca. La skill clasifica después cada petición en una de tres vías.

Vía	Definición	Resultado
Spike	Una duda de viabilidad	Una respuesta, no código que conservas
Acotada	Un cambio pequeño en un flujo que ya existe en el repositorio	Un cambio delimitado
Arquitectónica	Todo lo que reestructura cómo encaja el proyecto	Una spec que validas y después un plan de implementación

El agente dice su clasificación en voz alta para que puedas corregirla, y el mecanismo solo gira en un sentido: la complejidad oculta descubierta a mitad de una tarea sube de vía, nunca al revés. El archivo incluye una tabla de señales de alarma, pensamientos como «esto es demasiado simple para necesitar un diseño», con la réplica justo al lado: las tareas simples son exactamente donde las suposiciones sin revisar cuestan más. Hasta un spike conserva su barrera. Lo que el agente construya para responder a la pregunta queda etiquetado como desechable, y conservar ese código se convierte en una nueva petición que clasificar.

Durante el diálogo, el agente hace las preguntas que haría un ingeniero senior y presenta su diseño en secciones digeribles. En nuestro propio pipeline, esta fase ya ha matado funcionalidades que habríamos construido para nada.

La skill de redacción de planes abre con una instrucción que marca el tono: escribe el plan para un desarrollador competente que no tiene ningún contexto sobre tu código y que, en palabras del propio archivo, tiene un gusto cuestionable.

En concreto, el trabajo se corta en tareas donde cada paso lleva de dos a cinco minutos: escribe el test que falla, ejecútalo para confirmar que falla, escribe el código mínimo que lo pasa, vuelve a lanzar los tests, haz commit. Una acción, una verificación, y el trabajo avanza en commits frecuentes. Es el ciclo del desarrollo guiado por tests, impuesto por otra skill del plugin, así que cada tarea lleva su propio ciclo de tests.

Cada tarea lista los archivos exactos a crear o tocar, hasta el número de línea. El plan abre con una cabecera obligatoria: el objetivo en una frase, la arquitectura en dos o tres, el stack técnico, un enlace a la spec y las restricciones globales del proyecto copiadas palabra por palabra. Si la spec cubre varios subsistemas independientes, la skill exige planes separados, uno por subsistema, cada uno produciendo software testeable por sí solo.

El tamaño de las tareas es el corazón del argumento de fiabilidad. Una tarea corta significa un agente que termina su trabajo con una ventana de contexto todavía casi vacía. Nunca llega al momento en que la sesión se desborda, el agente pierde el hilo y empieza a inventar funciones que no existen. Ninguna demo de cinco minutos muestra este problema, pero lo decide todo en un proyecto real: la calidad de un agente al final de una sesión no tiene nada que ver con su calidad en el primer prompt. Menos contexto saturado significa mecánicamente menos alucinaciones, y código que hace lo que decía el plan.

En la ejecución, una skill dedicada aísla el trabajo en un worktree de Git, una copia de trabajo separada del repositorio, de modo que el plan corre sin pisar lo que estés haciendo al lado.

La skill de ejecución dirige el desarrollo mediante subagentes. Su principio cabe en una línea del archivo: un subagente nuevo por tarea, una revisión tras cada tarea y una revisión amplia de toda la rama al final. Tu sesión principal se convierte en orquestador. Ya no programa, delega. Cada subagente recibe exactamente el contexto que necesita su tarea y nunca el historial de tu sesión, lo que evita la contaminación del contexto y deja tu propia ventana libre para la coordinación.

El subagente puede hacer preguntas antes de empezar, luego implementa, testea, hace commit y revisa su propio trabajo. Cuando termina, el orquestador ejecuta una revisión en dos partes, primero el cumplimiento de la spec y después la calidad del código, con un puesto de revisor dedicado para cada tarea. Nada se improvisa: la skill trae un prompt plantilla para cada rol (implementador, revisor de tarea y el revisor que recomprueba los arreglos) que el orquestador rellena con el contexto de la tarea.

Resultado de la revisión	Qué ocurre
Pasa	El orquestador anota la finalización en un registro y avanza en el plan
Falla, rondas 1 a 3	El implementador original retoma el trabajo, ya que conoce el código y sus propias decisiones
Falla, ronda 4	Se lanza un implementador nuevo en un modelo más capaz
Falla, ronda 5	Salta un fusible y el orquestador resuelve él mismo cada hallazgo abierto

La skill también evita el exceso contrario: una ráfaga de tareas mecánicas minúsculas sale como un solo envío agrupado, revisado como una unidad. Nada se fusiona sin pasar por un revisor. El resultado es lo que un equipo humano llama proceso de code review, salvo que corre por sí solo, tarea tras tarea.

El sistema de reparto abre la puerta a una tercera victoria: la economía de tokens. La skill tiene una sección de selección de modelo que empieza con una regla: usa el modelo menos potente capaz de asumir cada rol. El orquestador evalúa la dificultad de cada tarea del plan y asigna el modelo a medida.

Tarea	Nivel de modelo
Tarea mecánica bien especificada que toca uno o dos archivos, o un plan que ya contiene el código a escribir	El nivel más barato (implementar se convierte en transcribir y testear)
Coordinación entre varios archivos, depuración	Un modelo estándar
Arquitectura, la revisión final de la rama	El modelo más capaz disponible

El archivo añade dos matices. Primero, nombra siempre el modelo de forma explícita al delegar: un subagente sin modelo hereda el de tu sesión, a menudo el más caro, lo que anula en silencio toda la sección. Segundo, el número de turnos pesa más que el precio del token. Los modelos más baratos necesitan más turnos en trabajos de muchos pasos y acaban costando más en total, por eso los revisores y los implementadores que trabajan a partir de prosa tienen un mínimo un nivel por encima en lugar del más barato.

Este montaje hace viable algo contraintuitivo: usar Opus o Fable, los modelos más caros del catálogo, en el plan Pro de veinte dólares. El modelo caro solo trabaja en las pocas decisiones que lo merecen, y el resto del plan corre en modelos que consumen una fracción de tu cuota.

La última victoria es en la que nadie piensa al instalar el plugin. Las specs y los planes no son mensajes de chat que se esfuman al terminar la sesión. Son archivos markdown guardados dentro del repositorio y añadidos al commit junto con el trabajo. La skill fija la ubicación: una carpeta de planes fechada, un archivo por funcionalidad, con el objetivo, la arquitectura y el enlace a la spec en la cabecera.

La spec viaja con el plan, y los conflictos entre ambos se resuelven a favor de la spec: el documento es la autoridad, no la memoria del agente. El historial de git ya no solo te dice qué cambió. Te dice por qué, y qué había decidido el agente en ese momento. Seis meses después, mencionar el archivo del plan en un prompt permite al agente retomar el contexto de la funcionalidad original, y una nueva funcionalidad que toca el mismo subsistema se apoya en la spec existente en lugar de redescubrir el terreno.

Ya no existe la tarea sin rastro: todo lo que un agente hizo en el código dejó un documento detrás, del primer brainstorm al último commit. El proyecto resume su filosofía en dos principios, lo sistemático sobre lo improvisado y las pruebas sobre las afirmaciones. La documentación sale del proceso por sí sola.

El límite es real y el repositorio no lo anuncia: toda esta disciplina tiene un coste fijo, y ese coste nunca se apaga. La skill de entrada es tajante. A la menor duda, el agente debe cargar la skill, y el archivo de brainstorming afirma que la ceremonia escala con la tarea, pero la aprobación humana nunca.

En un arreglo de dos líneas, eso significa responder preguntas de encuadre, aprobar un diseño de dos frases y esperar el ciclo completo antes de ver el arreglo. Para una errata en un archivo de configuración, el proceso completo es simplemente más lento que arreglarlo tú mismo. La propia orquestación consume tokens: los briefs de reparto, dos revisiones por tarea y el registro se pagan cada vez, y es en las tareas más pequeñas donde más se nota.

También hay un síntoma contrario, y responde directamente a la pregunta de Reddit. Si tus estadísticas de uso muestran el plugin a un pequeño porcentaje, tus peticiones casi nunca activan las skills, así que pagas la comprobación de entrada en cada sesión sin tocar nunca las ganancias. Un bucle de arreglo que agota las cinco rondas son cinco diffs, cinco revisiones más y un arbitraje, para una tarea que debía llevar minutos. El proyecto tampoco se queda quieto: pasó de una primera versión a una sexta en menos de un año y aún tiene 125 issues abiertas, así que las skills que lees hoy habrán cambiado en la próxima actualización.

El plugin prevé su propia salida. Sus instrucciones ponen tus directrices por encima de las skills, así que puedes decirle al agente, de forma explícita, que salte el proceso. Nuestra regla: Superpowers activado por defecto para cualquier trabajo de funcionalidades y un salto deliberado para los arreglos minúsculos.

Tu uso de Claude Code	Veredicto
Funcionalidades que llevan horas	Instálalo: el encuadre evita que implementes lo que no toca, las tareas cortas alejan al agente de la saturación del contexto, la selección de modelo estira tu cuota y heredas una documentación que nunca habrías escrito
Scripts desechables y arreglos pequeños	Pasa de largo: pagarías el coste fijo del proceso en tareas que no lo necesitan
Entre medias	Instálalo y aprende a decir skip: una frase en tu prompt te devuelve el control

Si quieres probarlo sin adoptarlo todo, deja correr solo la skill de brainstorming unos días. Concentra la mayor parte de la ganancia, y las demás skills se injertan de forma natural después. El plugin cumple sus cuatro promesas siempre que le des funcionalidades dignas de su ceremonia. Ya corre en nuestros propios proyectos, y la fase de brainstorming es la que ya no apagaríamos. El repositorio es gratuito y open source, con 280.000 personas en la cola delante de ti.