Edición en Markdown

AI-translated from English; not yet reviewed by a fluent editor.

# Usa Superpowers en Claude Code para planificar, probar y revisar un cambio de código

> Una guía basada en documentación para llevar un cambio autorizado por un diseño y plan Superpowers aprobados, pruebas rojo-verde observadas, revisión de tareas y de toda la rama, y una decisión del responsable.

By BIG CHANGE Editorial

Published: 2026-10-20T10:39:38.153Z
Updated: 2026-10-20T10:39:38.153Z
Canonical: https://bigchange.ai/blog/superpowers-claude-code-plan-test-review-change-guide

![Conceptual charcoal illustration of a long, unlettered code-diff proof sheet emerging from a printer across an inspection table, with a short orange passage.](https://bigchange.ai/api/media/file/superpowers-whole-branch-proof-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE.

Superpowers puede guiar a un usuario de Claude Code por un cambio importante en un repositorio Git que controla: acordar el diseño, aprobar un plan de tareas, implementar con pruebas, revisar cada tarea e inspeccionar la rama final. Esta guía sigue los manuales oficiales de Superpowers 7.0.0 consultados el 20 de octubre de 2026. BIG CHANGE revisó la documentación; no instalamos el plugin ni ejecutamos el proceso en un proyecto.

## El gran cambio

- **Qué cambió:** Un diseño y un plan de implementación aprobados dan a los agentes de programación una tarea concreta y restricciones antes de modificar el repositorio.
- **Por qué importa:** El flujo documentado combina fallos y éxitos observados en las pruebas con dictámenes separados de especificación y calidad de un mismo revisor, seguidos de una revisión más amplia de toda la rama.
- **Qué vigilar:** El responsable sigue comprobando el diff completo y resultados recientes de aceptación, y decide qué ocurre con la rama. Un flujo de agentes terminado puede conservar hallazgos declarados.

## Antes de empezar

Elige un cambio autorizado de varios pasos en un repositorio que controles o puedas editar. Debe dividirse en tareas revisables y tener un comportamiento comprobable. Anota el comportamiento solicitado, el área afectada, las exclusiones, el comando original de aceptación y el commit inicial. Ejecuta ese comando y las comprobaciones existentes pertinentes antes de empezar. Si la referencia inicial ya falla, identifica ese fallo ahora: un resultado posterior verde o rojo necesita un punto de partida conocido.

Necesitas Git, una instalación autenticada de Claude Code, permiso para instalar plugins y crear una rama o worktree, y capacidad suficiente del plan o API para Claude Code y sus subagentes. Revisa las normas de tu organización sobre acceso al código fuente y uso de plugins. Examina el contenido del plugin, los permisos efectivos, las condiciones de datos del proveedor y los controles de gasto antes de activarlo. Anthropic advierte que los hooks y procesos de servidor de los plugins pueden ejecutarse con tus privilegios de usuario fuera del aislamiento de las llamadas a herramientas; las solicitudes habituales de permiso de las herramientas no cubren todo ese código. Mantén secretos, dependencias, escrituras externas, envíos y despliegues dentro de tu autoridad real. [La documentación de seguridad de plugins de Claude Code](https://code.claude.com/docs/en/plugins/security) explica este límite.

El recorrido siguiente usa la habilidad de Superpowers `subagent-driven-development` para un cambio con varias tareas. Los manuales también describen un recorrido integrado `executing-plans` y permiten acuerdos de diseño más simples para trabajos pequeños. Elige el recorrido con el responsable antes de implementar, sin suponer que todo proyecto debe seguir la secuencia completa.

## 1. Instala el plugin y verifica la versión activa

En una sesión interactiva de Claude Code, introduce el [comando del catálogo oficial](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/README.md):

```text
/plugin install superpowers@claude-plugins-official
```

Claude Code abre un panel de detalles del plugin antes de instalarlo. Inspecciona su contenido y elige un ámbito permitido. El ámbito local lo activa para ti en este repositorio; el de proyecto afecta a la configuración del repositorio de los colaboradores. Lee el resumen de instalación y la pestaña Errors. Sigue las instrucciones de activación de la sesión o reinicia, luego comprueba la pestaña Installed y ejecuta `claude plugin list` en una terminal. Registra Version, Scope y Status tal como aparecen, y confirma que las habilidades Superpowers estén disponibles en la sesión activa. El comando del catálogo no fija el commit de referencia de esta guía. Si la versión instalada o el texto de sus habilidades difiere de 7.0.0, adapta el procedimiento a esa versión antes de continuar. Una instalación fallida o desactivada exige detenerse; no demuestra que el flujo esté cargado. [La guía de instalación de Claude Code](https://code.claude.com/docs/en/discover-plugins) documenta estas comprobaciones.

## 2. Aprueba el diseño y después el plan

Comunica a Claude Code el cambio real, los criterios de aceptación, el resultado inicial y las modificaciones prohibidas. Usa el proceso de Superpowers `brainstorming` para concretar la intención, las decisiones de diseño y las restricciones. Para este cambio de varios pasos, examina el diseño escrito y los hallazgos de comprobación de construcción, resuelve las cuestiones que correspondan al responsable y aprueba la descripción completa. La aprobación debe describir el comportamiento que se construirá; no debe deducirse de que el agente siga hablando. El [manual de diseño](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/skills/brainstorming/SKILL.md) permite acuerdos más ligeros o una exclusión explícita para trabajos pequeños, por lo que aquí se elige deliberadamente el recorrido completo para una tarea importante.

Después, pide al proceso `writing-plans` que convierta el diseño en tareas. Revisa límites de archivos, interfaces, restricciones globales, comandos de prueba y Review Focus del plan. Cada tarea debe poder inspeccionarse y su prueba debe medir el comportamiento acordado. Aprueba el plan y el enfoque de ejecución con subagentes antes de cambiar código. [El manual de planificación](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/skills/writing-plans/SKILL.md) define la entrega. No confundas un plan plausible con permiso para añadir dependencias o modificar archivos ajenos al trabajo.

Al ejecutar, `using-git-worktrees` comprueba si hay un espacio de trabajo existente adecuado o prepara uno aislado con el consentimiento necesario. Registra su rama real, commit base y estado inicial limpio. Usa el soporte nativo de worktrees de Claude Code cuando esté disponible. Si hay cambios ajenos, resuelve su titularidad antes de continuar. [El manual de worktrees](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/skills/using-git-worktrees/SKILL.md) describe las comprobaciones y la creación.

## 3. Observa cada prueba y revisión de tarea

Con el plan aprobado, usa `subagent-driven-development` para tareas revisables de forma independiente. El manual actual asigna un implementador a una tarea y después entrega su implementación y diff a **un solo revisor de tarea**. Este devuelve dos juicios: si la tarea coincide con la especificación y si su calidad de implementación es aceptable. Son dos dictámenes de una misma revisión, no dos agentes revisores consecutivos. Las tareas pequeñas de la misma forma pueden agruparse según las reglas del manual. [El flujo de tareas](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/skills/subagent-driven-development/SKILL.md) y el [prompt del revisor](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/skills/subagent-driven-development/task-reviewer-prompt.md) establecen esta secuencia.

Para cada comportamiento adecuado a probar primero, exige un ciclo rojo-verde observable: añade la prueba de comportamiento, ejecútala y observa el fallo esperado; realiza la implementación mínima, repite la prueba y observa que pasa; después refactoriza manteniendo las comprobaciones en verde. Un error de importación o un arnés de pruebas roto no es el resultado rojo esperado. Conserva comando, salida y commit o diff relevante de cada tarea. El [manual de desarrollo guiado por pruebas](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/skills/test-driven-development/SKILL.md) describe excepciones que requieren acuerdo humano; esta guía supone una tarea adecuada al recorrido habitual de prueba previa.

Lee ambos dictámenes y el diff real. Resuelve cualquier punto de «no se puede verificar desde el diff» con el plan y el repositorio antes de aceptar la tarea. Inspecciona las correcciones y su nueva revisión acotada; una nueva afirmación de éxito no es un resultado de prueba reciente. El flujo 7.0.0 limita su bucle de corrección y puede aparcar hallazgos con decisiones escritas. Conserva esos hallazgos para la revisión posterior. Una tarea marcada como completa no implica una revisión sin reservas.

Cuando terminen las tareas, examina la **revisión separada de toda la rama**. Puede detectar interacciones entre tareas y reconsiderar hallazgos aplazados que un revisor no podía resolver desde un solo diff. Pide pruebas y decisiones para cada asunto abierto. Conserva diseño, plan, salidas de pruebas, informes de revisión y diff completo antes de limpiar el espacio temporal del plugin. Si una habilidad esperada no se activó, revisa el estado y la versión activos del plugin y el diagnóstico documentado; instalarlo no demuestra que se haya impuesto el flujo.

## 4. Comprueba la rama y decide su destino

Ejecuta otra vez el comando original de aceptación sobre el código final y toda la batería de pruebas del proyecto. Examina salidas recientes, el diff completo de la rama y todos los hallazgos pendientes. [El manual de verificación de Superpowers](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/skills/verification-before-completion/SKILL.md) exige pruebas del estado actual antes de declarar el trabajo terminado. Si falla la batería, identifica el fallo exacto y corrígelo o deja la rama para revisión; con pruebas fallidas no se llega al menú documentado de finalización.

En una rama con nombre, `finishing-a-development-branch` presenta fusión local, envío y creación de una pull request, o conservación de la rama tal cual. Un HEAD separado tiene las opciones pull request y conservación. Descartar solo se gestiona tras petición explícita del responsable y confirmación escrita; no es una cuarta opción habitual. [El manual de finalización de ramas](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/skills/finishing-a-development-branch/SKILL.md) explica estas opciones. Muestra al responsable las comprobaciones, el diff y las reservas restantes antes de que decida. Una fusión, envío, eliminación o despliegue necesita la autoridad correspondiente.

El resultado útil es una rama revisable vinculada al requisito original: diseño y plan aprobados, resultados de pruebas observados, ambos dictámenes de tarea, revisión de toda la rama, diff completo y resultado reciente de aceptación. Si la instalación, el acceso, el presupuesto o una comprobación detienen la ejecución, conserva los elementos verificados e indica la última etapa completada. La documentación describe un proceso; no prueba que el cambio no ejecutado de esta guía fuera más rápido, barato o tuviera menos defectos.

## Fuentes y lecturas adicionales

- [Superpowers 7.0.0: README e instalación](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/README.md): recorrido oficial del proyecto y su descripción del flujo. No verifica la versión instalada del lector ni sus resultados.
- [Manual de ejecución de tareas de Superpowers](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/skills/subagent-driven-development/SKILL.md): revisor de tarea, dos dictámenes, decisiones de corrección y revisión final de rama. Léelo junto con la versión realmente instalada.
- [Instalación de plugins de Claude Code](https://code.claude.com/docs/en/discover-plugins) y [seguridad](https://code.claude.com/docs/en/plugins/security): ámbito, activación, lectura de versión y privilegios de ejecución. Los controles de la organización pueden cambiar lo disponible.

Para reparar una sola comprobación de aceptación, consulta la [guía de BIG CHANGE para verificar una comprobación de repositorio fallida](https://bigchange.ai/blog/ai-goal-failing-repository-check-guide). El proceso aquí empieza antes, con el diseño y plan de un cambio de varias tareas.

## Sources

- [README de Superpowers en la versión 7.0.0](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/README.md) — Comando del catálogo oficial del proyecto y flujo general. Es una referencia fija, no la prueba de que el catálogo haya instalado ese commit exacto ni de que el flujo se ejecutara.
- [Habilidad brainstorming de Superpowers](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/skills/brainstorming/SKILL.md) — Documenta cuestiones de diseño, comprobación de construcción y aprobación humana; las tareas pequeñas pueden tomar un recorrido más ligero.
- [Habilidad writing-plans de Superpowers](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/skills/writing-plans/SKILL.md) — Documenta estructura del plan y entrega para revisión. No significa que se haya aprobado un plan para un proyecto no ejecutado.
- [Habilidad using-git-worktrees de Superpowers](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/skills/using-git-worktrees/SKILL.md) — Documenta la selección de un espacio existente o aislado, el consentimiento y las comprobaciones iniciales; no se creó ningún worktree para este artículo.
- [Habilidad subagent-driven-development y revisor de tarea de Superpowers](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/skills/subagent-driven-development/SKILL.md) — Establece un único revisor de tarea con dictámenes de especificación y calidad, bucles de corrección limitados, hallazgos aparcados y una revisión separada de toda la rama. La finalización puede incluir asuntos sin resolver con decisiones documentadas.
- [Habilidad test-driven-development de Superpowers](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/skills/test-driven-development/SKILL.md) — Documenta el ciclo esperado rojo-verde-refactorización y las excepciones acordadas con una persona. No se ejecutó ninguna prueba para este artículo.
- [Habilidad verification-before-completion de Superpowers](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/skills/verification-before-completion/SKILL.md) — Exige pruebas recientes de comandos reales para declarar la finalización; no puede establecer los resultados de esta guía.
- [Habilidad finishing-a-development-branch de Superpowers](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/skills/finishing-a-development-branch/SKILL.md) — Documenta opciones de ramas con nombre y HEAD separado, y descarte solicitado aparte con confirmación escrita. Sigue siendo necesaria la autoridad del responsable.
- [Instalar y gestionar plugins — Claude Code Docs](https://code.claude.com/docs/en/discover-plugins) — Panel actual de instalación, ámbitos, activación, pestaña Installed y lectura de versión, Scope y Status en la CLI; la política local puede cambiar la disponibilidad real.
- [Seguridad de plugins — Claude Code Docs](https://code.claude.com/docs/en/plugins/security) — Explica que los hooks y procesos de servidor de plugins pueden ejecutarse con privilegios de usuario fuera de las solicitudes del aislamiento de llamadas a herramientas; los usuarios deben revisar el acceso local.