Superpowers Claude: cómo instalarlo y elegir el flujo adecuado

¿Qué es Superpowers Claude?

Superpowers es la biblioteca de skills de ingeniería de Jesse Vincent, junto con las instrucciones que animan al agente de programación a utilizarlas. En Claude Code, el asistente de programación de Anthropic que trabaja con tu repositorio, aporta flujos para entender una solicitud, planificar cambios, probar, depurar, delegar y cerrar el trabajo de una rama. Funciona como el manual de un taller: las herramientas ya están ahí; el manual establece el orden de trabajo y las comprobaciones previas a la entrega. README de Superpowers

Verificado el 18 de octubre de 2026: el manifiesto del código fuente indica la versión 7.0.0, y el repositorio contiene 15 carpetas de skills de primer nivel con un archivo SKILL.md. Estos datos corresponden al código examinado para este artículo; comprueba qué revisión instala el marketplace que elijas. Manifiesto del plugin, directorio de skills

Su atractivo práctico está en hacer visible la secuencia de decisiones. Antes de modificar una función, Claude puede definir cómo debe comportarse. Antes de darla por terminada, puede exigir un resultado de pruebas recién obtenido. Esas instrucciones dejan algo concreto que revisar, pero no garantizan que los requisitos o las pruebas sean correctos.

Cómo instalar Superpowers en Claude

Utiliza una de las vías de instalación del README del proyecto, dentro de Claude Code. Los comandos siguientes se han copiado exactamente de su sección sobre Claude Code. Son comandos interactivos con barra inicial, no comandos para pegar en una terminal convencional. Instrucciones de instalación del README

Instalar el plugin de Superpowers desde el marketplace oficial

/plugin install superpowers@claude-plugins-official

El creador también documenta su propio marketplace. Si prefieres esa vía, primero regístralo y después instala el plugin:

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

Elige una fuente de instalación y lleva un registro de cuál utilizas. Usar ambas vías para instalar el mismo plugin no aporta ninguna ventaja.

Después de instalarlo, inicia una sesión nueva de Claude Code para activar el hook de inicio. Pídele una función de alcance acotado, como añadir un filtro a una lista de tareas existente. Comprueba si anuncia una skill adecuada y sigue sus instrucciones. Que el comando de instalación termine correctamente y que el flujo se comporte como esperas son dos comprobaciones distintas.

¿Qué cambia en la sesión después de instalarlo?

Lo primero que cambia es el contexto: un hook de inicio incorpora las instrucciones de uso de Superpowers a la conversación. El selector configurado para SessionStart cubre startup, clear y compact. Su script lee using-superpowers, inserta ese texto e indica a Claude que cargue las demás skills mediante la herramienta Skill. No pega el contenido completo de todas las skills en el mensaje inicial. Configuración del hook, script de inicio

¿Cómo elige Claude una skill de Superpowers?

Claude compara la tarea con las descripciones de las skills y después lee las instrucciones pertinentes. La guía de creación del plugin explica que las descripciones deben indicar cuándo corresponde usar cada skill. Las instrucciones iniciales piden al agente que lo compruebe antes de responder o actuar, anuncie la skill y dé prioridad a las skills de proceso sobre las de implementación. Guía para identificar las skills pertinentes

Así, una solicitud para construir algo apunta a brainstorming; una prueba que falla apunta a systematic-debugging. Después, una skill especializada en ese ámbito puede orientar la implementación. También puedes pedir una skill por su nombre: «Usa superpowers:systematic-debugging para investigar este fallo antes de proponer una solución». Instrucciones de uso

La selección automática es una instrucción para el modelo, no un selector determinista basado en palabras clave. El hook aporta el texto de arranque; el agente todavía debe reconocer la situación y seguir las instrucciones elegidas. Si toma el flujo equivocado, corrige el alcance de la tarea o solicita directamente la skill adecuada.

Las skills de Superpowers y cuándo se utilizan

La biblioteca abarca todo el ciclo de desarrollo, pero cada sesión debe cargar las skills que correspondan al trabajo. Estos son los nombres exactos de los archivos examinados. La columna de uso resume sus descripciones e instrucciones; no garantiza que una frase concreta active siempre una skill determinada. Directorio actual de skills

No hace falta memorizar la lista. Al desarrollar una función habitual, observa las transiciones: solicitud comprendida, plan concreto si hace falta, implementación probada, cambio revisado y decisión de integración. Ante un error, el punto de partida útil es investigar, en lugar de abrir una conversación de diseño sobre una función nueva.

Cómo convive con el modo de planificación nativo y tus propias skills

Superpowers establece un flujo alrededor de la planificación; su skill writing-plans es distinta del modo de planificación nativo de Claude Code. Las instrucciones iniciales actuales indican expresamente que se invoque brainstorming antes de entrar en el modo de planificación si esa fase aún no se ha realizado. Por tanto, fijan un orden de operaciones, en lugar de tratar el modo nativo y su skill de redacción de planes como equivalentes. Instrucción actual de planificación

writing-plans genera un documento en el repositorio, normalmente dentro de docs/superpowers/plans/, con decisiones de implementación y comprobaciones. Al entregarlo, pide al usuario que revise el plan y elija una forma de ejecutarlo, salvo que ya la haya indicado. Seleccionar un modo, por sí solo, no produce ese documento ni esas instrucciones para las tareas. Los controles y el comportamiento del entorno se explican en la guía del modo de planificación de Claude Code.

Tus propias skills siguen formando parte del conjunto. El archivo writing-skills del plugin identifica ~/.claude/skills/ como el directorio de skills personales de Claude Code. Además, sus instrucciones iniciales sitúan expresamente las instrucciones del usuario, incluidos CLAUDE.md y las peticiones directas, por encima de las instrucciones de las skills. Así, una skill específica del proyecto puede recoger tus convenciones mientras Superpowers aporta el proceso de desarrollo. Define bien ese reparto si ambas partes establecen cómo deben hacerse las pruebas o las revisiones. Archivo de creación de skills, prioridad de las instrucciones

Para entender el concepto de archivo de instrucciones en el que se basa, consulta las skills para agentes. Superpowers es una colección con un enfoque propio construida sobre ese mecanismo.

Superpowers en Claude Code: de la idea a la integración de una función

Un interruptor «Ocultar completadas» basta para mostrar el flujo completo. El ejemplo siguiente se ha elaborado a partir de los archivos de las skills; no es el registro de una sesión de prueba. Los nombres de archivo, los casos de aceptación y el resultado son hipotéticos.

Supongamos que una aplicación de listas de tareas ya cuenta con pruebas. El usuario pide un interruptor que oculte las tareas completadas sin eliminarlas. En este recorrido, solicita expresamente un plan escrito y revisiones de las tareas mediante subagentes. De lo contrario, un cambio tan pequeño podría seguir la vía abreviada, con la definición acordada en el chat.

Definir el comportamiento: brainstorming

La pregunta clave es si «ocultar» afecta solo a la vista actual o modifica las tareas guardadas. En este ejemplo se acuerda un filtro que solo afecta a la vista: el interruptor empieza desactivado, las tareas completadas reaparecen al desactivarlo y, si el filtro deja la lista vacía, se muestra un mensaje que indica que no hay tareas activas.

Claude reformula ese alcance y obtiene la aprobación. Como el usuario eligió la vía escrita, el diseño se guarda en un documento dentro de docs/superpowers/specs/, con una comprobación de quien vaya a implementarlo antes de la entrega. La vía habitual de la skill para cambios pequeños permite que la descripción y el acuerdo se queden en el chat. Reglas de brainstorming

Lo que debes revisar es el acuerdo sobre el comportamiento. Si introduce sin avisar preferencias guardadas o cambios en el almacenamiento de las tareas, la función ya habrá ampliado su alcance antes de empezar a implementarse.

Hacer que el trabajo se pueda comprobar: writing-plans

El plan divide la función en entregables que se pueden comprobar de forma independiente. Uno implementa una función de filtrado en un archivo ilustrativo, src/tasks/filterTasks.ts, con pruebas para listas mixtas, vacías y con todas las tareas completadas. Otro conecta un interruptor accesible en src/tasks/TaskList.tsx, utiliza la interfaz acordada para la función y prueba el resultado visible.

El plan especifica los archivos, las interfaces, las aserciones de las pruebas, los comandos de prueba del proyecto y los resultados esperados. También deja constancia de que el filtrado debe mantener intacta la colección original de tareas. El usuario revisa el plan y confirma la vía con subagentes. En este punto, una instrucción vaga se convierte en algo sobre lo que un implementador y un revisor pueden discrepar con precisión. Instrucciones para redactar planes

Preparar el espacio de trabajo: using-git-worktrees

Al preparar la ejecución, Claude comprueba si el trabajo ya está aislado. Un worktree de Git es otro directorio de trabajo del repositorio, normalmente en su propia rama. La skill da preferencia al mecanismo nativo de worktrees del entorno y respeta las preferencias que el usuario ya haya expresado; en caso contrario, pregunta antes de crear uno.

En este ejemplo, el usuario acepta crear un worktree para la función. Claude ejecuta allí las pruebas existentes del proyecto antes de cambiar la aplicación. Si las pruebas ya fallan en el estado de partida, hay que prestar atención a esos fallos antes de atribuir los posteriores al nuevo interruptor. Instrucciones del espacio de trabajo

Implementar las tareas: subagent-driven-development y test-driven-development

El agente coordinador asigna la tarea de filtrado a un implementador nuevo y después organiza su revisión. Tras ese control, pasa a la tarea de interfaz. La skill actual de subagentes comprueba el cumplimiento de la especificación y la calidad del código en la revisión de cada tarea, y después exige una revisión más amplia de la rama terminada. También registra el progreso y las decisiones en un registro específico del plan. Flujo con subagentes

Durante la implementación, test-driven-development aporta el ciclo rojo-verde-refactorización. Aquí, una prueba demuestra primero que, al solicitar la vista filtrada, todavía se devuelve una tarea completada. Solo después de observar ese fallo, el implementador añade el filtrado, vuelve a ejecutar la prueba y limpia el código manteniendo todas las pruebas en verde. Instrucciones de TDD

Para el entregable de interfaz, la aserción útil comprueba qué ve el usuario después de accionar el interruptor. Una prueba que solo compruebe si se llamó a una función no demostraría el comportamiento visible de la función desarrollada.

La alternativa es executing-plans: Claude implementa el plan por sí mismo en la sesión actual y, si hay subagentes disponibles, al final incorpora un revisor nuevo para toda la rama. Elige esa vía cuando no necesites una estructura de revisión con entregas por tarea. Instrucciones para ejecutar el plan en la sesión actual

Resolver los hallazgos: skills de revisión y systematic-debugging

En la revisión final de la rama, requesting-code-review prepara la entrega al revisor. Supongamos que este detecta que desactivar el interruptor no hace reaparecer las tareas completadas. receiving-code-review exige contrastar ese hallazgo con el código y el comportamiento previsto antes de cambiar nada. Solicitud de revisión, recepción de comentarios

Si el fallo se reproduce, systematic-debugging guía la investigación. Sus fases abarcan la investigación de la causa raíz, el análisis de patrones, la comprobación de hipótesis y la implementación. En el ejemplo, la hipótesis podría ser que el código sustituyó la colección original por la filtrada. Examina ese flujo de datos, reproduce la pérdida y corrige la causa con una prueba de regresión. No te limites a forzar el estado visual del interruptor para que parezca correcto. Instrucciones de depuración

Demostrar que el trabajo está terminado y decidir cómo integrarlo

verification-before-completion exige resultados de comandos recién ejecutados antes de afirmar que el trabajo salió bien. Para esta función, eso implica aportar evidencias del comportamiento del filtro, de la interacción con el interruptor y de las comprobaciones pertinentes del proyecto, e indicar claramente cualquier fallo pendiente. Instrucciones de verificación

Después, finishing-a-development-branch verifica toda la batería de pruebas y presenta las opciones de integración. En una rama convencional con nombre, el archivo actual ofrece una integración local, subir la rama y crear una pull request, o conservar la rama. Espera la decisión del usuario: superar una revisión no autoriza de forma implícita a integrar los cambios.

Para completar el ejemplo, el usuario elige una integración local en la rama base confirmada. Claude integra los cambios, prueba el resultado y solo elimina el worktree y la rama de la función cuando esas pruebas pasan. Si se creara una pull request, el trabajo quedaría pendiente del proceso de integración del repositorio. Instrucciones de cierre de la rama

Cuándo una tarea pequeña necesita menos proceso

El proceso se convierte en una carga cuando sigue pidiendo decisiones que la solicitud ya dejó resueltas. Cambiar una etiqueta visible con un texto de reemplazo exacto no debería exigir la misma preparación que modificar cómo se guarda el estado de las tareas. Esta valoración se refiere al trabajo que añade el flujo; no es una afirmación medida sobre el tiempo empleado.

El archivo actual de brainstorming distingue tres tamaños:

• Tarea rápida y clara: la propia solicitud contiene la descripción necesaria; ejecútala.
• Cambio pequeño: acuerda la descripción en el chat y después implementa el cambio con el flujo habitual.
• Proyecto: aprueba un diseño escrito y después elabora un plan completo de implementación del software.

Ese mismo archivo permite que el usuario pida expresamente omitir las preguntas, con lo que termina ese requisito previo de brainstorming. Esto no cancela automáticamente las demás instrucciones de pruebas o verificación. Reglas para dimensionar la tarea y omitir las preguntas

Una instrucción útil sería: «Este es un cambio pequeño. Mantén la descripción en el chat, usa la configuración de pruebas existente y no amplíes la función». Para una corrección de redacción ya decidida, indica el texto exacto y el alcance. Son restricciones de la tarea que la jerarquía de instrucciones del plugin reconoce, no comandos secretos para eludirla.

El límite concreto es la carga adicional del proceso: más conversaciones, documentos de planificación, asignaciones y revisiones pueden resultar desproporcionados frente a las dudas que quedan por resolver. El código fuente documenta esos pasos; no dice cuántos minutos tardará tu cambio. Si la sesión ignora repetidamente su alcance, el repositorio incluye diagnosing-superpowers para examinar lo ocurrido a partir de las evidencias de la transcripción. Skill de diagnóstico de sesiones

¿Qué expectativas sobre Superpowers están exageradas?

Seguir un flujo prescrito no demuestra que el software sea correcto ni que se haya desarrollado más rápido. Una prueba que falla puede representar un requisito equivocado, un plan puede omitir una restricción de integración y un agente revisor puede pasar por alto un defecto. Evalúa las aserciones y el diff, no la seguridad con la que esté redactado el mensaje de finalización.

Trabajar con subagentes tampoco significa que todas las tareas de implementación se ejecuten a la vez. La skill actual prohíbe expresamente usar subagentes de implementación en paralelo dentro de ese flujo para evitar conflictos. dispatching-parallel-agents es una skill distinta, destinada a problemas independientes. Reglas de asignación de la implementación

Instalarlo tampoco te exime de decidir el alcance de la tarea o su integración. El propio procedimiento de cierre del plugin deja la decisión de integrar los cambios en manos del usuario. Su promesa más sólida se refiere al proceso: indica a Claude qué comprobar y qué evidencias presentar. Su utilidad depende del trabajo y de que el agente siga esas instrucciones.

A quién le conviene instalarlo y qué probar después

Instálalo cuando el problema recurrente sea que se omiten decisiones de ingeniería. Si desarrollas por tu cuenta y tu agente pasa por alto los requisitos, empieza con una función de alcance acotado que tenga un caso de fallo significativo. Comprueba si la sesión define el comportamiento antes de implementar y aporta evidencias después.

Si ya trabajas con un equipo de desarrollo, primero armoniza sus convenciones de planificación, pruebas y revisión con las instrucciones del plugin. Cuando tus skills actuales ya recogen el proceso deseado, añadir otro flujo general puede duplicarlo. Si la mayor parte del trabajo consiste en cambios mínimos y completamente especificados, hay menos motivos para adoptar todo el método solo para resolver esas tareas.

El lunes, elige un cambio acotado y escribe sus criterios de aceptación. Usa Superpowers, examina las skills seleccionadas, revisa el diff final y decide si cada documento o resultado adicional te ayudó a tomar una decisión. Conserva el flujo porque sus comprobaciones fueron útiles, no porque generó un plan largo.

Para conocer herramientas relacionadas que resuelven otros problemas, consulta los mejores plugins de Claude Code.

Preguntas frecuentes sobre Superpowers Claude

Para recibir consejos prácticos sobre cómo desarrollar con IA, suscríbete al boletín.