Superpowers: 311.000 estrellas para un método de trabajo en Markdown

El repositorio con más estrellas de la lista de tendencias de GitHub de esta semana no es un modelo, ni un framework, ni el anzuelo open source de una startup. Es una carpeta de archivos Markdown que le dice a tu agente de programación cómo comportarse.

Superpowers, de Jesse Vincent, ronda las 311.000 estrellas, con unas 5.900 añadidas en la última semana. Su propia descripción: una metodología completa de desarrollo de software para tus agentes de programación, construida sobre un conjunto de skills componibles más unas instrucciones iniciales que aseguran que el agente las use de verdad.

Trescientas mil estrellas para una metodología es una cosa rara de mirar. O el mayor contingente de desarrolladores de la década ha decidido a la vez que quiere proceso, o el botón de estrella se ha convertido en un marcador para «debería pensar en esto luego». Probablemente las dos. Pero la cosa en sí merece tomarse en serio, porque es la respuesta más opinionada que ha publicado nadie a la pregunta de qué debe hacer un agente antes de escribir código.

El primer movimiento es no empezar

Este es el flujo tal como lo describe el README. En cuanto el agente ve que estás construyendo algo, no se lanza a escribir código. Da un paso atrás y pregunta qué intentas hacer en realidad.

Cuando ha sacado una especificación de la conversación, te la enseña en trozos lo bastante cortos para leerlos. No un muro de requisitos. Trozos. Cuando das el visto bueno, produce un plan de implementación lo bastante detallado, en palabras del README, para que lo siga «un ingeniero junior entusiasta, con mal gusto, sin criterio, sin contexto del proyecto y alergia a las pruebas».

Esa frase es lo mejor del repositorio. También es una descripción precisa de lo que es un LLM en un mal día, y escribir el plan para ese lector es una disciplina que casi todos los ingenieros se saltan porque damos por hecho que el lector comparte nuestro contexto.

Luego, cuando dices adelante, arranca el desarrollo dirigido por subagentes: los agentes avanzan tarea a tarea, inspeccionan y revisan su trabajo y siguen. El README afirma que no es raro que el agente trabaje de forma autónoma un par de horas sin desviarse del plan.

Qué hay dentro de la caja

Unas quince skills, agrupadas por función.

Pruebas tiene una entrada, y es la que importa: test-driven-development, el ciclo rojo-verde-refactor, con un documento de referencia sobre antipatrones de testing. Depuración tiene systematic-debugging, un proceso de causa raíz en cuatro fases con técnicas de rastreo, defensa en profundidad y espera basada en condiciones, más verification-before-completion, cuyo único trabajo es evitar que el agente declare victoria sobre algo que no está arreglado.

Colaboración es donde está el peso de verdad: brainstorming para sacar la intención, writing-plans, executing-plans, dispatching-parallel-agents, pedir y recibir revisión de código, using-git-worktrees, finishing-a-development-branch y subagent-driven-development con su revisión en dos etapas: primero el cumplimiento de la especificación, después la calidad del código.

Dos metaskills cierran el círculo: writing-skills, para crear nuevas, y using-superpowers, la introducción que empuja al modelo a cargar el sistema al principio de una conversación. Como las skills se disparan solas, en teoría no tienes que recordar nada de esto. Tu agente ya lo lleva.

Instalación, por arnés, dieciséis veces

Esta es la parte que te dice hasta qué punto se ha fragmentado el mercado de herramientas para agentes. Superpowers publica instrucciones para Claude Code, Antigravity, la app y la CLI de Codex, Cursor, Devin CLI, Factory Droid, Gemini CLI, GitHub Copilot CLI, Grok Build, Kimi Code, OpenCode, Pi, Qwen Code, Hermes y Muse.

Claude Code, por el mercado oficial:

/plugin install superpowers@claude-plugins-official

O por el mercado del propio Vincent:

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

Cursor, en el chat del agente: /add-plugin superpowers. Gemini CLI: gemini extensions install https://github.com/obra/superpowers. Copilot CLI: registra el mercado y luego copilot plugin install superpowers@superpowers-marketplace. Antigravity: agy plugin install https://github.com/obra/superpowers. Devin: devin plugins install obra/superpowers. Factory Droid: registra e instala. La app y la CLI de Codex pasan las dos por el mercado oficial de plugins.

Si usas más de un arnés, lo instalas por separado en cada uno. Es decir, las mismas doce skills existen como doce copias sin una ruta de actualización compartida, y el consejo del README para actualizar es «depende algo del agente de programación, pero a menudo es automático». No es una crítica al proyecto. Es el estado actual del ecosistema, y ver cómo un repositorio de metodología lidia con ello es realmente ilustrativo.

La política de contribuciones es la pista

Enterrado en la sección de contribución: por lo general no aceptan contribuciones de skills nuevas, las actualizaciones de skills tienen que funcionar en todos los agentes soportados, y no aceptan PRs escritos por agentes que arreglen issues abiertos por otra persona salvo que un maintainer lo haya pedido, aunque tú hayas chocado con el mismo problema.

Piensa para qué sirve esa última regla. El modo de fallo obvio de un repositorio así es quedar sepultado bajo skills de aspecto plausible generadas por los mismísimos agentes que las skills deberían gobernar. Vincent lo vio venir y lo atajó, a costa de parecer antipático.

También tiene una implicación más sutil. Si tu agente puede generar una skill para cualquier cosa, el recurso escaso deja de ser la skill y pasa a ser el criterio sobre cuáles merece la pena tener. Ese criterio es lo que vende el repositorio en realidad, y no está abierto a pull requests.

Dónde se rompe la metodología

Cuatro cosas, por orden de cuántas veces las he visto morder.

El proceso no arregla el criterio. Un plan perfectamente ejecutado para una función mal concebida produce una versión bien probada de lo equivocado. La skill de brainstorming ayuda preguntando qué quieres de verdad, pero no te va a decir que la idea es sosa.

Economía de tokens. Especificación, revisión por trozos, plan, reparto de subagentes, revisión en dos etapas por tarea, verificación antes de cerrar. En una tarea pequeña esto es una cantidad espectacular de sobrecoste. La metodología está pensada para trabajo que se mide en días, y parecerá absurda en un arreglo de una línea.

Los planes se desvían. Dos horas de trabajo autónomo contra un plan escrito en el minuto cero están bien cuando el plan era correcto. Cuando la tercera tarea revela que la segunda se apoyaba en una suposición falsa, tienes dos horas de trabajo seguro en la dirección equivocada, y la revisión es lo único que se interpone entre tú y un diff enorme.

Y la honesta: las skills son prompts, y los prompts son sugerencias. Todo esto depende de que el modelo elija seguir la skill en lugar de otras cinco cosas que también sabe. Por eso existe using-superpowers como arranque: es un prompt cuyo trabajo es hacer que se carguen otros prompts.

Para quién es

Si publicas código del que depende otra gente y has visto a un agente marcar con confianza como terminado algo que no lo estaba, este es un conjunto razonable de barandillas y cuesta un comando probarlo. Empieza por test-driven-development y verification-before-completion e ignora el resto una semana. Esas dos son las que más cambian el comportamiento.

Si estás prototipando, pásalo de largo. La metodología está optimizada para no publicar basura, que es un objetivo distinto de averiguar si la idea funciona.

Trescientas mil estrellas no son un veredicto sobre la metodología. Son un veredicto sobre el momento: mucha gente tiene ahora agentes que escriben código más rápido de lo que pueden supervisar, y busca algo que abarate la supervisión. Superpowers es una respuesta. Que esté hecha de Markdown es la parte más interesante.