OpenSpec vs Superpowers: comparación de la generación de specs y la implementación

TL;DR

• OpenSpec (Fission AI, MIT, CLI de npm @fission-ai/openspec) es un sistema de artefactos de specs: specs vivas, carpetas por cambio, specs delta y flujos /opsx:* respaldados por una CLI que las skills consultan para obtener el estado estructurado.
• Superpowers (Jesse Vincent / Prime Radiant, MIT, plugin) es una capa que aplica una metodología: skills que se activan automáticamente y definen cómo el agente explora ideas, planifica, implementa (TDD), revisa y finaliza ramas, sin imponer una estructura de specs en el repo.
• Resuelven distintos modos de fallo. OpenSpec evita que los requisitos se pierdan en el chat: los convierte en specs duraderas que se pueden fusionar. Superpowers evita que los agentes omitan el diseño, las pruebas, las revisiones y las buenas prácticas de worktrees.
• Generación de specs: OpenSpec produce artefactos estructurados (proposal.md, spec.md delta, design.md, tasks.md) en openspec/changes/. Superpowers produce secciones de diseño conversacional y un plan de microtareas mediante las skills brainstorming y writing-plans, no un árbol formal de specs, a menos que tú lo agregues.
• Implementación: /opsx:apply de OpenSpec recorre tasks.md y actualiza las casillas. Superpowers utiliza subagent-driven-development o executing-plans, aplica TDD RED/GREEN y ejecuta una revisión en dos etapas: cumplimiento de la spec y luego calidad del código.
• Se pueden combinar. OpenSpec se encarga de qué construir y de la trazabilidad; Superpowers, de cómo ejecuta el agente el trabajo con disciplina. Por defecto, ninguno reemplaza al otro.

Qué aprenderás aquí

• Qué optimiza cada herramienta, OpenSpec y Superpowers, y por qué no son sustitutos directos
• Una comparación función por función de flujos integrados, artefactos e interfaces para agentes
• En qué difiere la generación de specs: specs delta estructuradas frente a diseño conversacional + planes
• En qué difiere la implementación: aplicación guiada por tareas frente a pipelines de TDD + subagentes/revisión
• Consideraciones de plataforma, especialmente las limitaciones de Cursor para los subagentes de Superpowers
• Una tabla de decisión para elegir uno, el otro o ambos
• Un ejemplo concreto que lleva la misma funcionalidad por cada conjunto de herramientas
• Cómo usar el selector Spec workflow picker de la barra lateral para navegar entre todas las comparaciones de estas tres herramientas en este sitio

El July 14, 2026, revisé la documentación vigente de OpenSpec (opsx.md, workflows.md, commands.md, README), los metadatos de npm para @fission-ai/openspec@1.6.0, el README de Superpowers y la versión v6.1.1 (July 2, 2026), los archivos de skills de Superpowers (writing-plans, executing-plans, subagent-driven-development), las notas de versión y el anuncio original de Superpowers de Jesse Vincent. Las conclusiones comparativas sobre su adecuación a los equipos y la combinación de las herramientas son inferencias editoriales, salvo que estén vinculadas a una fuente primaria.

Por qué estas dos herramientas aparecen juntas

Ambos proyectos entraron en la misma conversación durante el mismo periodo (finales de 2025 – mediados de 2026) como respuesta al mismo problema principal: los asistentes de programación con IA avanzan rápido, pero el proceso se desmorona cuando todo vive en el chat.

Difieren en la solución:

OpenSpec se compara con Spec Kit y Kiro en su README. Superpowers se compara con la programación ad hoc mediante agentes en su README y en la publicación de lanzamiento. Son capas adyacentes, no la misma categoría de producto; por eso resulta útil compararlas lado a lado.

                    ┌─────────────────────────────────────┐
                    │         Your coding agent           │
                    └─────────────────┬───────────────────┘
                                      │
              ┌───────────────────────┴───────────────────────┐
              │                                               │
              ▼                                               ▼
   ┌──────────────────────┐                    ┌──────────────────────┐
   │      Superpowers     │                    │       OpenSpec       │
   │  HOW the agent works │                    │  WHAT you're building │
   │  TDD, reviews,       │                    │  specs, deltas,       │
   │  worktrees, subagents│                    │  archive, sync        │
   └──────────────────────┘                    └──────────────────────┘
              │                                               │
              └───────────────────────┬───────────────────────┘
                                      ▼
                           Application code + tests

Configuración lado a lado

OpenSpec

npm install -g @fission-ai/openspec@latest
cd your-repo
openspec init
# optional: openspec init --tools cursor,claude
# optional: openspec config profile && openspec update   # expanded workflows

Después de la inicialización, OpenSpec crea openspec/specs/, openspec/changes/, el archivo opcional openspec/config.yaml y skills/comandos específicos del harness (por ejemplo, .cursor/skills/openspec-propose/SKILL.md y .cursor/commands/opsx-propose.md).

Superpowers

En el chat de Cursor Agent:

/add-plugin superpowers

También puedes instalarlo desde el marketplace de plugins en Claude Code, Codex, Factory Droid, Copilot CLI, OpenCode, Pi, Kimi Code y otros. No hay un paso de inicialización del repo: el plugin inyecta la inicialización using-superpowers al comenzar la sesión.

OpenSpec entry points                 Superpowers entry points
─────────────────────                 ────────────────────────
Terminal: openspec init               Plugin: /add-plugin superpowers
Terminal: openspec list|validate      Automatic: skills trigger on context
AI chat:  /opsx:propose               Implicit: "help me build X" → brainstorming
AI chat:  /opsx:apply                 Implicit: approved design → writing-plans → implement

Funciones integradas: comparación lado a lado

Flujo principal (respaldado por fuentes)

Interfaz para agentes

Las skills de OpenSpec no son prompts decorativos. Consultan la CLI para obtener el estado estructurado antes de escribir un artefacto a la vez:

User: /opsx:continue
  │
  ├─► openspec status --change add-dark-mode --json
  ├─► openspec instructions specs --change add-dark-mode --json
  ├─► read dependency artifacts (proposal.md, …)
  └─► write ONE artifact (e.g. delta spec)

Superpowers invierte ese modelo: el agente busca skills aplicables antes de cada tarea, y las skills codifican comportamientos obligatorios (TDD, controles de revisión, configuración de worktrees).

Grafo de artefactos predeterminado (esquema spec-driven de OpenSpec)

El esquema predeterminado de OpenSpec produce cuatro tipos de artefactos vinculados:

proposal ──→ specs ──→ design ──→ tasks ──→ /opsx:apply

Las specs delta usan secciones ADDED / MODIFIED / REMOVED para que los cambios en proyectos existentes sigan siendo auditables. Al archivar, los deltas se fusionan en openspec/specs/<capability>/spec.md.

La cadena predeterminada de Superpowers (según el README):

brainstorming ──→ using-git-worktrees ──→ writing-plans
       │
       └──► subagent-driven-development | executing-plans
                    │
                    ├── test-driven-development (during each task)
                    ├── requesting-code-review (between tasks)
                    └── finishing-a-development-branch

El plan de Superpowers enfatiza tareas de 2–5 minutos con rutas de archivo exactas, pasos de verificación y suficiente detalle para que un «ingeniero junior con mal gusto» pueda ejecutarlo: una granularidad distinta a la de tasks.md de OpenSpec, que registra elementos de una lista de implementación vinculados a las specs.

Generación de specs: dónde difieren realmente

Este es el centro de la comparación para arquitectos.

OpenSpec: specs como artefactos duraderos del repo

OpenSpec trata las especificaciones como archivos de primera clase y versionados:

• Las specs principales describen el comportamiento actual del sistema (openspec/specs/).
• Las carpetas de cambios contienen la propuesta, las specs delta, el diseño y las tareas (openspec/changes/<name>/).
• El archivo mueve los cambios completados a openspec/changes/archive/ y, de forma opcional, sincroniza los deltas con las specs principales.
• La configuración del proyecto (openspec/config.yaml) inyecta el contexto del stack y reglas por artefacto (por ejemplo, escenarios Given/When/Then).

Ventajas (respaldadas por fuentes + inferencia):

Desventajas (inferencia):

• Requiere inicialización, convenciones y ejecutar openspec update ocasionalmente después de las actualizaciones.
• La calidad de las specs sigue dependiendo del modelo + las plantillas: OpenSpec permite editar las plantillas, pero alguien tiene que mantenerlas.

Superpowers: specs como conversación negociada → plan

Superpowers genera specs mediante skills, no con un esquema de directorios fijo:

1. brainstorming — Refina la intención mediante preguntas y presenta el diseño en secciones cortas para que una persona lo apruebe.
2. writing-plans — Convierte el diseño aprobado en un plan de implementación granular (ruta de guardado predeterminada: docs/superpowers/plans/).

A partir de Superpowers v6.x, brainstorming y writing-plans usan listas de autoverificación integradas durante la creación de la spec o el plan, en lugar de ciclos de revisión con subagentes: es más rápido, pero sigue sin ser un modelo de specs delta que se puedan fusionar.

No hay una función integrada para fusionar specs delta, un árbol de specs orientado a capacidades ni un equivalente de /opsx:sync. El plan se convierte en el contrato de implementación para esa sesión/rama.

Ventajas (respaldadas por fuentes + inferencia):

Desventajas (inferencia):

• Los requisitos son menos duraderos entre sesiones, a menos que hagas commit manualmente de los archivos de diseño/plan.
• Es más difícil que varios equipos usen las specs como «fuente de verdad» sin agregar OpenSpec o algo similar.
• El comportamiento de las skills varía según el harness (consulta las notas de plataforma más abajo).

Tabla comparativa de generación de specs

Implementación: de dónde viene la disciplina

OpenSpec /opsx:apply

Según la documentación de comandos de OpenSpec, /opsx:apply:

• Lee tasks.md e identifica los elementos incompletos.
• Implementa las tareas una por una: código, archivos y pruebas según sea necesario.
• Marca las tareas completadas.
• Puede actualizar los artefactos cuando la implementación revela vacíos en la spec (flujo fluido).

OpenSpec no exige de forma centralizada TDD, asignación de subagentes ni revisión en dos etapas. Eso depende de las reglas de tu agente, el modelo y cualquier plugin que cubra esas funciones.

Stack de implementación de Superpowers

Superpowers trata la implementación como un pipeline con puntos de control:

El README afirma que puede ejecutar procesos autónomos de varias horas que se mantienen fieles al plan. Es una afirmación del autor, no un benchmark. Tómala como una intención de diseño, no como un SLA.

Consideración de plataforma: soporte de subagentes en el harness

Superpowers trata la orquestación de subagentes como una capacidad del harness, no como algo que todas las instalaciones del plugin obtienen por igual.

Según las notas de versión de Superpowers v6.x y la skill executing-plans (July 2026):

• Harnesses con capacidad para subagentes (enumerados explícitamente): Claude Code, Codex CLI, Codex App, Copilot CLI.
• subagent-driven-development es obligatorio en esos harnesses después de aprobar el plan.
• executing-plans está reservado para harnesses sin capacidad para subagentes e indica al usuario que Superpowers funciona mejor en plataformas que sí la tienen.

Cursor es compatible como plugin, pero no figura entre los harnesses de Superpowers con capacidad para subagentes en la versión v6.1.1. En Cursor, espera executing-plans (ejecución de tareas en línea con puntos de control) en lugar del ciclo completo de asignación de subagentes, a menos que Superpowers agregue posteriormente Cursor a su lista de plataformas con capacidad para subagentes.

El /opsx:apply de OpenSpec es independiente del harness: consiste en instrucciones y archivos de tareas, no en infraestructura de subagentes.

Extensibilidad y personalización

OpenSpec

• openspec/config.yaml — contexto del proyecto + reglas por artefacto.
• schema.yaml + plantillas — grafos de artefactos personalizados (existe un catálogo de esquemas de la comunidad).
• Perfiles de flujo — core (propose/explore/apply/sync/archive) frente al ampliado (new/continue/ff/verify/bulk-archive/onboard).
• Stores (beta) — repos independientes de planificación compartidos entre repos de código.

La documentación de OPSX de OpenSpec plantea explícitamente la personalización como la edición de plantillas/esquemas sin esperar a nuevas versiones del paquete.

Superpowers

• Biblioteca de skills — 14 skills documentadas que cubren pruebas, depuración, colaboración y meta.
• writing-skills — meta-skill para crear y probar bajo presión nuevas skills.
• Actualizaciones del plugin — a menudo automáticas según el harness.
• Política de contribución — el README indica que, en general, no aceptan nuevas skills en el proyecto original; los cambios deben funcionar en todos los agentes compatibles.

Superpowers optimiza la consistencia del comportamiento. OpenSpec optimiza la flexibilidad de los artefactos.

Cuándo usar cada uno

Criterio editorial: Si debes elegir uno, elige OpenSpec cuando la trazabilidad de las specs y los deltas en proyectos existentes sean el cuello de botella; elige Superpowers cuando lo sea la disciplina del agente (TDD, revisiones, worktrees).

La misma funcionalidad, dos rutas

Funcionalidad: Agregar reproducción de un resumen de audio de artículos a un devlog de Astro.

Ruta A — OpenSpec

/opsx:explore          → clarify delivery (inline player vs modal), scope caps
/opsx:propose article-audio-summary-pipeline
                       → proposal.md, delta specs (ui, generation, delivery),
                         design.md, tasks.md
/opsx:apply            → implement tasks; check off items
/opsx:archive          → sync deltas into openspec/specs/; archive change

Los artefactos permanecen legibles para el siguiente ingeniero, incluidos los requisitos que el agente ya no tiene que volver a deducir del chat.

Ruta B — Superpowers

"Help me add audio summaries to articles"
  → brainstorming: questions on UX, storage, generation API
  → design sections approved
  → using-git-worktrees: feat/article-audio branch
  → writing-plans: 2–5 min tasks with file paths + verification
  → executing-plans or subagent-driven-development
  → test-driven-development on each task
  → finishing-a-development-branch: PR or merge

Obtienes buenas prácticas sólidas de implementación. Los requisitos duraderos quedan donde las skills los hayan escrito, a menos que adoptes OpenSpec (o algo similar) para la capa de specs.

Ruta C — Combinada (inferencia)

OpenSpec: /opsx:propose + delta specs     ← WHAT + traceability
Superpowers: TDD + review skills         ← HOW with discipline

Este no es un producto integrado oficial: es un stack práctico que muchos equipos pueden armar manualmente.

Riesgos de combinarlos (inferencia): Ambas herramientas inyectan skills y reglas de comportamiento. Sin coordinación, puedes terminar con fases de planificación duplicadas (OpenSpec /opsx:propose más Superpowers brainstorming) o instrucciones de git/worktree contradictorias. Un patrón práctico: usa OpenSpec para crear artefactos y luego deja que las skills de Superpowers se encarguen únicamente de las buenas prácticas de implementación.

Resumen de ventajas

Fuentes

Fuentes primarias consultadas el July 14, 2026:

• README de OpenSpec — filosofía, inicio rápido, comparaciones, licencia MIT
• Flujo OPSX de OpenSpec — acciones fluidas, artefactos, configuración, esquemas
• Flujos de OpenSpec — perfiles principal y ampliado
• Comandos de OpenSpec — comportamiento de /opsx:*, incluidos apply y archive
• npm @fission-ai/openspec — versión 1.6.0 al momento de escribir el artículo
• README de Superpowers — biblioteca de skills, flujo, instalación, versión v6.1.1
• RELEASE-NOTES de Superpowers — comportamiento de subagentes según el harness en v6.x, soporte del plugin para Cursor
• Skill writing-plans de Superpowers — formato del plan, ruta de guardado predeterminada, transferencia a la ejecución
• Skill executing-plans de Superpowers — lista de plataformas con capacidad para subagentes
• Skill subagent-driven-development de Superpowers — modelo de revisión en dos etapas
• Publicación de lanzamiento de Superpowers — origen del flujo explorar ideas → planificar → implementar, justificación de las skills (October 9, 2025)
• Herramientas compatibles con OpenSpec — IDs de herramientas y nombres de skills generadas

Lecturas relacionadas en este devlog:

• OpenSpec vs GitHub Spec Kit — compara dos frameworks de artefactos de specs (usa el Spec workflow picker en la barra lateral del artículo)
• OpenSpec avanzado: flujos ampliados — /opsx:verify, esquemas personalizados, perfiles
• Reemplaza Plan Mode con OpenSpec — cuándo las specs estructuradas superan el modo de planificación del IDE