Superpowers: el framework de skills que todos miran

Cada pocos meses aparece un framework de coding con IA que capta la atención del gremio. Este año le tocó a Superpowers, el proyecto de Jesse Vincent que lleva meses en la parte alta de GitHub trending y que hoy ronda las 164 mil estrellas. No es un record cualquiera: para un repo cuyo lenguaje principal es Shell y cuyo deliverable son archivos markdown, el número dice algo sobre dónde está el interés del ecosistema.

La promesa, en una línea, es volver portable y reusable la forma en que un agente escribe código. En vez de un prompt gigante, tienes un directorio de skills — cada skill es un markdown con instrucciones que el agente carga según la tarea. No inventa la rueda, pero la empaqueta de una manera que mucha gente estaba esperando.

Nos clavamos a leerlo para decidir si entra al stack de plantillas que usamos en proyectos de cliente. Este post es lo que encontramos.

· obra/superpowers · MIT · Jesse Vincent

Qué hace realmente

Superpowers resuelve un problema concreto que cualquiera que lleve seis meses usando Claude Code, Cursor o Codex CLI conoce de memoria: los agentes son inconsistentes entre tareas. En una sesión hacen TDD impecable, en la siguiente meten un parche encima de un parche. En una repo respetan la arquitectura, en otra la atropellan. El contexto se pierde, el estilo se pierde, la disciplina se pierde.

La propuesta es sacar esa disciplina fuera del prompt y convertirla en archivos. Un skill es un markdown corto, con un título, un trigger (“cuándo se activa esto”) y un conjunto de reglas. El agente lee el skill antes de trabajar y lo aplica. Si mañana cambias de modelo, el skill viaja contigo. Si mañana entra alguien nuevo al equipo, lee el skill y sabe cómo opera el agente.

No es magia ni abstracción heavy. Es convertir conocimiento tácito en texto versionable.

Cómo funciona por dentro

La instalación es de una sola línea y no pide nada raro:

npx superpowers install --claude --local

El comando deja un directorio .superpowers/skills/ con un catálogo base. A partir de ahí, el workflow canónico es de siete pasos, pero lo interesante es la lógica detrás:

1. Brainstorming socrático antes de tocar código. El agente pregunta en vez de asumir.
2. Un git worktree por tarea. Cada branch vive en su propio folder, sin cruces.
3. Un plan escrito con paths exactos y subtareas de dos a cinco minutos.
4. Subagentes frescos por subtarea. Contexto limpio, sin arrastrar el ruido anterior.
5. TDD obligatorio: primero el test que falla, luego el código mínimo, luego el refactor.
6. Code review automática entre tareas. Los hallazgos críticos bloquean el avance.
7. Cierre de branch: valida tests, ofrece merge o PR.

Un skill tipo, escrito a mano, se ve así de simple:

---
name: using-tdd
trigger: al empezar cualquier tarea de implementación
---

# TDD estricto

1. Escribe el test primero. Debe fallar por la razón correcta.
2. Corre la suite completa y confirma el rojo.
3. Implementa lo mínimo para pasar. Nada más.
4. Corre otra vez. Todo verde.
5. Refactoriza sin tocar el comportamiento observable.
6. Commit con mensaje "test: <qué> / feat: <qué>".

Si el test pasa al primer intento sin haber fallado, está mal escrito.

Ese markdown, sin código, sin framework detrás, es toda la pieza. Los “skills” son puros archivos. El mérito del proyecto está en haber definido la convención, el loader y un catálogo inicial suficientemente útil para que arranques sin escribir nada.

Pros

• Curva de entrada muy baja: si sabes escribir un README, sabes escribir un skill.
• Portabilidad real entre runtimes. Claude Code, Codex CLI, Cursor, OpenCode y Copilot CLI consumen el mismo directorio.
• TDD no es un opcional, viene metido en el workflow base. Eso solo ya justifica mirarlo.
• Los worktrees por tarea eliminan una clase entera de bugs de contexto cruzado entre branches.
• El skill writing-skills te permite escribir nuevos skills con ayuda del propio agente, lo que hace que el framework crezca contigo.
• Licencia MIT, código en shell puro, cero dependencias exóticas. Lo puedes auditar en una tarde.

Contras

• No hay concepto de fases, roadmap ni gestión de proyecto. Si necesitas eso, vas a terminar combinándolo con otra herramienta.
• La governance es light. Sirve para equipos pequeños o trabajo individual; en una organización con veinte desarrolladores vas a querer reglas adicionales.
• El repo de skills comunitarios (superpowers-skills) está archivado desde octubre de 2025. El catálogo vive, pero la colaboración abierta se frenó.
• El workflow asume disciplina del usuario. Si alguien decide saltarse los pasos, el framework no lo detiene; solo documenta cómo debería ser.
• Depende fuertemente de git worktrees, lo cual es genial salvo cuando tu proyecto tiene submódulos complicados o hooks pesados por branch.

Cuándo sí, cuándo no

Sí te conviene si trabajas solo o en equipos de menos de diez personas, si ya haces TDD o quieres empezar, y si cambias de runtime de IA seguido. También si necesitas una base limpia sobre la cual construir tus propias convenciones — Superpowers es buen punto de partida precisamente porque no te mete mucho encima.

No te conviene si necesitas gestión de roadmap, aprobaciones multi-stage o integraciones con Jira y compañía. Tampoco si tu equipo no acepta el worktree-por-tarea como estándar: el framework pierde la mitad de su valor sin eso. Y si tu caso es “quiero que el agente arregle este bug y se vaya”, montar Superpowers es sobreingeniería.

Una comparación honesta: contra Claude Code sin framework, la diferencia no es que el agente sea más inteligente. Es que repite menos los mismos errores. Después de dos semanas con skills decentes, el tiempo que antes gastabas en recordarle al agente tus reglas se va a cero. Esa es la ganancia real.

Veredicto

Lo adoptamos como base para proyectos nuevos donde tenemos control del stack, sobre todo los que arrancan de cero y donde vamos a establecer convenciones desde el día uno. No lo imponemos en código legacy: meter worktrees y TDD estricto sobre una base que no los tiene es una pelea que no vale.

Para proyectos de cliente lo usamos con un caveat — extendemos el catálogo con skills propios que cubren nuestras reglas de estilo, patrones de error y protocolos de deploy. Lo que viene de fábrica es un 60% del camino; el otro 40% lo escribes tú, y ahí es donde el framework devuelve la inversión.

No es la bala de plata. Es una convención bien diseñada para un problema que la comunidad ya reconocía. Por 164 mil estrellas y cero costo de adopción, la pregunta honesta no es si usarlo; es por qué no lo estás usando todavía.

TL;DR — Superpowers no te da un agente mejor, te da un agente consistente; es la diferencia entre contratar talento senior y contratar talento senior que además lee el handbook.