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 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:

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 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 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 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 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 y el prompt del revisor 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 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 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 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

Para reparar una sola comprobación de aceptación, consulta la guía de BIG CHANGE para verificar una comprobación de repositorio fallida. El proceso aquí empieza antes, con el diseño y plan de un cambio de varias tareas.