Para quién es este manual
No es para todo el mundo. Si esperas un juguete para hacer mockups, vete. Si tienes proyecto real, sigue.
Hay dos formas de leer este artículo. La primera: como espectáculo. Mira lo que hace la IA. Te lo lees, te suena interesante, no aplicas nada. La segunda: como manual. Lo guardas. Vuelves. Lo aplicas. Y mañana te ahorras tres horas en una sesión que ibas a perder.
Esto está escrito para la segunda. Si tienes un proyecto real, una web, una app, una integración, una base de datos sucia, un agente que no funciona, y has oído hablar de Claude Code y Superpowers pero no sabes por dónde meterle el diente, este es tu sitio.
Si lo que buscas es un curso bonito con diapositivas y testimonios, también vete. Aquí no hay curso. Hay manual.
Lo que sigue son las cuatro skills que uso, los tres modelos que combino, los ocho errores que ya he cometido para que tú no los repitas, el checklist de cierre antes de cada commit, y el momento exacto en el que NO merece la pena usar Superpowers.
Las cuatro skills, en plata
Qué hace cada una y cuándo Claude las invoca. Sin tecnicismo gratuito.
Una skill en Superpowers no es un comando. Es un workflow con checklist que Claude detecta y aplica cuando la tarea encaja. Tú no las llamas. Las invoca el modelo cuando el contexto dispara la regla. Estas son las cuatro que de verdad mueven la aguja.
Brainstorming — de idea cruda a spec aprobado
Cuando llegas con una idea vaga («quiero rediseñar la home», «quiero un agente que llame y agende»), Claude no salta a codear. Invoca brainstorming. Y empieza a preguntar.
Una pregunta cada vez. Multiple choice cuando es posible. Te propone dos o tres approaches con tradeoffs antes de decidir nada. Te enseña el diseño por bloques y pide tu OK tras cada uno.
El hard gate: no invoca ninguna skill de implementación hasta que apruebas el spec por escrito. Si te saltas el spec, todo lo que venga después estará mal.
- Cuándo se invoca: cualquier tarea con peso (rediseños, features, refactors)
- Cuándo NO: bugs con causa clara, typos, cambios menores
- Salida: un spec en markdown que tú apruebas
Writing Plans — de spec aprobado a plan ejecutable
Coge el spec y lo descompone en tareas de dos a cinco minutos. Cada tarea lista los archivos exactos que toca, qué cambios, qué commit message. No hay pseudocódigo. Hay código listo para ejecutar.
La regla más importante: prohibido escribir «TODO», «TBD» o «implementar después». Si el plan no es ejecutable en frío por alguien que no conoce el proyecto, no pasa.
- Cuándo se invoca: cuando el spec está aprobado
- Salida: un plan con N tareas atómicas, ordenadas
- Aprobación: tú apruebas el plan antes de que se ejecute
Subagent-Driven Development — el plan se ejecuta con dos cabezas
Por cada tarea, lanza un subagente implementer con contexto curado. Solo recibe su tarea, no el plan entero. Hace el trabajo. Cuando termina, lanza un subagente reviewer que verifica el código contra el spec.
El reviewer no confía en el informe del implementer. Lee el código real. Comprueba que existen las variables, que las funciones están definidas, que no hay CSS huérfano. Si encuentra problemas, vuelve al implementer y repite hasta APPROVED.
- Cada subagente tiene contexto aislado: el principal no se llena de basura
- Tareas paralelas funcionan si tocan archivos distintos
- Si tocan los mismos archivos, en serie
Visual Companion — los mockups en tu navegador
Servidor local que sirve los mockups HTML a tu navegador. Cada vez que Claude genera un mockup nuevo, lo ves en pantalla completa en tiempo real. Comparar tres mockups por chat es ilegible. Comparar tres mockups en pantalla cambia la decisión.
- Ideal para iteraciones de hero, cards, layouts
- Reduce los ciclos de «no me gusta, otra vez» a la mitad
- Te ahorra explicar con palabras lo que se ve mejor con la pantalla
Qué modelo para qué fase
Opus para decidir. Sonnet para ejecutar. Haiku para leer. La tabla mental que uso a diario.
Claude Code te deja elegir modelo. No uses siempre el más caro. Es tirar dinero y a veces tirar calidad. Cada modelo tiene un punto donde brilla. Esta es mi tabla:
La regla práctica
Empiezo cualquier proyecto serio con Opus para discutir el spec. Una vez aprobado, cambio a Sonnet para escribir el plan y ejecutarlo con subagentes. Si en mitad del camino aparece un bug raro y tengo que leer ciento veinte líneas de log, paso a Haiku solo para esa lectura, vuelvo el resumen al chat principal y sigo con Sonnet.
El error que más veo en gente nueva: usar Opus para todo. Pagas siete veces más por escribir un bucle for que Sonnet escribe igual de bien. Y agotas el contexto antes de tiempo.
La economía en una línea
Opus es para los cinco minutos de cada hora en los que decides. Sonnet es para los cincuenta minutos en los que ejecutas. Haiku es para los cinco minutos en los que tragas información antes de volver a decidir.
Los ocho errores reales con su solución
No los he leído en un libro. Los he cometido yo. Aquí están con su solución exacta.
Esto es lo que más duele de un manual: aceptar que vas a tropezar. Bien. Aquí están los ocho tropiezos por adelantado.
Worktree por inercia cuando yo quería main
Qué pasó: empezamos una sesión y Claude, por costumbre vieja, creó un worktree separado para trabajar. Su memoria persistente decía «esta usuaria siempre quiere worktree». No era verdad ya. Yo quería trabajar directo en main esa sesión.
El coste: hora y media perdida y cambios que hubo que reaplicar a mano.
Empieza cada sesión nueva diciendo dónde quieres trabajar. «Hoy en main, no quiero worktree». La memoria persistente es útil pero no es ley. Si cambia tu flujo, dilo en la primera frase.
sed por rango sin verificar lo de alrededor
Qué pasó: para borrar un keyframe CSS muerto, Claude usó sed '281,291d'. Las líneas se habían desplazado entre la inspección y el borrado. El rango se cargó también dos keyframes que sí estaban en uso. El hero quedó con opacity cero permanente. Te has cargado todo el diseño.
El coste: catástrofe silenciosa. La página cargaba en blanco y no daba error.
Prohibido borrar por número de línea sin ver el contenido inmediato antes y después. grep primero. Confirma todas las apariciones. Borra por contenido único, no por rango ciego.
Subagentes copiando patrón de la página anterior
Qué pasó: al rediseñar la página «tech», los subagentes volvieron a meter el fake terminal y las pills flotantes que ya estaban en la home. Patrón visual repetido. Eso ya está en otra página, no se repite.
El coste: rediseño descartado y rehecho.
En el spec, lista explícita de patrones prohibidos por página. Si un bloque visual ya vive en otra página, dilo. Los subagentes copian lo que ven en su contexto inmediato, no lo que tú tienes en la cabeza.
Copy inventado metido como si fuera mío
Qué pasó: el bloque «Sistema» de la home apareció con copy que yo no había validado. Los subagentes lo metieron desde el spec, pero el spec tenía drafts no aprobados que se colaron. Eso no es mío, lo has inventado.
El coste: bloque rehecho de cero.
En el spec, marca claramente qué copy es aprobado y qué es placeholder. Si Claude no ve la diferencia, mete placeholder en producción. La regla: solo lo aprobado va al plan. Todo lo demás, fuera.
Hero enorme por clamp mal calculado
Qué pasó: patrón recurrente. Cada vez que Claude pone clamp() en el H1, el valor superior queda demasiado alto. El hero llega a ochenta píxeles en desktop. El hero está enorme.
El coste: tres iteraciones en cada página.
Regla en el spec: H1 nunca por encima de cuarenta y cuatro píxeles en desktop. Usa clamp(1.9rem, 4vw, 2.8rem) como techo, no como punto de partida. Y revisa el render en visual companion antes de aprobar.
Cifra anual incoherente con el ancla de la frase
Qué pasó: la calculadora de rentabilidad mostraba ahorro × 12 en la cifra anual, pero la frase ancla decía «te cuesta seguir a mano». Lo coherente con esa frase es coste humano × 12. Marketing engañoso disfrazado de demo.
El coste: bug honesto pillado en QA. Si no, sale en producción.
En el spec, especifica la fórmula en lenguaje natural, no solo en código. Que el placeholder visible al cargar coincida con lo que el JS calcula. Si no coincide, alguien lo va a creer y va a tomar una mala decisión.
El reviewer no detecta que el implementer borró por exceso
Qué pasó: en la sesión de poda del manifiesto y tech, el implementer borró bloques que sí estaban en uso. El reviewer aprobó porque el spec decía «limpiar contenido redundante» y le sonaba bien. Pero faltaba el filtro de qué bloques sí pueden tocarse.
El coste: reaplicación manual de tres bloques.
Reglas anti-sobrepoda explícitas en el spec. Lista blanca de bloques que se pueden borrar. Lista negra de los que no se tocan. El reviewer chequea las dos listas antes de aprobar.
Memoria vieja persistiendo entre sesiones
Qué pasó: reglas de hace tres sesiones se aplicaban hoy aunque ya no tuvieran sentido. Claude Code guarda memoria persistente del proyecto y de la usuaria. Es útil, pero es un arma de doble filo cuando tu flujo cambia.
El coste: decisiones por defecto que ya no eran las mías.
Revisa la memoria persistente cada dos semanas. Borra lo que ya no aplica. Y al empezar una sesión nueva con un flujo distinto, dilo explícitamente en la primera frase, igual que en el error 01.
Mi checklist de cierre antes de commit
Diez puntos. Si alguno falla, no hago commit. Punto.
Esto no me lo invento al final. Lo aplico cada vez que cierro una tarea. Si cualquier punto falla, vuelvo atrás antes de tocar git.
El checklist de los diez puntos
- 1. Copy aprobado. No hay frases que yo no haya validado.
- 2. Sin TODOs. No queda ningún
// TODO,TBDoimplementar despuésen el código. - 3. Reviewer dijo APPROVED. No basta con que el implementer diga «hecho».
- 4. Hero no roto. Lo veo en visual companion. En desktop y en móvil.
- 5. CSS huérfano fuera. Clases definidas que no se usan, fuera. Variables CSS que ya no aplican, fuera.
- 6. Variables existen donde se referencian. Nada de
var(--xxx)apuntando a variables muertas. - 7. URLs internas funcionan. Cross-links, breadcrumbs, footer. Click manual a los nuevos.
- 8. JSON-LD valida. Probado en Rich Results Test.
- 9. Meta tags completas. Title, description, OG, canonical. Imagen OG existe en disco.
- 10. Commit message describe lo que hace, no lo que toca. «Renombrar voz-ia.html a agentes-de-voz-ia.html y actualizar canonicals» no «cambios en tech/».
Diez puntos. Treinta segundos cada uno. Cinco minutos de revisión antes de commit. Te ahorra cinco horas de rework al día siguiente.
Cuándo NO merece la pena usar Superpowers
El flujo completo es para tareas con peso. Para todo lo demás, es overkill.
Superpowers brilla cuando la tarea tiene peso: muchas decisiones, varios archivos, decisiones estéticas o de negocio, posibilidad de equivocarse en grande. Si no hay nada de eso, brainstorm + spec + plan es trámite que no aporta.
Cuándo lo uso al 100%
Cuándo lo salto
La trampa del «por si acaso»
Si aplicas brainstorming + spec + plan para todo, conviertes Superpowers en burocracia. Y la burocracia se odia. La regla: el flujo completo solo cuando una mala decisión cuesta más de una hora rehacer. Si la podes rehacer en cinco minutos, no hace falta.
Aprende a sentir el peso de la tarea. Es lo que más rápido te pone a producir bien.
Cómo arrancar sin morir el primer día
Plan de arranque de tres días para no quemarte y sacar algo real.
Si nunca has usado Claude Code y vas a meterte en serio, este es el plan. No es teoría. Es lo que le diría a alguien que arranca mañana.
Instalar y mover una pieza pequeña
Instala Claude Code. Instala el plugin Superpowers. Elige una tarea pequeña de tu proyecto: un cambio de copy, una variable CSS, un texto que cambiar. No empieces con el rediseño del logo.
El objetivo del día 1 no es resultado. Es entender cómo se siente la conversación: cómo te pregunta, cómo te enseña el plan, cómo lanza los subagentes, cómo te pide aprobación en los hard gates.
- Modelo: Sonnet
- Tiempo: 30-45 minutos
- Entrega: un commit con un cambio mínimo bien hecho
Un brainstorming con Opus
Coge una tarea con peso. Algo que has estado posponiendo porque no sabes cómo arrancar. Pídele a Opus que haga brainstorming contigo. Deja que te pregunte. Responde a lo que te pregunte sin atajos.
Vas a ver lo que cambia tener al modelo en modo «pregunto antes de decidir». Vas a notar el hard gate. Vas a aprobar un spec por escrito.
- Modelo: Opus para brainstorming, Sonnet para ejecutar después
- Tiempo: 1-2 horas
- Entrega: un spec aprobado y un plan inicial
Ejecutar el plan con subagentes
Lanza la skill subagent-driven development con el plan del día anterior. Mira cómo funciona el implementer + reviewer. Aprueba o rechaza. Aplica el checklist de cierre antes de commit.
Al final del día 3 tendrás un cambio real en producción hecho con el flujo entero. Y vas a entender por dentro qué es Superpowers. No por fuera.
- Modelo: Sonnet para subagentes, Haiku si tienes que leer logs largos
- Tiempo: 2-3 horas
- Entrega: cambio mergeado y desplegado
Qué NO hacer el primer día
No intentes rediseñar la home entera. No abras tres tareas en paralelo. No mezcles Claude Code con otras herramientas hasta que el flujo te sea natural.
Una tarea. Un flujo. Un commit. El resto viene solo.
Las reglas reales
La IA no escala sin ti. Y eso a mucha gente le rompe el cuento.
Lo digo claro: esto no escala sin ti. Lo más fuerte de Superpowers no es que la IA haga más. Es que te obliga a estar presente en las decisiones que importan.
Si no estás, el resultado es malo. Brainstorming exige tu cabeza en cada decisión. Si delegas el spec, el spec sale mediocre. Si delegas la revisión, los reviewers aprueban cosas raras.
La IA no te ahorra pensar. Te ahorra el teclado. Y cuando piensas con disciplina, el resultado es alto. Cuando piensas con prisa, el resultado es bajo. La IA solo amplifica la calidad de tu pensamiento.
No es automático. Si la conversación contigo es mala, el resultado es malo. Superpowers ayuda a estructurar la conversación, no a sustituirla.
Las herramientas no salvan a un equipo sin método. Si tu proceso es desordenado, la IA va a producir desorden más rápido. Si tu proceso es claro, la IA produce calidad más rápido.
El cuento de los cinco minutos sigue existiendo. Esta semana en redes lo verás otra vez. «Mira qué fácil». Tú ya sabes lo que hay debajo: diez días, treinta y cinco commits, cincuenta subagentes y un checklist de diez puntos antes de cada commit. Desde las trincheras.