Referencia de CLI

La CLI de OpenSpec (openspec) proporciona comandos de terminal para la configuración del proyecto, validación, inspección de estado y gestión. Estos comandos complementan los comandos de barra diagonal de IA (como /opsx:propose) documentados en Commands.

Resumen

Categoría	Comandos	Propósito
Configuración	`init`, `update`	Inicializar y actualizar OpenSpec en su proyecto
Stores (repositorios independientes de OpenSpec)	`store setup`, `store register`, `store unregister`, `store remove`, `store list`, `store doctor`	Gestionar stores — repositorios independientes de OpenSpec que ha registrado
Salud	`doctor`	Informar sobre el estado de salud de las relaciones para la raíz resuelta
Contexto de trabajo	`context`	Ensamblar el conjunto de trabajo (raíz + stores referenciados)
Conjuntos de trabajo personales	`workset create`, `workset list`, `workset open`, `workset remove`	Mantener y abrir vistas de trabajo personales y locales en su herramienta
Navegación	`list`, `view`, `show`	Explorar cambios y especificaciones
Validación	`validate`	Verificar cambios y especificaciones en busca de problemas
Ciclo de vida	`archive`	Finalizar cambios completados
Flujo de trabajo	`new change`, `status`, `instructions`, `templates`, `schemas`	Soporte para flujos de trabajo basados en artefactos
Esquemas	`schema init`, `schema fork`, `schema validate`, `schema which`	Crear y gestionar flujos de trabajo personalizados
Configuración	`config`	Ver y modificar configuraciones
Utilidades	`feedback`, `completion`	Retroalimentación e integración con shell

Comandos de Humanos vs Agentes

La mayoría de los comandos de la CLI están diseñados para el uso humano en una terminal. Algunos comandos también admiten el uso por agentes/scripts mediante salida JSON.

Comandos solo para humanos

Estos comandos son interactivos y están diseñados para su uso en terminal:

Comando	Propósito
`openspec init`	Inicializar proyecto (preguntas interactivas)
`openspec view`	Panel de control interactivo
`openspec workset open <name>`	Abrir un conjunto de trabajo guardado (ventana del editor o sesión de agente de terminal)
`openspec config edit`	Abrir configuración en el editor
`openspec feedback`	Enviar comentarios a través de GitHub
`openspec completion install`	Instalar autocompletado de shell

Comandos compatibles con agentes

Estos comandos admiten la salida --json para su uso programático por parte de agentes de IA y scripts:

Comando	Uso humano	Uso por agente
`openspec list`	Explorar cambios/especificaciones	`--json` para datos estructurados
`openspec show <item>`	Leer contenido	`--json` para análisis
`openspec validate`	Buscar problemas	`--all --json` para validación masiva
`openspec status`	Ver progreso de artefactos	`--json` para estado estructurado
`openspec instructions`	Obtener próximos pasos	`--json` para instrucciones del agente
`openspec templates`	Encontrar rutas de plantillas	`--json` para resolución de rutas
`openspec schemas`	Listar esquemas disponibles	`--json` para descubrimiento de esquemas; `--store <id>` para seleccionar una raíz registrada
`openspec store setup <id>`	Crear y registrar un almacén local	`--json` con entradas explícitas para una salida de configuración estructurada
`openspec store register <path>`	Registrar un almacén existente	`--json` para una salida de registro estructurada
`openspec store unregister <id>`	Olvidar un registro de almacén local	`--json` para una salida de limpieza estructurada
`openspec store remove <id>`	Eliminar la carpeta de un almacén local registrado	`--yes --json` para eliminación no interactiva
`openspec store list`	Explorar almacenes registrados	`--json` para registros estructurados
`openspec store doctor`	Comprobar la configuración del almacén local	`--json` para diagnósticos estructurados
`openspec new change <id>`	Crear estructura base para cambios locales al repositorio	`--json`, además de `--store <id>` para usar un almacén registrado como raíz de OpenSpec
`openspec workset create [name]`	Componer una vista de trabajo personal	`--member <path> --json` para composición no interactiva
`openspec workset list`	Explorar conjuntos de trabajo guardados	`--json` para vistas estructuradas
`openspec workset remove <name>`	Eliminar una vista guardada	`--yes --json` para eliminación no interactiva

Opciones globales

Estas opciones funcionan con todos los comandos:

Opción	Descripción
`--version`, `-V`	Mostrar número de versión
`--no-color`	Deshabilitar la salida de colores
`--help`, `-h`	Mostrar ayuda para el comando

Comandos de configuración

`openspec init`

Inicializa OpenSpec en tu proyecto. Crea la estructura de carpetas y configura las integraciones de herramientas de IA.

El comportamiento predeterminado utiliza los valores predeterminados de la configuración global: perfil core, entrega both, flujos de trabajo propose, explore, apply, update, sync, archive.

openspec init [path] [options]

Utiliza --language <language> para añadir una instrucción de idioma a la openspec/config.yaml de un nuevo proyecto. Para un proyecto existente, edita el campo context de la configuración para que OpenSpec nunca sobrescriba las indicaciones específicas del proyecto.

Argumentos:

Argumento	Requerido	Descripción
`path`	No	Directorio objetivo (predeterminado: directorio actual)

Opciones:

Opción	Descripción
`--tools <list>`	Configurar herramientas de IA de forma no interactiva. Usa `all`, `none` o una lista separada por comas
`--language <language>`	Escribir artefactos en este idioma al crear una nueva configuración
`--force`	Limpieza automática de archivos heredados sin solicitar confirmación
`--profile <profile>`	Anular el perfil global para esta ejecución de inicialización (`core` o `custom`)
`--no-animation`	Mostrar una pantalla de bienvenida estática en lugar de la animada
`--copilot-cloud`	Configurar los archivos del agente de codificación en la nube de GitHub Copilot sin solicitar confirmación
`--no-copilot-cloud`	Omitir los archivos del agente de codificación en la nube de GitHub Copilot sin solicitar confirmación

--profile custom utiliza los flujos de trabajo que actualmente están seleccionados en la configuración global (openspec config profile).

La animación de bienvenida también se omite cuando la variable de entorno OPENSPEC_NO_ANIMATION está establecida (cualquier valor, incluido el vacío), cuando NO_COLOR está establecido con un valor no vacío, o cuando la preferencia de movimiento reducido del sistema operativo está habilitada (Reducir movimiento en macOS, animaciones desactivadas en GNOME).

IDs de herramientas compatibles (--tools) — windsurf también es aceptado, como alias de devin: amazon-q, antigravity, auggie, bob, claude, cline, command-code, codeartsagent, codex, devin, forgecode, codebuddy, continue, costrict, crush, cursor, factory, gemini, github-copilot, hermes, iflow, junie, kilocode, kimi, kiro, lingma, minimax-code, vibe, oh-my-pi, opencode, pi, codeassistant, qoder, qwen, rovodev, roocode, trae, zed, zcode, agents

Esta lista refleja AI_TOOLS en src/core/config.ts. Consulta Herramientas compatibles para las rutas de habilidades y comandos de cada herramienta.

Ejemplos:

bash

# Inicialización interactiva
openspec init

# Inicializar en un directorio específico
openspec init ./my-project

# No interactivo: configurar para Claude y Cursor
openspec init --tools claude,cursor

# No interactivo: configurar habilidades globales de MiniMax Code
openspec init --tools minimax-code

# Configurar para todas las herramientas compatibles
openspec init --tools all

# Anular perfil para esta ejecución
openspec init --profile core

# Omitir preguntas y limpiar automáticamente archivos heredados
openspec init --force

Lo que crea:

openspec/
├── specs/              # Tus especificaciones (fuente de verdad)
├── changes/            # Cambios propuestos
└── config.yaml         # Configuración del proyecto

.claude/skills/         # Habilidades de Claude Code (si se seleccionó claude)
.cursor/skills/         # Habilidades de Cursor (si se seleccionó cursor)
.cursor/commands/       # Comandos OPSX de Cursor (si la entrega incluye comandos)
.agents/skills/         # Habilidades compartidas para herramientas compatibles con AGENTS.md (si se seleccionaron agents)
... (otras configuraciones de herramientas)

`openspec update`

Actualiza los archivos de instrucciones de OpenSpec después de actualizar la CLI. Regenera los archivos de configuración de las herramientas de IA utilizando tu perfil global actual, los flujos de trabajo seleccionados y el modo de entrega.

openspec update [path] [options]

Argumentos:

Argumento	Requerido	Descripción
`path`	No	Directorio objetivo (predeterminado: directorio actual)

Opciones:

Opción	Descripción
`--force`	Forzar la actualización incluso cuando los archivos estén actualizados

Ejemplo:

bash

# Actualizar archivos de instrucciones después de una actualización npm
npm install -g @fission-ai/openspec@latest
openspec update

Actualiza primero el paquete. Los archivos de instrucciones son generados por la CLI instalada, por lo que ejecutar openspec update contra una instalación obsoleta informará de que todo está actualizado sin añadir los flujos de trabajo que incluyen las versiones más recientes.

Para hacer esto visible, openspec update consulta al registro de npm si se ha publicado una CLI más reciente. Cuando la tuya está retrasada, ofrece actualizar:

text

Hay disponible una versión más reciente de la CLI de OpenSpec (v1.6.0 → v1.7.0).
  Ejecutando desde: /usr/local/lib/node_modules/@fission-ai/openspec
¿Actualizar a v1.7.0 ahora? (Y/n)

Responde "sí" y ejecutará npm install -g @fission-ai/openspec@latest, luego volverá a ejecutar la actualización con la nueva CLI para que los nuevos flujos de trabajo se apliquen en el mismo comando. Confirma la actualización consultando la versión al binario instalado en lugar de confiar en el código de salida de npm, por lo que si otra instalación anterior en tu PATH sigue respondiendo, te lo indica en lugar de afirmar que tuvo éxito. Responde "no" e imprimirá el comando y realizará la actualización con la CLI que tienes. Ctrl-C detiene el comando.

La oferta aparece solo en una terminal interactiva, y solo cuando npm posee la instalación — el único caso en el que npm install -g realmente soluciona el problema. Todo lo demás recibe el comando que coincide con cómo fue instalado:

Cómo se instaló OpenSpec	Qué obtienes
Instalación global de npm	El mensaje de solicitud y la ejecución de la actualización para ti — en una terminal interactiva; la salida canalizada obtiene el comando impreso en su lugar
Instalación global de pnpm, bun, yarn o volta	El propio comando de ese gestor: `pnpm add -g …@latest`, `bun add -g …@latest`, `yarn global add …@latest` o `volta install …@latest`
Una dependencia del proyecto	Una nota para actualizar la dependencia, ya que su gestor de paquetes posee el archivo lock
Una caché de `npx` / `dlx`	`npx @fission-ai/openspec@latest update` — ese comando es la actualización, por lo que no hay un segundo paso
Un clon de git	Nada — tu versión es la que indique la rama

Cada vez que se imprime algo, nombra el directorio desde el cual se cargó la CLI en ejecución — el lugar que debes comprobar cuando has actualizado pero un shim obsoleto aún domina tu PATH.

Consulta el registro en npm_config_registry cuando npm lo exporta, y https://registry.npmjs.org en caso contrario. No se lee ningún .npmrc: permitir que el contenido de los archivos elija hacia dónde va una solicitud saliente es un flujo que vale la pena evitar, y el .npmrc de un proyecto viaja con el repositorio. En un espejo privado, exporta npm_config_registry — o establece OPENSPEC_NO_UPDATE_CHECK para omitir la comprobación por completo. La comprobación se omite cuando CI está establecido en cualquier valor excepto un valor explícito de apagado (false, 0, no, off o vacío), bajo NODE_ENV=test, y siempre que esté establecido OPENSPEC_NO_UPDATE_CHECK (cualquier valor), DO_NOT_TRACK=1 u OPENSPEC_TELEMETRY=0. Se ejecuta antes de la actualización y puede retrasarla como máximo 1.5 segundos — abandona después de eso incluso cuando la red pierde paquetes silenciosamente, y permanece en silencio cuando el registro no es accesible.

Cómo se decide "actualizado": los archivos de habilidades registran la versión que los generó, por lo que OpenSpec compara eso con la CLI instalada. Los archivos de comandos no llevan marca de versión, por lo que para una herramienta que tiene comandos pero no habilidades (entrega commands), OpenSpec compara el contenido de los archivos con lo que generaría ahora — las ediciones en esos archivos cuentan como desviación y se sobrescriben. Con la entrega skills o both, solo se verifica la versión registrada, por lo que un archivo editado a mano cuya versión aún coincide se deja intacto; usa --force para reescribirlo. De cualquier manera, los archivos generados son propiedad de OpenSpec — mantén tus propias instrucciones en otro lugar.

Stores (repos independientes de OpenSpec)

Beta. Los stores y las funciones construidas sobre ellos (referencias, contexto de trabajo, worksets) son nuevos; los nombres de comandos, las banderas, los formatos de archivo y la salida JSON pueden cambiar entre versiones. Para la guía paso a paso orientada a problemas, consulte la guía de stores.

Un store es un repo independiente de OpenSpec que has registrado en esta máquina — por ejemplo, un repo de planificación o un repo de contratos. Registrar un store permite que los comandos normales (list, show, status, validate, new change, archive, ...) actúen en él desde cualquier lugar pasando --store <id>.

`openspec store setup`

Crea y registra un store local. Sin argumentos en una terminal, OpenSpec guía al usuario a través de la configuración. Los agentes y scripts deben pasar entradas explícitas y usar --json.

bash

openspec store setup [id] [options]

Opciones:

Opción	Descripción
`--path <path>`	Carpeta donde debe vivir el store (por ejemplo `~/openspec/<id>`)
`--remote <url>`	Registra el remote canónico en el `store.yaml` del nuevo store
`--init-git`	Inicializa un repositorio Git con un commit inicial (predeterminado)
`--no-init-git`	Omite todas las acciones de Git: sin init, sin commit inicial
`--json`	Salida en JSON

Las ejecuciones no interactivas (--json, scripts, agentes) deben pasar tanto el id del store como --path. En una terminal interactiva, la configuración solicita la ubicación con una sugerencia editable en un lugar visible y de propiedad del usuario (por ejemplo ~/openspec/<id>); nunca usa como predeterminado el directorio de datos administrado por OpenSpec.

Ejemplos:

bash

openspec store setup
openspec store setup team-context
openspec store setup team-context --path ~/openspec/team-context --no-init-git
openspec store setup team-context --path ~/openspec/team-context --no-init-git --json

`openspec store register`

Registra una carpeta de store local existente. Durante la beta de stores, un root puede registrarse antes de que existan cambios, se hayan aplicado specs o se hayan archivado cambios; en ese caso, openspec/changes/, openspec/specs/ y openspec/changes/archive/ pueden estar ausentes hasta que los comandos normales los creen. Un repo solo de configuración que declara store: <id> permanece como un puntero a otro store y no se registra como root de store a menos que se elimine ese puntero.

bash

openspec store register [path] [options]

Opciones:

Opción	Descripción
`--id <id>`	Id del store; por defecto usa los metadatos del store o el nombre de la carpeta
`--yes`	Confirma la creación de metadatos de identidad del store para un root de OpenSpec saludable
`--json`	Salida en JSON

`openspec store unregister`

Olvida un registro de store local sin eliminar archivos.

bash

openspec store unregister <id> [--json]

Usa esto cuando un store fue movido, clonado en otro lugar o ya no debería mostrarse en OpenSpec en esta máquina.

`openspec store remove`

Olvida un registro de store local y elimina su carpeta local.

bash

openspec store remove <id> [--yes] [--json]

remove muestra la carpeta exacta antes de eliminarla en una terminal interactiva. Los agentes, scripts y llamadores JSON deben pasar --yes para confirmar la eliminación. OpenSpec se niega a eliminar una carpeta que no contenga metadatos de store coincidentes.

`openspec store list`

Lista los stores registrados localmente.

bash

openspec store list [--json]
openspec store ls [--json]

`openspec store doctor`

Comprueba el registro local del store, los metadatos y la presencia de Git.

bash

openspec store doctor [id] [--json]

Doctor es solo diagnóstico; informa sobre roots faltantes, discrepancias de metadatos y estado de registro local inválido sin modificar el store.

Referenciar stores desde un proyecto

Un repo de proyecto puede declarar en qué stores se basa su trabajo en openspec/config.yaml:

yaml

schema: spec-driven
references:
  - team-context

A partir de ese momento, la salida de openspec instructions en ese repo (tanto las superficies por artefacto como apply, en modo JSON y modo humano) incluye un índice de las specs de cada store referenciado — ids de spec, un resumen de una línea de la sección Purpose de cada spec, y el comando de obtención (openspec show <spec-id> --type spec --store <id>). El índice se construye en vivo desde el checkout registrado en cada ejecución; el contenido de las specs nunca se copia en la salida.

Las referencias son contexto de solo lectura. Nunca cambian dónde actúan los comandos: el trabajo permanece en el propio root del repo, y escribir en un store referenciado sigue siendo una acción explícita con --store. Una referencia que no se puede resolver (por ejemplo, un store no registrado en esta máquina) se degrada a una advertencia en el índice con la corrección exacta, y las instructions se generan igualmente. openspec doctor informa sobre la salud de las referencias en un solo lugar.

Registrar desde dónde se clonó un store

Un store puede registrar su fuente de clonado canónica en su archivo de identidad comprometido, de modo que la incorporación nunca se quede atascada en "registrar el store":

bash

openspec store setup team-context --path ~/openspec/team-context \
  --remote git@github.com:acme/team-context.git

El remote queda en .openspec-store/store.yaml dentro del commit inicial, de modo que cada clon nace sabiéndolo. Para un store existente, edita store.yaml a mano y haz commit. store doctor muestra el remote registrado (y el Git origin observado del checkout); la guía de configuración/registro lo menciona; y register registra el origin del checkout en el registro local de la máquina.

Una declaración de referencia también puede llevar la fuente de clonado, de modo que un compañero de equipo que aún no tiene el store obtiene una corrección completa y copiable (git clone <remote> <path> && openspec store register <path> --id <id>):

yaml

references:
  - { id: team-context, remote: "git@github.com:acme/team-context.git" }

Registrar un remote no es sincronización: OpenSpec nunca clona, tira ni empuja por su cuenta.

Declarar un store predeterminado

Un repo cuya planificación esté completamente externalizada — sin openspec/specs/ ni openspec/changes/ locales — puede declarar su store una sola vez en lugar de pasar --store en cada comando:

yaml

# openspec/config.yaml (el único archivo bajo openspec/)
store: team-context

Los comandos normales luego se resuelven automáticamente al store declarado; el banner del root y el bloque JSON root informan source: "declared" con el id del store, y las pistas impresas siguen llevando --store <id>. La declaración es un respaldo, nunca una sobrescritura: el --store explícito siempre prevalece, y un directorio con carpetas de planificación reales ignora el puntero (con una advertencia). Para convertir un repo puntero en un root local de OpenSpec, elimina la línea store: y ejecuta openspec init — init se niega a crear la estructura mientras la declaración esté presente.

Una variante a nivel de máquina cubre todos los repos a la vez: openspec config set defaultStore <id> (ver Configuración). Solo se consulta después de que --store, un root local y un puntero de proyecto hayan fallado en resolverse; el banner del root y el bloque JSON root entonces informan source: "global_default".

Doctor (salud de las relaciones)

Una sola pregunta de solo lectura, un solo lugar: ¿está sana la raíz de OpenSpec y están disponibles en esta máquina los almacenes a los que hace referencia?

bash

openspec doctor [--store <id>] [--json]

El informe separa la salud de la raíz, la salud de los metadatos de los almacenes (incluyendo una nota cuando el remoto registrado y el origen del checkout divergen, y una nota cuando el checkout del almacén ha quedado por detrás de su ref de seguimiento remoto obtenido por última vez), y la salud de las referencias (se muestran las mismas instrucciones de diagnóstico, con correcciones de clonación para referencias no resueltas). Los hallazgos de salud de cualquier gravedad salen con código 0 — los agentes leen los arrays status; solo los fallos de comando (sin raíz, almacén desconocido) salen con 1. Doctor nunca clona, sincroniza ni repara. Para obtener el conjunto ensamblado en sí mismo, en lugar de su salud, usa openspec context.

Contexto de trabajo (el conjunto ensamblado)

Todo lo que este trabajo relaciona a través de las declaraciones de OpenSpec, en un solo conjunto de trabajo: la raíz de OpenSpec y los almacenes a los que hace referencia.

bash

openspec context [--store <id>] [--json] [--code-workspace <path> [--force]]

El resumen JSON es consumible por agentes (cada almacén referenciado disponible lleva su receta de obtención; los miembros no resueltos llevan las mismas instrucciones de corrección que muestra doctor). --code-workspace además escribe un archivo de espacio de trabajo de VS Code que contiene la raíz más los almacenes referenciados disponibles (carpetas ref:<id>) — la única escritura que realiza este comando, rechazada sin --force si el archivo ya existe. Los miembros no disponibles se informan, nunca se adivinan.

El "contexto de trabajo" es el conjunto ensamblado; el campo context: en openspec/config.yaml es el trasfondo del proyecto inyectado en las instrucciones — dos cosas diferentes. openspec doctor responde si el conjunto está sano; openspec context responde qué es el conjunto.

Worksets personales

Beta. Los worksets forman parte de la nueva superficie beta; los comandos, banderas y formatos de archivo pueden cambiar entre versiones. Para la guía, consulta la guía de almacenes.

Un workset es una vista personal con nombre de las carpetas en las que trabajas juntos — una raíz de planificación más cualquier otra cosa que elijas — guardada en tu máquina y reabierta por nombre en tu herramienta. Es puramente local: nunca se confirma, nunca se comparte, nunca se deriva de declaraciones, y eliminar uno nunca toca una carpeta miembro.

bash

openspec workset create [name] [--member <path> | --member <name>=<path>]... [--tool <id>] [--json]
openspec workset list [--json]
openspec workset open <name> [--tool <id>]
openspec workset remove <name> [--yes] [--json]

create ejecuta un breve flujo guiado (o acepta banderas --member de forma no interactiva; el primer miembro es el primario — las sesiones comienzan allí). open lanza la herramienta elegida: los editores (VS Code, Cursor) abren una ventana con cada miembro y regresan; los agentes de CLI (Claude Code, codex) toman el control de esta terminal como una sesión con cada miembro adjunto y sin prompt prellenado, finalizando cuando sales. Una carpeta miembro ausente en el momento de abrir se omite con una nota; el resto se abre. La preferencia de herramienta guardada se puede anular por cada apertura con --tool.

Añadir soporte para una nueva herramienta es configuración, no código. Cada herramienta tiene uno de dos estilos de lanzamiento — workspace-file (lanzada con el .code-workspace generado) o attach-dirs (una bandera de adjuntar por cada miembro) — y la clave openers en el config.json global (ábrelo con openspec config edit) añade herramientas o ajusta las integradas por campo:

json

{
  "openers": {
    "zed": { "style": "workspace-file" },
    "claude": { "attach_flag": "--dir" }
  }
}

Todo el estado de los worksets reside en la carpeta worksets/ del directorio de datos global (las vistas guardadas más los archivos <name>.code-workspace generados, regenerados en cada apertura); eliminar esa carpeta elimina todo rastro.

Comandos de exploración

`openspec list`

Lista los cambios o especificaciones de tu proyecto.

openspec list [options]

Opciones:

Opción	Descripción
`--specs`	Listar especificaciones en lugar de cambios
`--changes`	Listar cambios (predeterminado)
`--sort <order>`	Ordenar por `recent` (reciente) o `name` (nombre)
`--json`	Salida en formato JSON

Ejemplos:

bash

# Listar todos los cambios activos
openspec list

# Listar todas las especificaciones
openspec list --specs

# Salida JSON para scripts
openspec list --json

Salida (texto):

Cambios:
  add-dark-mode     Sin tareas      ahora mismo

`openspec view`

Muestra un panel interactivo para explorar especificaciones y cambios.

openspec view

Abre una interfaz basada en terminal para navegar por las especificaciones y cambios de tu proyecto.

`openspec show`

Muestra los detalles de un cambio o especificación.

openspec show [item-name] [options]

Argumentos:

Argumento	Requerido	Descripción
`item-name`	No	Nombre del cambio o especificación (pide si se omite)

Opciones:

Opción	Descripción
`--type <type>`	Especifica el tipo: `change` o `spec` (autodetectado si no es ambiguo)
`--json`	Salida como JSON
`--no-interactive`	Deshabilita las preguntas

Opciones específicas para cambios:

Opción	Descripción
`--deltas-only`	Muestra solo las especificaciones delta (modo JSON)

Opciones específicas para especificaciones:

Opción	Descripción
`--requirements`	Muestra solo los requisitos, excluye escenarios (modo JSON)
`--no-scenarios`	Excluye el contenido de los escenarios (modo JSON)
`-r, --requirement <id>`	Muestra un requisito específico por índice basado en 1 (modo JSON)

Ejemplos:

bash

# Selección interactiva
openspec show

# Mostrar un cambio específico
openspec show add-dark-mode

# Mostrar una especificación específica
openspec show auth --type spec

# Salida JSON para análisis
openspec show add-dark-mode --json

Comandos de validación

`openspec validate`

Valida los cambios y las especificaciones en busca de problemas estructurales, y verifica los requisitos MODIFICADOS de un cambio frente a las especificaciones principales que reemplazarían.

openspec validate [item-name] [options]

Un cambio con cero deltas de especificación fallará la validación, a menos que su .openspec.yaml declare skip_specs: true (para refactorizaciones puras, herramientas o trabajo de documentación — ver Receta 5).

Argumentos:

Argumento	Requerido	Descripción
`item-name`	No	Elemento específico a validar (solicita entrada si se omite)

Opciones:

Opción	Descripción
`--all`	Validar todos los cambios y especificaciones
`--changes`	Validar todos los cambios
`--specs`	Validar todas las especificaciones
`--archived`	Validar que los cambios archivados tengan todas las tareas completadas (para linting pre-commit)
`--type <type>`	Especificar el tipo cuando el nombre es ambiguo: `change` o `spec`
`--strict`	Habilitar el modo de validación estricta
`--json`	Salida en formato JSON
`--concurrency <n>`	Máximo de validaciones en paralelo (por defecto: 6, o variable de entorno `OPENSPEC_CONCURRENCY`)
`--no-interactive`	Deshabilitar las solicitudes interactivas

--archived tiene su propio alcance: no valida los deltas de especificación (ya aplicados en el momento del archivo), sino que verifica que cada cambio bajo changes/archive/ tenga marcadas todas las casillas de verificación de sus tasks.md, saliendo con código de error distinto de cero si alguna está sin marcar. Esto detecta cambios que fueron archivados con trabajo incompleto, útil en un hook pre-commit.

Ejemplos:

bash

# Validación interactiva
openspec validate

# Validar un cambio específico
openspec validate add-dark-mode

# Validar todos los cambios
openspec validate --changes

# Validar todo con salida JSON (para CI/scripts)
openspec validate --all --json

# Validación estricta con mayor paralelismo
openspec validate --all --strict --concurrency 12

# Fallar si algún cambio archivado aún tiene tareas sin marcar
openspec validate --archived

Salida (texto):

Validating add-dark-mode...
  ✓ proposal.md valid
  ✓ specs/ui/spec.md valid
  ⚠ design.md: missing "Technical Approach" section

1 warning found

Salida (JSON):

json

{
  "version": "1.0.0",
  "results": {
    "changes": [
      {
        "name": "add-dark-mode",
        "valid": true,
        "warnings": ["design.md: missing 'Technical Approach' section"]
      }
    ]
  },
  "summary": {
    "total": 1,
    "valid": 1,
    "invalid": 0
  }
}

Comandos de ciclo de vida

`openspec archive`

Archiva un cambio completado y fusiona los deltas de especificación en las especificaciones principales.

openspec archive [change-name] [options]

Argumentos:

Argumento	Requerido	Descripción
`change-name`	No	Cambio a archivar (solicita entrada si se omite; requerido cuando nada puede responder a la solicitud)

Opciones:

Opción	Descripción
`-y, --yes`	Omitir las solicitudes de confirmación. Requerido cuando nada puede responderlas — un agente de IA, un trabajo de CI o cualquier ejecución con stdin cerrado
`--skip-specs`	Omitir actualizaciones de especificaciones para una única ejecución de archivo. Un cambio que permanentemente no tenga deltas de especificación debería declarar `skip_specs: true` en su `.openspec.yaml` en su lugar — se archiva sin bandera
`--no-validate`	Omitir la validación (requiere confirmación). También deshabilita la jubilación de capacidades — sin veredicto del validador, nada se jubila

Ejemplos:

bash

# Archivo interactivo (pregunta qué cambio y luego confirma)
openspec archive

# Archivar cambio específico
openspec archive add-dark-mode

# Archivar sin solicitudes (agentes, CI, scripts)
openspec archive add-dark-mode --yes

# Archivar un cambio de herramientas que no afecta las especificaciones
openspec archive update-ci-config --skip-specs

Jubilación de una capacidad: Añade el marcador de jubilación a los metadatos del cambio:

yaml

# openspec/changes/retire-legacy/.openspec.yaml
schema: spec-driven
retire_capabilities: true

Luego archiva el cambio normalmente:

bash

openspec archive retire-legacy --yes

Cuando el cambio elimina el último requisito de la capacidad, OpenSpec borra su spec.md en vivo. Otros deltas de capacidad en el mismo cambio siguen actualizando sus especificaciones principales. Sin el marcador, el archivo se detiene antes de cambiar cualquier archivo y te indica que lo añadas.

Qué hace:

Valida el cambio (a menos que se use --no-validate)
Solicita confirmación (a menos que se use --yes)
Reserva el destino del archivo antes de cambiar cualquier especificación principal
Valida y fusiona los deltas de especificación activos en openspec/specs/ — una capacidad cuyo último requisito elimina el cambio se jubila, y su archivo de especificación se borra, pero solo cuando el .openspec.yaml del cambio declara retire_capabilities: true junto a su schema:
Mueve la carpeta del cambio a openspec/changes/archive/YYYY-MM-DD-<name>/
Si una mutación de especificación o un movimiento final falla antes de asegurar un archivo completo, restaura las especificaciones y deja o devuelve el cambio en su ruta activa
Si una copia de respaldo verificada completa pero falla la limpieza de origen en fase, conserva el archivo completo y el estado de especificación comprometido para recuperación

Sin terminal: un agente de IA, un trabajo de CI o cualquier ejecución con stdin cerrado no puede responder al paso 2, por lo que el archivo se detiene antes de tocar nada, sale con código 1, y nombra el comando para volver a ejecutarlo — openspec archive <name> --yes, llevando cualquier otra bandera que hayas pasado. Pasa --yes (y el nombre del cambio) al principio para omitir el ida y vuelta.

Comandos del flujo de trabajo

Estos comandos admiten el flujo de trabajo OPSX dirigido por artefactos. Son útiles tanto para humanos que verifican el progreso como para agentes que determinan los siguientes pasos.

`openspec new change`

Crea un directorio de cambio y metadatos opcionales confirmados en la raíz de OpenSpec resuelta.

bash

openspec new change <name> [options]

Los nombres de los cambios deben usar kebab-case en minúsculas: letras minúsculas, números y guiones simples. No pueden contener espacios, guiones bajos, letras mayúsculas, guiones consecutivos, ni guiones al principio o al final. Se permite un número inicial, por lo que puedes prefijar los nombres para ordenar o clasificar los cambios, por ejemplo 100-add-feature o 00001-add-auth.

Opciones:

Opción	Descripción
`--description <text>`	Descripción para agregar a `index.md`
`--goal <text>`	Metadatos opcionales de objetivo para almacenar con el cambio
`--schema <name>`	Esquema de flujo de trabajo a utilizar
`--store <id>`	Identificador de almacén a usar como raíz de OpenSpec (un almacén es un repositorio OpenSpec independiente que has registrado)
`--json`	Salida en JSON

Ejemplos:

bash

openspec new change add-billing-api
openspec new change add-billing-api --store team-context --json

`openspec status`

Muestra el estado de finalización de los artefactos para un cambio.

openspec status [options]

Opciones:

Opción	Descripción
`--change <id>`	Nombre del cambio (solicita si se omite)
`--schema <name>`	Anulación de esquema (auto-detectado desde la configuración del cambio)
`--json`	Salida en JSON

Ejemplos:

bash

# Verificación interactiva del estado
openspec status

# Estado para un cambio específico
openspec status --change add-dark-mode

# JSON para uso por agentes
openspec status --change add-dark-mode --json

Salida (texto):

Change: add-dark-mode
Schema: spec-driven
Progress: 2/4 artifacts complete

[x] proposal
[x] specs
[ ] design
[-] tasks (blocked by: design)

Un cambio que declara skip_specs: true muestra su etapa de especificaciones como [~] specs (skipped: change declares skip_specs) y lo excluye del conteo de progreso.

Salida (JSON):

json

{
  "changeName": "add-dark-mode",
  "schemaName": "spec-driven",
  "isPlanningComplete": false,
  "isComplete": false,
  "applyRequires": ["tasks"],
  "artifacts": [
    {"id": "proposal", "outputPath": "proposal.md", "status": "done", "requires": []},
    {"id": "specs", "outputPath": "specs/**/*.md", "status": "done", "requires": ["proposal"]},
    {"id": "design", "outputPath": "design.md", "status": "ready", "requires": ["proposal"]},
    {"id": "tasks", "outputPath": "tasks.md", "status": "blocked", "requires": ["specs", "design"], "missingDeps": ["design"]}
  ]
}

isPlanningComplete informa si existe cada artefacto de planificación no omitido; los artefactos omitidos se consideran satisfechos sin ser creados. No informa si las tareas de implementación están completas. isComplete se mantiene como un alias de compatibilidad con el mismo valor.

Los artefactos se enumeran en orden de dependencia: una dependencia nunca aparece después de algo que la requiere, y los artefactos que se vuelven disponibles al mismo tiempo (los specs y design de spec-driven solo necesitan proposal) mantienen el orden en que el esquema los declara, en lugar de un orden alfabético. Así, la primera entrada ready es el artefacto a redactar a continuación.

`openspec instructions`

Obtén instrucciones enriquecidas para crear un artefacto o aplicar tareas. Utilizado por agentes de IA para entender qué crear a continuación.

openspec instructions [artifact] [options]

Argumentos:

Argumento	Requerido	Descripción
`artifact`	No	ID de artefacto, o superficie de entrada del flujo de trabajo: `apply` o `archive`

Opciones:

Opción	Descripción
`--change <id>`	Nombre del cambio (requerido en modo no interactivo)
`--schema <name>`	Anulación de esquema
`--json`	Salida en JSON

Casos especiales: Usa apply para obtener instrucciones de implementación de tareas. Usa archive para obtener las entradas de archivado actuales, de solo lectura (context y operationGuidance) para un cambio válido; no archiva ni modifica nada.

Ejemplos:

bash

# Obtener instrucciones para el próximo artefacto
openspec instructions --change add-dark-mode

# Obtener instrucciones de un artefacto específico
openspec instructions design --change add-dark-mode

# Obtener instrucciones de aplicación/implementación
openspec instructions apply --change add-dark-mode

# Obtener entradas de operación de archive sin archivar
openspec instructions archive --change add-dark-mode --json

# JSON para consumo por agentes
openspec instructions design --change add-dark-mode --json

La salida incluye:

Contenido de la plantilla para el artefacto
Contexto del proyecto desde la configuración
Contenido de los artefactos de dependencia
Reglas por artefacto desde la configuración
Contexto actual del proyecto y guía de operación coincidente para apply/archive

Las entradas de operación se leen desde el repositorio resuelto o el almacén seleccionado en cada invocación. El contexto del proyecto es una entrada requerida a nivel de prompt: los agentes lo leen y aplican hechos, convenciones y restricciones relevantes del proyecto. La guía de operación es un consejo adicional opcional: los agentes consideran cada entrada y siguen solo aquellas que son aplicables y compatibles con el flujo de trabajo incorporado. Ambos campos se mantienen separados de las elecciones explícitas del usuario, del estado controlado por CLI, de las instrucciones incorporadas y de las reglas de artefactos. El contexto conflictivo se informa; la guía conflictiva o no aplicable no se sigue y se explica el motivo. Estos son contratos de comportamiento para los agentes generados, no verificaciones CLI exigibles. instructions archive devuelve solo el cambio seleccionado, las entradas opcionales y los metadatos raíz; no incluye el flujo de trabajo de archivo estático.

Para un artefacto omitido mediante skip_specs: true, la salida es solo una advertencia (JSON agrega campos skipped/warning) — el artefacto no debe crearse.

`openspec templates`

Muestra las rutas de plantilla resueltas para todos los artefactos en un esquema.

openspec templates [options]

Opciones:

Opción	Descripción
`--schema <name>`	Esquema a inspeccionar (por defecto: `spec-driven`)
`--json`	Salida en JSON

Ejemplos:

bash

# Mostrar rutas de plantilla para el esquema predeterminado
openspec templates

# Mostrar plantillas para un esquema personalizado
openspec templates --schema my-workflow

# JSON para uso programático
openspec templates --json

Salida (texto):

Schema: spec-driven

Templates:
  proposal  → ~/.openspec/schemas/spec-driven/templates/proposal.md
  specs     → ~/.openspec/schemas/spec-driven/templates/specs.md
  design    → ~/.openspec/schemas/spec-driven/templates/design.md
  tasks     → ~/.openspec/schemas/spec-driven/templates/tasks.md

`openspec schemas`

Lista los esquemas de flujo de trabajo disponibles con sus descripciones y flujos de artefactos.

openspec schemas [options]

Opciones:

Opción	Descripción
`--json`	Salida en JSON
`--store <id>`	Utiliza un almacén registrado como raíz de OpenSpec

Ejemplo:

bash

openspec schemas

Salida:

Available schemas:

  spec-driven (package)
    The default spec-driven development workflow
    Flow: proposal → specs → design → tasks

  my-custom (project)
    Custom workflow for this project
    Flow: research → proposal → tasks

Comandos de esquema

Comandos para crear y gestionar esquemas de flujo de trabajo personalizados.

`openspec schema init`

Crea un nuevo esquema local al proyecto.

openspec schema init <name> [options]

Argumentos:

Argumento	Requerido	Descripción
`name`	Sí	Nombre del esquema (kebab-case)

Opciones:

Opción	Descripción
`--description <text>`	Descripción del esquema
`--artifacts <list>`	IDs de artefactos separados por comas (por defecto: `proposal,specs,design,tasks`)
`--default`	Establecer como esquema predeterminado del proyecto
`--no-default`	No preguntar si se desea establecer como predeterminado
`--force`	Sobrescribir el esquema existente
`--json`	Salida en formato JSON

Ejemplos:

bash

# Creación interactiva de esquema
openspec schema init research-first

# No interactivo con artefactos específicos
openspec schema init rapid \
  --description "Flujo de iteración rápida" \
  --artifacts "proposal,tasks" \
  --default

Lo que crea:

openspec/schemas/<name>/
├── schema.yaml           # Definición del esquema
└── templates/
    ├── proposal.md       # Plantilla para cada artefacto
    ├── specs.md
    ├── design.md
    └── tasks.md

`openspec schema fork`

Copia un esquema existente a tu proyecto para personalizarlo.

openspec schema fork <source> [name] [options]

Argumentos:

Argumento	Requerido	Descripción
`source`	Sí	Esquema a copiar
`name`	No	Nuevo nombre del esquema (por defecto: `<source>-custom`)

Opciones:

Opción	Descripción
`--force`	Sobrescribir el destino existente
`--json`	Salida en formato JSON

Ejemplo:

bash

# Bifurcar el esquema spec-driven integrado
openspec schema fork spec-driven my-workflow

`openspec schema validate`

Valida la estructura y las plantillas de un esquema.

openspec schema validate [name] [options]

Argumentos:

Argumento	Requerido	Descripción
`name`	No	Esquema a validar (valida todos si se omite)

Opciones:

Opción	Descripción
`--verbose`	Mostrar pasos de validación detallados
`--json`	Salida en formato JSON

Ejemplo:

bash

# Validar un esquema específico
openspec schema validate my-workflow

# Validar todos los esquemas
openspec schema validate

`openspec schema which`

Muestra desde dónde se resuelve un esquema (útil para depurar la precedencia).

openspec schema which [name] [options]

Argumentos:

Argumento	Requerido	Descripción
`name`	No	Nombre del esquema

Opciones:

Opción	Descripción
`--all`	Listar todos los esquemas con sus orígenes
`--json`	Salida en formato JSON

Ejemplo:

bash

# Comprobar de dónde proviene un esquema
openspec schema which spec-driven

Salida:

spec-driven resolves from: package
  Source: /usr/local/lib/node_modules/@fission-ai/openspec/schemas/spec-driven

Precedencia de esquemas:

Proyecto: openspec/schemas/<name>/
Usuario: ~/.local/share/openspec/schemas/<name>/
Paquete: Esquemas integrados

Comandos de configuración

`openspec config`

Ver y modificar la configuración global de OpenSpec.

openspec config <subcommand> [options]

Subcomandos:

Subcomando	Descripción
`path`	Mostrar la ubicación del archivo de configuración
`list`	Mostrar toda la configuración actual
`get <key>`	Obtener un valor específico
`set <key> <value>`	Establecer un valor
`unset <key>`	Eliminar una clave
`reset`	Restablecer a los valores predeterminados
`edit`	Abrir en `$EDITOR`
`profile [preset]`	Configurar el perfil del flujo de trabajo de forma interactiva o mediante un preset

Ejemplos:

bash

# Mostrar la ruta del archivo de configuración
openspec config path

# Listar toda la configuración
openspec config list

# Obtener un valor específico
openspec config get telemetry.enabled

# Establecer un valor (desactivar telemetría de uso anónimo)
openspec config set telemetry.enabled false

# Establecer explícitamente un valor de cadena
openspec config set user.name "Mi Nombre" --string

# Eliminar una configuración personalizada
openspec config unset user.name

# Establecer un almacén predeterminado a nivel de máquina (raíz de respaldo cuando no hay --store,
# raíz local ni almacén de proyecto: resolución de puntero)
openspec config set defaultStore team-plans

# Restablecer toda la configuración
openspec config reset --all --yes

# Editar la configuración en tu editor
openspec config edit

# Configurar perfil con asistente basado en acciones
openspec config profile

# Preset rápido: cambiar flujos de trabajo a core (mantiene el modo de entrega)
openspec config profile core

Opt-out de telemetría: telemetry.enabled está activado por defecto cuando no se establece (modelo de opt-out). Establécelo en false para desactivar las estadísticas de uso anónimo y la comprobación de versión de openspec update. Las variables de entorno tienen prioridad sobre la configuración: OPENSPEC_TELEMETRY=0, DO_NOT_TRACK=1, y un valor verdadero de CI (p. ej., true/1/yes) siempre desactivan la telemetría independientemente del valor de configuración.

openspec config profile comienza con un resumen del estado actual y luego te permite elegir:

Cambiar entrega + flujos de trabajo
Cambiar solo la entrega
Cambiar solo los flujos de trabajo
Mantener la configuración actual (salir)

Si mantienes la configuración actual, no se escriben cambios ni se muestra ninguna solicitud de actualización. Si no hay cambios de configuración pero los archivos del proyecto actual están desactualizados respecto a tu perfil/delivery global, OpenSpec mostrará una advertencia y sugerirá ejecutar openspec update. Presionar Ctrl+C también cancela el flujo limpiamente (sin stack trace) y sale con el código 130. En la lista de verificación de flujos de trabajo, [x] significa que el flujo de trabajo está seleccionado en la configuración global. Para aplicar esas selecciones a los archivos del proyecto, ejecuta openspec update (o elige Apply changes to this project now? cuando se te pregunte dentro de un proyecto).

Ejemplos interactivos:

bash

# Actualización solo de entrega
openspec config profile
# elegir: Change delivery only
# elegir entrega: Skills only

# Actualización solo de flujos de trabajo
openspec config profile
# elegir: Change workflows only
# alternar flujos de trabajo en la lista de verificación y confirmar

Comandos de utilidad

`openspec feedback`

Enviar comentarios sobre OpenSpec. Crea un issue en GitHub.

openspec feedback <message> [options]

Argumentos:

Argumento	Requerido	Descripción
`message`	Sí	Resumen del comentario; el texto largo se acorta en el título del issue y se conserva en el cuerpo

Opciones:

Opción	Descripción
`--body <text>`	Detalles adicionales incluidos después del resumen

Requisitos: Debe estar instalado y autenticado el CLI de GitHub (gh).

Ejemplo:

bash

openspec feedback "Add support for custom artifact types" \
  --body "I'd like to define my own artifact types beyond the built-in ones."

`openspec completion`

Gestionar las autocompletaciones de shell para el CLI de OpenSpec.

openspec completion <subcommand> [shell]

Subcomandos:

Subcomando	Descripción
`generate [shell]`	Generar el script de autocompletado en stdout
`install [shell]`	Instalar autocompletado para tu shell
`uninstall [shell]`	Eliminar autocompletados instalados

Shells compatibles: bash, zsh, fish, powershell

Ejemplos:

bash

# Instalar autocompletados (detecta automáticamente el shell)
openspec completion install

# Instalar para un shell específico
openspec completion install zsh

# Generar script para instalación manual (bash)
openspec completion generate bash > ~/.bash_completion.d/openspec

# Desinstalar
openspec completion uninstall

Windows (PowerShell): Instalar autocompletados para el host de PowerShell actual:

powershell

$env:PROFILE = $PROFILE
openspec completion install powershell
. $PROFILE

$env:PROFILE indica a OpenSpec qué perfil configurar en esta sesión. El instalador crea directorios de perfil faltantes y añade un bloque gestionado que carga OpenSpecCompletion.ps1. Recargar el perfil habilita los autocompletados inmediatamente.

Para desinstalar desde el host actual, ejecuta:

powershell

$env:PROFILE = $PROFILE
openspec completion uninstall powershell

Reinicia PowerShell después de desinstalar para limpiar los autocompletados de la sesión actual.

Los autocompletados son opcionales (opt-in). El CLI los menciona una sola vez, en stderr, la primera vez que ejecutas un comando en una terminal interactiva, y nunca más — también permanece silencioso si ya tienes autocompletados instalados. Establece OPENSPEC_NO_COMPLETIONS=1 para suprimir completamente ese consejo.

Códigos de salida

Código	Significado
`0`	Éxito
`1`	Error (fallo de validación, archivos faltantes, etc.)

Variables de entorno

Variable	Descripción
`OPENSPEC_TELEMETRY`	Establecer a `0` para desactivar la telemetría y la comprobación de versión de `openspec update` (anula `telemetry.enabled` en la configuración global)
`DO_NOT_TRACK`	Establecer a `1` para desactivar la telemetría y la comprobación de versión de `openspec update` (señal DNT estándar; anula la configuración)
`OPENSPEC_CONCURRENCY`	Concurrencia predeterminada para validación masiva (predeterminado: 6)
`EDITOR` o `VISUAL`	Editor para `openspec config edit`
`NO_COLOR`	Desactivar la salida de colores cuando se establece
`OPENSPEC_NO_ANIMATION`	Desactivar la animación de bienvenida de `openspec init` cuando se establece
`OPENSPEC_NO_COMPLETIONS`	Establecer a `1` para suprimir el consejo único sobre autocompletados de shell
`OPENSPEC_NO_UPDATE_CHECK`	Desactivar la comprobación de `openspec update` para una versión publicada más reciente del CLI cuando se establece (cualquier valor, incluido vacío). También se omite cuando `CI` está establecido (a menos que sea `false`/`0`/`no`/`off`) o `NODE_ENV=test`
`npm_config_registry`	Registro que consulta la comprobación de versión de `openspec update`. Debe ser una URL `http(s)` o recurrirá a `https://registry.npmjs.org`. No se lee ningún archivo `.npmrc`

Documentación relacionada

Commands - Comandos de IA (/opsx:propose, /opsx:apply, etc.)
Workflows - Patrones comunes y cuándo usar cada comando
Customization - Crear esquemas y plantillas personalizados
Getting Started - Guía de configuración inicial

Referencia de CLI ​

Resumen ​

Comandos de Humanos vs Agentes ​

Comandos solo para humanos ​

Comandos compatibles con agentes ​

Opciones globales ​

Comandos de configuración ​

openspec init ​

openspec update ​

Stores (repos independientes de OpenSpec) ​

openspec store setup ​

openspec store register ​

openspec store unregister ​

openspec store remove ​

openspec store list ​

openspec store doctor ​

Referenciar stores desde un proyecto ​

Registrar desde dónde se clonó un store ​

Declarar un store predeterminado ​

Doctor (salud de las relaciones) ​

Contexto de trabajo (el conjunto ensamblado) ​

Worksets personales ​

Comandos de exploración ​

openspec list ​

openspec view ​

openspec show ​

Comandos de validación ​

openspec validate ​

Comandos de ciclo de vida ​

openspec archive ​

Comandos del flujo de trabajo ​

openspec new change ​

openspec status ​

openspec instructions ​

openspec templates ​

openspec schemas ​

Comandos de esquema ​

openspec schema init ​

openspec schema fork ​

openspec schema validate ​

openspec schema which ​

Comandos de configuración ​

openspec config ​

Comandos de utilidad ​

openspec feedback ​

openspec completion ​

Códigos de salida ​

Variables de entorno ​

Documentación relacionada ​

Referencia de CLI

Resumen

Comandos de Humanos vs Agentes

Comandos solo para humanos

Comandos compatibles con agentes

Opciones globales

Comandos de configuración

`openspec init`

`openspec update`

Stores (repos independientes de OpenSpec)

`openspec store setup`

`openspec store register`

`openspec store unregister`

`openspec store remove`

`openspec store list`

`openspec store doctor`

Referenciar stores desde un proyecto

Registrar desde dónde se clonó un store

Declarar un store predeterminado

Doctor (salud de las relaciones)

Contexto de trabajo (el conjunto ensamblado)

Worksets personales

Comandos de exploración

`openspec list`

`openspec view`

`openspec show`

Comandos de validación

`openspec validate`

Comandos de ciclo de vida

`openspec archive`

Comandos del flujo de trabajo

`openspec new change`

`openspec status`

`openspec instructions`

`openspec templates`

`openspec schemas`

Comandos de esquema

`openspec schema init`

`openspec schema fork`

`openspec schema validate`

`openspec schema which`

Comandos de configuración

`openspec config`

Comandos de utilidad

`openspec feedback`

`openspec completion`

Códigos de salida

Variables de entorno

Documentación relacionada