AI
El plugin Superpowers para Claude Code: el flujo de trabajo estructurado que realmente funciona
Este artículo es una traducción del artículo original en inglés.
El plugin Superpowers alcanzó 107.000 estrellas en GitHub en cinco meses. Tiene 8.600 forks. Se lanzó en octubre de 2025 y ya es uno de los repositorios de herramientas para desarrolladores de más rápido crecimiento en GitHub: más rápido que la mayoría de los frameworks consolidados, más rápido que la mayoría de los design systems, más rápido que casi cualquier cosa que no contara con el presupuesto de marketing de una gran empresa.
Eso no ocurre por accidente. Sucede cuando una herramienta resuelve un problema que los desarrolladores tienen de verdad, de una manera que realmente funciona.
El problema: programar con IA sin disciplina es lento, no rápido. Sé que suena contradictorio. Pero lo aprendí de la manera difícil construyendo Ding.
Ding es un proyecto en el que he creído durante mucho tiempo: un daemon de alertas sin estado que creo tiene casos de uso sólidos en el espacio de observabilidad, donde pasé años trabajando. La idea general es atractiva y sólida. La ejecución ha sido un reto.
Como muchos desarrolladores, he pasado el último año y medio construyendo mi proyecto favorito, desarmándolo y reconstruyéndolo desde cero con cada nueva ola de agentes de IA. Cada vez que sale un nuevo modelo o herramienta, Ding se convierte en mi prueba. No porque sea un proyecto de juguete, sino porque es genuinamente difícil. Requiere decisiones arquitectónicas reales, manejo real de concurrencia, diseño real de configuración. El tipo de cosas que expone si un agente realmente piensa o solo escribe rápido.
Los agentes han ido mejorando. Pero nunca había visto nada construir Ding tan limpiamente como lo hice con Superpowers.
Sin estructura, Claude avanza a toda velocidad con tu primera descripción vaga, construye con confianza en la dirección equivocada y te deja tres horas metido en algo que hay que tirar. La velocidad es real. El desperdicio también.
Si este problema te resulta familiar a nivel de equipo: Builder.io es una plataforma de desarrollo agéntico que ejecuta agentes de IA en paralelo con gates de revisión estructurados integrados: contenedores en la nube, sin configuración local, gratis para empezar. Vale la pena echarle un vistazo si quieres este tipo de disciplina en todo el equipo, no solo en sesiones individuales de Claude Code.
Superpowers soluciona eso. Es un plugin de Claude Code que impone un flujo de trabajo estructurado antes de que se escriba una sola línea de código. Primero el brainstorm. Aisla tu rama. Escribe un plan detallado. Luego ejecuta. Cada paso habilita el siguiente.
Esto es lo que realmente se siente usarlo, y dónde todavía tiene aristas sin pulir.
Cómo funciona realmente el plugin Superpowers para Claude
Superpowers es un plugin de Claude Code creado por Jesse Vincent y el equipo de Prime Radiant. Incluye una biblioteca de skills: archivos markdown con instrucciones, listas de verificación y diagramas de proceso que Claude lee antes de actuar. El plugin es el contenedor. Las skills son los flujos de trabajo que proporciona.
La secuencia obligatoria tiene cuatro pasos:
- Brainstorm — sin código hasta que tengas un documento de diseño aprobado por un humano
- Git worktree — rama aislada para que main nunca se toque
- Escribe un plan — un documento que divide el trabajo en tareas de 2 a 5 minutos con rutas de archivos exactas, comandos exactos y código completo
- Ejecuta — los subagentes implementan cada tarea; revisión en dos etapas después de cada una
Piénsalo como contratar a un constructor. La mayoría de las herramientas de IA para programar son como entregarle un brief vago y un juego de llaves. Superpowers es la revisión del contrato, la aprobación del plano y la lista de verificación final, antes de que nadie toque una pared.
Antes de instalarlo, probablemente estés pensando: esto suena lento. No lo es. Déjame mostrarte por qué.
La fase de brainstorm no es opcional
Es lo más importante que hace el plugin, y lo más fácil de descartar como una carga innecesaria.
Antes de que la implementación de Ding v1 tocara un solo archivo Go, la sesión de brainstorm produjo un documento de especificación de 424 líneas. No un esquema aproximado, sino un diseño detallado que resolvió cada decisión arquitectónica significativa antes de que comenzara la implementación.
Tres de esas decisiones habrían sido costosas de equivocar a mitad de la construcción:
Cooldowns por conjunto de etiquetas, no por regla. La especificación estableció que cpu_spike disparándose para host=web-01 no bloquea que se dispare para host=web-02. Ese es el comportamiento correcto para una herramienta de alertas multi-host. Tampoco es la primera implementación obvia. Sin la especificación, el rastreador de cooldowns casi con certeza habría sido indexado por regla, y luego habría necesitado una refactorización cuando apareciera el primer caso de uso real con múltiples hosts.
El notificador integrado stdout. La especificación definió stdout como un nombre de notificador especial que puedes referenciar directamente en una regla sin declararlo en el mapa notifiers:. Decisión simple, seis líneas menos en la configuración mínima, tomada en el documento de diseño. Sin ella, el plan habría generado una declaración completa de StdoutNotifier desde el inicio.
Semántica del hot-reload. La especificación definió que las evaluaciones en curso se completan antes del intercambio del motor: bloqueo de escritura en el intercambio, bloqueos de lectura durante la evaluación. Equivocarse aquí habría producido una condición de carrera casi imposible de reproducir y depurar. Se decidió correctamente en la especificación y se implementó correctamente a la primera.
El brainstorm también produjo una lista clara de elementos fuera del alcance: condiciones compuestas (AND, OR), soporte nativo para PagerDuty, lógica de reintentos para webhooks fallidos. Cada vez que surgía el impulso de «sería bueno agregar...» durante la ejecución, la respuesta estaba justo ahí en la especificación. Sin discusión, sin drift.
Las preguntas parecen lentas. No lo son. Están evitando que tres días de trabajo vayan en la dirección equivocada.
El plan tiene código real
La mayoría de los planes son vagos. «Agrega validación al parser de configuración.» Bien, pero ¿qué significa eso exactamente?
El formato de plan de Superpowers es diferente. La skill de escritura de planes produce planes con código completo, no pseudocódigo. Para la tarea de validación de configuración de Ding v1, el plan contenía el test de fallo completo:
Junto con el comando exacto go test, la salida esperada ("FAIL — Validate not defined"), la implementación completa de Validate(), el comando para verificar que pasa y el mensaje del commit.
El plan v1 cubrió 17 archivos en todo el proyecto, mapeados en una tabla de archivos al inicio que mostraba exactamente de qué era responsable cada archivo. La implementación produjo 26 commits en secuencia, cada uno correspondiente a una tarea del plan.
Un plan tan específico también es revisable. Después de escribir el plan, un subagente de cumplimiento de especificaciones lo revisó y detectó que BenchmarkEngineSwap no coincidía con la terminología EngineReinit de la especificación: una inconsistencia de nomenclatura que habría producido un resultado de benchmark confuso. Eso se corrigió antes de que comenzara la ejecución.
La lección: un plan debe ser tan detallado que alguien sin contexto del proyecto pueda implementarlo correctamente. Si escribes instrucciones vagas, esa vaguedad se convertirá en un bug.
Dónde el plugin Superpowers para Claude tiene dificultades
El flujo de trabajo es excelente para construir features. No está diseñado para pelear con tu entorno.
La depuración del entorno no está en el plan. La suite de benchmarks de Ding fue planificada para un entorno Unix genérico. Ejecutarla en macOS provocó 10 commits de corrección separados después de la implementación inicial:
date +%s%Nno existe en macOS BSD date. Todos los scripts de latencia e inicio usaban timestamps en nanosegundos. Todos necesitaron una función portátilns_now().eval "$start_cmd" &seguido dekill $!no termina el proceso objetivo de forma confiable cuando bash mantiene un wrapper de subshell.$!era el PID del subshell, no el de Ding. Ding seguía ejecutándose como proceso huérfano, manteniendo el puerto ocupado y haciendo que el siguiente intento de inicio fallara. Se solucionó agregandopkill -9 -f "ding serve"para capturar procesos huérfanos.docker run -ddevuelve un ID de contenedor en stdout, pero$!es el PID del proceso CLI de docker. Diez inicios consecutivos del contenedor de Prometheus fallaron porque el primer contenedor nunca se detuvo.
Nada de esto era planificable de antemano. El comportamiento del shell de macOS no es algo sobre lo que puedas razonar a partir de una especificación. La depuración fue fundamentalmente iterativa: ejecutar, ver cómo falla, formular una hipótesis, probarla, encontrar un fallo diferente.
Cuando el entorno te está dando problemas, sal del flujo de trabajo del plan. Arregla el entorno. Luego vuelve. El plan es para construir features, no para apagar incendios.
Los planes heredan los errores de la especificación. El plan se genera a partir de la especificación. Si la especificación está equivocada, el plan lo estará de la misma manera.
La especificación del benchmark se escribió a partir de la documentación de Ding y las configuraciones de ejemplo. Las configuraciones en los ejemplos lucían así:
Pero el parser de configuración real requería un mapa notifiers: separado:
Todos los scripts de benchmark estaban equivocados de la misma manera. Cuando los tests se ejecutaron, las 100 muestras de latencia agotaron el tiempo de espera porque Ding rechazó las configuraciones al inicio. El revisor de cumplimiento de especificaciones lo detectó, pero lo detectó porque alguien notó que los tests estaban fallando, no porque capturara el error de la especificación antes de que se propagara.
La solución: antes de finalizar una especificación que interactúa con código existente, haz una verificación rápida contra el código real. Lee las funciones de validación, no solo los archivos de ejemplo. Las especificaciones escritas a partir de documentación omiten los casos extremos que el código implementa.
Tres cosas que debes interiorizar antes de empezar
La especificación es la fuente de verdad para todo lo que sigue. Cada pregunta de «¿es esto correcto?» se resuelve leyendo la especificación, no adivinando. Cuando el scope creep apareció durante Ding v1 —«sería natural agregar condiciones AND aquí»— la respuesta fue inmediata: las condiciones compuestas están listadas bajo «Fuera del alcance (v1)». Sin discusión. Sin drift.
El plan necesita el test antes que el código. La skill de escritura de planes está construida alrededor de TDD: escribe el test de fallo, verifica que falla, escribe la implementación mínima, verifica que pasa, haz el commit. Ese orden importa. Cuando leas el plan que genera la skill, verifica que cada tarea tenga un paso de test antes del paso de implementación. Si no lo tiene, el plan está incompleto.
Marca las tareas a medida que avanzas. El documento del plan es tu mecanismo de recuperación si una sesión muere. El plan tiene casillas de verificación para cada paso: marcarlas no es trabajo administrativo, es el registro de estado. En el trabajo con Ding, el registro de commits de git cumplió esta función porque cada tarea completada se confirmaba antes de que terminara la sesión. Pero en una sesión donde las tareas están parcialmente completas cuando la sesión muere, las casillas sin marcar en el plan son la única manera en que la siguiente sesión sabe dónde reanudar.
El modelo central de Superpowers
Superpowers es un plugin de imposición de disciplina, no un sistema de entrega de features. No hace que Claude sea más rápido escribiendo líneas de código individuales. Hace que el proceso general sea más rápido al prevenir errores costosos y haciendo el trabajo reanudable, revisable y corregible.
Los tres gates duros:
No puedes construir lo que no has diseñado. El gate de brainstorm es duro. Saltártelo significa implementar lo incorrecto. En el proyecto Ding, el brainstorm decidió los cooldowns por conjunto de etiquetas, la semántica del mutex de hot-reload y el notificador integrado stdout antes de que comenzara la implementación. Equivocarse en esas cosas a mitad de la implementación habría requerido un retrabajo significativo.
No puedes ejecutar lo que no has planificado. El gate del plan es duro. Saltártelo y los subagentes se desvían. El plan de Ding v1 especificó 17 archivos y 26 tareas. El plan del benchmark especificó 13 archivos y 22 tareas. Los subagentes siguieron esos planes sin ambigüedad.
No puedes publicar lo que no has revisado. El gate de revisión es duro. Saltártelo y los bugs se cuelan. La revisión de cumplimiento de especificaciones detectó el error de formato de configuración en los scripts de benchmark antes de que se convirtiera en un misterio de depuración de varias horas.
El sistema es honesto sobre lo que no resuelve: la depuración del entorno, la recuperación de sesiones tras interrupciones catastróficas y los errores de especificación que pasaron la revisión porque la especificación en sí estaba equivocada sobre el comportamiento real del código. Para esas situaciones, sales del flujo de trabajo, arreglas el problema y regresas. El flujo de trabajo es una guía, no una camisa de fuerza.
Primeros pasos con Superpowers para Claude Code
Inicia una nueva sesión de Claude Code. Describe algo que quieras construir. No intentes activar las skills manualmente: se activan automáticamente. Si quieres verificar la instalación, di «Quiero construir una nueva feature para este proyecto» y observa cómo se activa la skill de brainstorming antes de que Claude haga una pregunta de aclaración.
Encuentra el proyecto Ding mencionado en este artículo en github.com/zuchka/ding. Los documentos de especificación (docs/superpowers/specs/), los planes de implementación (docs/superpowers/plans/) y los resultados del benchmark (benchmarks/results/latest.json) están todos en el repositorio.
- Código fuente: github.com/obra/superpowers (MIT)
- Discord: discord.gg/Jd8Vphy9jq
- Creado por: Jesse Vincent y el equipo de Prime Radiant
En Builder.io, hemos estado pensando mucho en flujos de trabajo estructurados similares dentro de Fusion: la idea de que el desarrollo asistido por IA funciona mejor cuando el proceso impone disciplina, no solo capacidad. Si estás experimentando con Superpowers o flujos de trabajo estructurados de Claude Code, me encantaría saber cómo te está yendo.
Preguntas frecuentes sobre Claude Superpowers
¿Qué es el plugin Superpowers para Claude Code?
Superpowers es un plugin de Claude Code creado por Jesse Vincent y el equipo de Prime Radiant. Impone un flujo de trabajo estructurado de cuatro pasos: brainstorm, aislar un git worktree, escribir un plan detallado y luego ejecutar, antes de que se escriba cualquier código. Se distribuye como una biblioteca de «skills»: archivos markdown con instrucciones, listas de verificación y diagramas de proceso que Claude lee antes de actuar.
¿Cómo instalo el plugin Superpowers?
Ejecuta este comando en una sesión de Claude Code:
Una vez instalado, las skills se activan automáticamente. No las activas manualmente: solo describe lo que quieres construir y la skill de brainstorming se activará por sí sola.
¿Cuáles son los cuatro pasos del flujo de trabajo de Superpowers?
- Brainstorm — Claude produce un documento de diseño que apruebas antes de que se escriba cualquier código
- Git worktree — el trabajo ocurre en una rama aislada para que main nunca se toque
- Escribe un plan — un documento detallado con rutas de archivos exactas, comandos y código completo dividido en tareas de 2 a 5 minutos
- Ejecuta — los subagentes implementan cada tarea con una revisión en dos etapas después de cada una
¿El flujo de trabajo estructurado ralentiza las cosas?
No: hace que el proceso general sea más rápido al prevenir errores costosos. Saltarse el brainstorm significa implementar lo incorrecto. Saltarse el plan significa que los subagentes se desvían. Las preguntas iniciales parecen lentas; las horas que ahorran a mitad de la implementación no son visibles. Cada gate existe porque el costo de equivocarse más adelante es mucho mayor.
¿Qué es una «skill» en el plugin Superpowers?
Una skill es un archivo markdown con instrucciones, listas de verificación y diagramas de proceso. El plugin es el contenedor; las skills son los flujos de trabajo que proporciona. Cuando activas una acción como el brainstorming o la escritura del plan, Claude lee el archivo de skill relevante antes de proceder. La biblioteca de skills es lo que separa a Superpowers de simplemente darle instrucciones directas a Claude.
¿Puede Superpowers manejar la depuración del entorno y fallos inesperados?
No por diseño. El flujo de trabajo está construido para el desarrollo de features, no para apagar incendios. Cuando el entorno está rompiendo activamente las cosas —comportamiento incorrecto del shell, peculiaridades específicas de la plataforma, incompatibilidades de infraestructura— sal del flujo de trabajo del plan, arregla el entorno y luego regresa. El plan es una guía, no una camisa de fuerza.
¿Qué ocurre si la especificación tiene un error?
Los planes heredan los errores de la especificación. Si la especificación está equivocada, el plan lo estará en la misma dirección. La mitigación es hacer una verificación rápida contra el código real antes de finalizar una especificación: lee las funciones de validación, no solo los archivos de ejemplo. Las especificaciones escritas únicamente a partir de documentación pueden omitir los casos extremos que el código realmente implementa.
¿El plugin Superpowers es gratuito y de código abierto?
Sí. El plugin está disponible en github.com/obra/superpowers bajo la licencia MIT. También hay un Discord de la comunidad en discord.gg/Jd8Vphy9jq.
Share
