OpenSpec: la capa de especificaciones ligera que obliga a acordar qué construir antes de escribir código
Fission-AI/OpenSpec · 70.314★ · 4.813 forks
OpenSpec es una capa de especificaciones ligera que obliga al desarrollador y a su asistente de código a acordar, por escrito, qué se va a construir antes de escribir una sola línea de código. Es la principal alternativa «ligera» al enfoque spec-driven dentro de un ecosistema de herramientas que creció rápidamente a partir de 2025.
Nota de desambiguación: el repositorio se llama OpenSpec (con mayúscula) en GitHub; la fila de la cola usa
openspec. Existe al menos un proyecto no relacionado con el mismo nombre (un explorador OpenAPI/Swagger enopenspec.vercel.app), pero el repositorio documentado aquí esFission-AI/OpenSpec.

Qué es OpenSpec
OpenSpec es un framework de desarrollo guiado por especificaciones (SDD, por sus siglas en inglés) para asistentes de programación con IA. No es un modelo, un IDE ni un servidor: es un CLI de Node.js que genera archivos Markdown dentro del propio proyecto, más un conjunto de habilidades y comandos a cuchara (/opsx:*) que el asistente de IA ejecuta en el chat.
Su propósito es mover el acuerdo sobre los requisitos fuera del historial de chat. Cuando los requisitos viven solo en una conversación, el asistente llena los vacíos con suposiciones y el error se descubre después de que el código ya existe. OpenSpec introduce un contrato verificable: cada cambio se planifica en una carpeta con propuesta, especificaciones delta, diseño y lista de tareas; el humano revisa el plan antes de que se implemente nada, y al archivar el cambio, las especificaciones se convierten en la descripción del comportamiento actual del sistema.
El propio README resume la filosofía en cinco líneas: fluido, no rígido; iterativo, no en cascada; fácil, no complejo; pensado para brownfield, no solo para proyectos nuevos; y escalable de proyectos personales a empresas.
El origen
El repositorio fue creado el 5 de agosto de 2025 por la organización Fission-AI en GitHub. Los mantenedores declarados en MAINTAINERS.md son Tabish Bidiwale (TabishB), mantenedor principal, y Clay Good (clay-good), mantenedor, con Hari Krishnan (harikrishnan83) como asesor técnico. El sitio oficial, openspec.dev, lleva la marca «© 2026 Fission», lo que indica que el proyecto está respaldado por la empresa Fission.
El color narrativo que ofrecen las fuentes consultadas es modesto: no hay un post de lanzamiento viral con anécdota, a diferencia de otras herramientas del mismo nicho. La trayectoria documentada es la de un proyecto que maduró de forma constante: nació como experimental en agosto de 2025, pasó a estable con v1.0.0 el 26 de enero de 2026 (un rediseño completo del flujo alrededor de un sistema de acciones basado en artefactos, con cambios rompedores), y desde entonces ha lanzado versiones casi semanales. El autor principal del proyecto, Tabish Bidiwale, publicó un vídeo de lanzamiento y mantiene el perfil @0xTab en X, que el README enlaza para novedades.
Filosofía y principios
El README y la documentación declaran los siguientes principios, verificables en el propio código del flujo: acordar antes de construir (el asistente y el humano se alinean sobre las especificaciones antes de escribir código; el error es barato en el plan, caro en la implementación); fluido, no en fases rígidas (cualquier artefacto —propuesta, specs, diseño, tareas— puede editarse en cualquier momento; no hay puertas de fase que bloqueen el avance); markdown plano, sin sintaxis especial (las especificaciones son requisitos con escenarios SHALL/MUST + GIVEN/WHEN/THEN, legibles por humanos y verificables por el CLI); y neutralidad de herramienta (funciona con más de 30 asistentes de IA instalando el formato de habilidades o comandos que cada uno usa, en vez de obligar a un solo entorno).

Brownfield-first: no se documenta la aplicación completa de antemano; se escribe una especificación solo para lo que cada cambio toca, y las specs crecen con el trabajo real.

Un concepto central es la especificación delta: cada cambio declara solo lo que modifica (secciones ADDED, MODIFIED, REMOVED) en vez de reescribir toda la spec, y al archivar, esas deltas se fusionan en la spec principal. El cambio archivado queda en openspec/changes/archive/ como historia auditable.

Cómo funciona
El flujo básico documentado (perfil core, por defecto):
/opsx:explore ──► /opsx:propose ──► /opsx:apply ──► /opsx:sync ──► /opsx:archive
(opcional)
/opsx:explore(opcional): un «compañero de reflexión» sin compromiso que lee la base de código, sopesa opciones y convierte una idea borrosa en un plan concreto, sin crear todavía ningún artefacto./opsx:propose <nombre>: creaopenspec/changes/<nombre>/conproposal.md(el porqué y el alcance),specs/(deltas con requisitos y escenarios),design.md(el cómo técnico) ytasks.md(checklist de implementación). El humano revisa el plan./opsx:apply: el agente implementa las tareas; si el diseño necesita ajustes, los artefactos se editan y se continúa./opsx:sync(opcional): fusiona las deltas en las specs principales antes de archivar, útil en cambios largos./opsx:archive: aplica las deltas a la spec principal y mueve el cambio achanges/archive/AAAA-MM-DD-<nombre>/.

Hay un perfil expandido (new, continue, ff, verify, bulk-archive, onboard) que se activa con openspec config profile. El CLI de terminal complementa el chat con openspec list, openspec show <change> [--diff], openspec validate [--report findings], openspec status --all, openspec view (panel interactivo) y openspec feedback.
Además, desde la beta, OpenSpec ofrece Stores: un repositorio independiente dedicado solo a planificación, con la misma forma openspec/ (specs y changes) que se comparte con git push como cualquier otro repo. Resuelve el caso de un equipo donde una función toca tres repositorios, o donde un equipo de plataforma posee los requisitos y los equipos de producto los consumen de solo lectura. openspec store setup <nombre> y openspec new change <id> --store <nombre> son los comandos de arranque.

El ecosistema
Repositorios de la organización Fission-AI
Fission-AI/OpenSpec: el proyecto principal (este informe). Fission-AI/PR-QUEST: una forma más interactiva de revisar solicitudes de cambios; 25 estrellas (16 de octubre de 2025).
El producto comercial asociado, documentado en el blog oficial, es el OpenSpec Cloud Agent (acceso anticipado el 28 de agosto de 2026): una capa siempre activa que compara pull requests con los requisitos de los repositorios conectados, detecta «deriva» entre código y specs citando la línea exacta de ambos, y puede abrir PRs correctivos. Una actualización del 11 de septiembre de 2026 indica que las inscripciones nuevas del programa de acceso anticipado están pausadas mientras evalúan el producto con los equipos participantes.

Herramientas de la comunidad
UIs y visualizadores (catalogados en speclib/awesome-openspec, 73 estrellas): ToruAI/openspec-ui (kanban en tiempo real, 31 estrellas), oioi555/openspec-webui (interfaz web interactiva, 14 estrellas), jixoai/openspecui (interfaz web con modo en vivo y exportación estática, 113 estrellas), y otros como fselich/dossier, MusicAdam/openspec-viewer, sflueckiger/specboard, dansreis/speclens, spekhq/spek.
Integraciones y plugins de editores/agentes: Lumiaqian/openspec-mcp (servidor MCP con panel kanban), johnnyblabs/intellij-openspec (plugin de IntelliJ), Octane0411/opencode-plugin-openspec (160 estrellas, plugin de OpenCode con modo «architect»), fastknifes/openflow (180 estrellas, combina OpenSpec y Superpowers), y extensiones para Copilot, VS Code/Cursor, Zed, Emacs y Neovim.
Flujos híbridos y esquemas comunitarios: JiangWay/openspec-schemas (222 estrellas, incluye superpowers-bridge), intent-driven-dev/openspec-schemas (94 estrellas), MageByte-Zero/spec-superflow (798 estrellas, fusión con Superpowers), rihebty/flow-kit (400 estrellas), SYZ-Coder/superpowers-openspec-team-skills (193 estrellas), sudokar/openspec-plus (190 estrellas), wenqingyu/ralphy-openspec (182 estrellas).
Ingeniería inversa y guías: clay-good/OpenLore (304 estrellas, antes spec-gen, del propio mantenedor Clay Good, genera especificaciones a partir de código existente), ForceInjection/OpenSpec-practise (614 estrellas), sohaha/studyzy-OpenSpec-cn (96 estrellas), y más guías comunitarias en chino.

Estado oficial / semioficial
OpenSpec no es un componente de un marketplace de un gran vendor: es un paquete npm independiente (@fission-ai/openspec) bajo licencia MIT, mantenido por Fission-AI. Hay tres señales de estatus verificables: estable desde v1.0.0 (26 de enero de 2026, con la transición «de experimental a estable»); adopción de facto en el nicho SDD (los hilos de Hacker News muestran a OpenSpec nombrado junto con Spec Kit, Superpowers y Kiro en discusiones sobre desarrollo guiado por especificaciones); y producto comercial asociado (el OpenSpec Cloud Agent indica una intención de negocio más allá del OSS).
En la práctica, OpenSpec funciona como la opción ligera y multi-herramienta del estándar de facto «escribir specs antes que código», compitiendo de frente con github/spec-kit (oficial de GitHub) y Kiro (AWS), como el propio README compara.
Guía rápida de uso
Instalación y primer arranque
Prerrequisito: Node.js 20.19.0 o superior.
npm install -g @fission-ai/openspec@latest # también pnpm add -g / bun add -g / yarn global add
openspec --version # verificar
cd tu-proyecto
openspec init # interactivo: elige las herramientas de IA que usas
Opciones no interactivas: openspec init --tools claude,cursor, --tools all, --tools none, --profile core. Con Nix: nix run github:Fission-AI/OpenSpec -- init.
Al finalizar, openspec init crea la estructura openspec/ (con specs/, changes/ y config.yaml), escribe las habilidades y comandos para cada herramienta elegida, e imprime una línea «Getting started» con la ortografía exacta del comando para tu herramienta. Lo que esperar en el primer arranque: dos pasos de terminal y luego todo se hace en el chat del asistente. No existe un «modo interactivo» separado; el comando a cuchara es la entrada a OpenSpec.
Flujos de trabajo habituales
- Para proponer una función que ya tienes clara: en el chat del asistente, ejecuta
/opsx:propose add-dark-mode; se creaopenspec/changes/add-dark-mode/conproposal.md,specs/,design.mdytasks.md. Revisa el plan antes de continuar. - Para pensar una idea borrosa antes de comprometerte: ejecuta
/opsx:explore, explica el problema, y el agente explora el código, hace preguntas y propone un alcance; al terminar, transfiere a/opsx:propose. - Para implementar: ejecuta
/opsx:apply; el agente trabaja el checklist y marca cada tarea. Si te quedas sin contexto, abre una sesión nueva y vuelve a ejecutar/opsx:apply: lee los artefactos y reanuda desde la primera tarea sin marcar. - Para revisar y validar desde terminal:
openspec list(cambios activos),openspec show <cambio> --diff(solo las líneas que cambian),openspec validate <cambio>(valida el formato de las specs). Al terminar,/opsx:archivefusiona las deltas enopenspec/specs/y archiva el cambio.
Configuración esencial
openspec/config.yaml: la clavecontext:inyecta texto en cada solicitud de planificación; es el lugar para declarar tu stack tecnológico y convenciones.- Perfil de comandos (
openspec config profile):core(por defecto) o el perfil expandido (añadenew,continue,ff,verify,bulk-archive,onboard). - Idioma de artefactos:
openspec init --language <language>genera las specs en otro idioma (los encabezados y las palabrasSHALL/MUSTse mantienen en inglés). - Telemetría: encendida por defecto (solo nombres de comando y versión; desactivada automáticamente en CI). Opt-out:
openspec config set telemetry.enabled false. - Stores (beta):
openspec store setup <nombre>para planificación multi-repo.
Trampas frecuentes y soluciones
- Escribir
/opsx:proposeen la terminal: el error más común documentado. Los comandosopenspec ...corren en terminal; los comandos/opsx:...se escriben en el chat del asistente. - La sintaxis no coincide con tu herramienta:
/opsx:proposees/opsx-proposeen Cursor y GitHub Copilot,@opsx-proposeen Amazon Q,$openspec-proposeen Codex, y/skill:openspec-proposeen Kimi Code. Usa siempre la forma impresa poropenspec init. - Comando que no aparece: normalmente los archivos no están instalados.
openspec updatesolo refresca archivos existentes; si nunca corristeopenspec init, ejecútalo y reinicia el asistente. - Versión vieja en la PATH: tras actualizar el paquete, si
openspec --versionmuestra una versión anterior, hay una copia anterior enmascarando la nueva en la PATH. - Editar código a mano y desincronizar la spec: archivar convierte tus specs en el registro de la verdad; antes de archivar, reconcilia.
/opsx:verifyyopenspec show --diffayudan a ver las discrepancias. - Yarn 2+ no tiene
global: instala con npm, pnpm o bun en su lugar.
Integraciones y migración
La carpeta openspec/ se debe commitear como código fuente. Para CI: openspec validate --archived verifica que todos los cambios archivados tengan todas las tareas de tasks.md marcadas; openspec validate --report findings emite un informe solo de hallazgos para pipelines. openspec init --copilot-cloud genera archivos para que el agente de código de GitHub use el CLI. El servidor comunitario Lumiaqian/openspec-mcp expone el CLI como herramientas MCP. Para migrar desde versiones anteriores a 1.0, los comandos antiguos fueron eliminados; ejecuta openspec init para actualizar — los cambios activos, archivados y las specs se conservan.
Métricas actuales
Medición: 14 de septiembre de 2026, API de GitHub y registro npm.
| Métrica | Valor |
|---|---|
| Estrellas | 68.216 |
| Bifurcaciones | 4.689 |
| Incidencias abiertas indicadas por la API | 283 |
Commits (rama main, aproximado) | ≈843 |
| Lenguaje principal | TypeScript |
| Licencia | MIT |
| Creación | 5 de agosto de 2025 |
| Último push | 14 de septiembre de 2026 |
| Última publicación | v1.13.0, 9 de septiembre de 2026 |
| Descargas npm (semana) | 378.332 |
| Descargas npm (mes) | 1.768.196 |
Los principales contribuidores, por contribuciones: TabishB (518), clay-good (125), openspec-release-bot[bot] (23), github-actions[bot] (20) y dependabot[bot] (16). Caveats: open_issues_count puede incluir solicitudes de cambios abiertas; el conteo de commits es aproximado; y watchers_count de la respuesta de repositorio replica el campo de estrellas, por lo que no se reporta por separado.
Recepción de la comunidad
La evidencia recuperada muestra entusiasmo consistente pero también objeciones concretas y repetidas.
En el hilo 47419539 («Get Shit Done», 17 de marzo de 2026), recroad escribió: «I use openspec and love it. I’m doing 5-7x with close to 100% of code AI generated, and shipping to production multiple times a day. I work on a large sass app with hundreds of customers». gbrindisi añadió: «I like openspec, it lets you tune the workflow to your liking and doesn’t get in the way». En 46692578 («Ask HN: Do you have any evidence that agentic coding works?», 20 de enero de 2026), recroad volvió a citar OpenSpec: «Works pretty great for me… Easily 5x speed minimum». En 48774782 («Superpowers 6», 3 de julio de 2026), wejick escribió: «SDD with openspec hit the right balance for me».
La crítica más articulada aparece en el gran hilo 47994012 («Specsmaxxing», 287 puntos y 295 comentarios, 3 de mayo de 2026). jochem9, que lo usaba «desde hace unos meses», advirtió que «cuando una spec cambia, la IA necesita encontrar el código relevante para cambiarlo… en una base de código grande es muy fácil perder algo». alasano fue más duro: «disfruto el formato de OpenSpec, pero creo que mantener las specs principales no vale la pena. He dejado de hacerlo por completo… Cuando haces el proceso de sync, sigue desviándose hasta que tienes duplicación y contradicciones entre specs». gnatolf, en 47019109 («Breaking the spell of vibe coding», 14 de febrero de 2026), formuló la objeción de escala: «En cuanto el proyecto crece a un tamaño relevante de complejidad, mantener las specs es tan difícil como el problema que resuelve».
El desarrollador Dan Clarke publicó una review el 8 de mayo de 2026 tras un mes de uso: lo eligió porque Spec Kit le resultó «un poco pesado», resalta el modo explore como característica clave, pero matiza que en su experiencia «no es realmente spec-driven… las specs son un artefacto del flujo, no el punto de partida».
Comparación con proyectos similares
| Propuesta | Coincidencia verificable | Diferencia verificable |
|---|---|---|
github/spec-kit (136.644 estrellas, Python) | Kit oficial de GitHub para SDD con CLI, plantillas e integraciones. | El README de OpenSpec lo describe como «exhaustivo pero pesado: puertas de fase rígidas, mucho Markdown, configuración en Python». |
| Kiro (AWS) | IDE agéntico de AWS que convierte lenguaje natural en specs estructuradas. | El README: «poderoso pero quedas atado a su IDE y limitado a modelos Claude»; OpenSpec funciona con las 30+ herramientas existentes. |
obra/superpowers | Disciplina de proceso para agentes de código, con habilidades compuestas. | Superpowers impone la metodología de ejecución (TDD, revisión, worktrees); OpenSpec gobierna el acuerdo previo sobre requisitos. La comunidad los combina vía schemas. |
bmad-code-org/BMAD-METHOD | Metodología ágil guiada por IA que usa specs formales como fuente única de verdad. | Enfoque de equipo con roles y artefactos formales; OpenSpec es más ligero y personalizable vía schemas. |
La comparación más útil no es por popularidad: Spec Kit es el proyecto con más estrellas del nicho (136k frente a 68k de OpenSpec), pero el README y los comentarios de la comunidad posicionan a OpenSpec como la opción cuando se quiere ligereza, libertad de iteración y portabilidad entre asistentes, en vez de un kit prescriptivo.
Cómo contribuir
CONTRIBUTING.md documenta un proceso de cuatro pasos, notable por aplicar el propio flujo del proyecto a sí mismo: abrir una discusión o un issue primero (todo cambio empieza ahí; «PRs sin un issue enlazado o una discusión previa pueden cerrarse»); decidir si necesita una propuesta de cambio (un fix va directo a PR; una nueva funcionalidad requiere primero una propuesta OpenSpec aprobada); hacer el cambio (Node 20.19+ y pnpm; pnpm install, pnpm build, pnpm test, pnpm exec tsc --noEmit, pnpm lint); y abrir el PR (título como commit convencional, enlazar el issue, y si un agente de código escribió el código, declarar cuál).
Casos de uso
- Desarrolladores individuales que trabajan con Claude Code, Codex, Cursor, Gemini CLI u otro de los 30+ asistentes pueden reemplazar el flujo de «prompt vago → código inesperado» por
explore → propose → apply → archive. - Equipos multi-repo (plataforma + producto) pueden usar Stores (beta) para que un equipo posea los requisitos en un repositorio de planificación compartido, eliminando el wiki desincronizado.
- Equipos que temen la deriva spec↔código pueden activar
openspec validate --archivedy--report findingscomo hooks de pre-commit/CI, y evaluar el Cloud Agent para detección de deriva en PRs. - Proyectos brownfield grandes se benefician del diseño brownfield-first, con
clay-good/OpenLorepara generar specs iniciales a partir del código existente. - Equipos que ya usan Superpowers u otro framework de disciplina pueden combinar ambos vía los schemas comunitarios (
superpowers-bridge,spec-superflow,openflow), manteniendo la gobernanza de artefactos de OpenSpec y la ejecución disciplinada del otro. - Equipos que desean portabilidad encuentran valor en la neutralidad de herramienta: el mismo flujo de specs funciona en más de 30 asistentes.
Recursos
- Repositorio: https://github.com/Fission-AI/OpenSpec
- Documentación: https://github.com/Fission-AI/OpenSpec/blob/main/docs/README.md · Sitio: https://openspec.dev/
- Reviews: https://www.danclarke.com/openspec/ (Dan Clarke, 8 de mayo de 2026)
- Comunidad / Discord: https://discord.gg/YctCnvvshC
- Video tutoriales: Launch video de Tabish Bidiwale https://youtu.be/N-MftbmnmMo
- Hilos de HN relevantes: https://news.ycombinator.com/item?id=47994012 (Specsmaxxing) · https://news.ycombinator.com/item?id=48221805
- Registros de paquetes: npm https://www.npmjs.com/package/@fission-ai/openspec
- Blog oficial: https://openspec.dev/blog · Releases: https://github.com/Fission-AI/OpenSpec/releases
- Lista curada comunitaria: https://github.com/speclib/awesome-openspec
Nota: este artículo combina el README y la documentación oficial (docs/), MAINTAINERS.md y CONTRIBUTING.md, las notas de versión, el blog oficial de openspec.dev, la API de GitHub, el registro npm, la lista speclib/awesome-openspec y hilos de Hacker News consultados el 14 de septiembre de 2026. Las cifras cambian con el tiempo.
Comentarios