Riferimento CLI

La CLI OpenSpec (openspec) fornisce comandi da terminale per la configurazione del progetto, la validazione, l'ispezione dello stato e la gestione. Questi comandi completano i comandi slash AI (come /opsx:propose) documentati in Comandi.

Riepilogo

Categoria	Comandi	Scopo
Configurazione	`init`, `update`	Inizializza e aggiorna OpenSpec nel tuo progetto
Store (repository OpenSpec standalone)	`store setup`, `store register`, `store unregister`, `store remove`, `store list`, `store doctor`	Gestisci gli store — repository OpenSpec standalone che hai registrato
Salute	`doctor`	Segnala lo stato di salute delle relazioni per la root risolta
Contesto di lavoro	`context`	Assembla il set di lavoro (root + store referenziati)
Workset personali	`workset create`, `workset list`, `workset open`, `workset remove`	Conserva e apri visualizzazioni di lavoro personali e locali nel tuo strumento
Navigazione	`list`, `view`, `show`	Esplora modifiche e specifiche
Validazione	`validate`	Controlla modifiche e specifiche per problemi
Ciclo di vita	`archive`	Finalizza le modifiche completate
Workflow	`new change`, `status`, `instructions`, `templates`, `schemas`	Supporto del workflow basato su artefatti
Schemi	`schema init`, `schema fork`, `schema validate`, `schema which`	Crea e gestisci workflow personalizzati
Configurazione	`config`	Visualizza e modifica le impostazioni
Utilità	`feedback`, `completion`	Feedback e integrazione con la shell

Comandi Umani vs Agent

La maggior parte dei comandi CLI è progettata per l'uso umano in un terminale. Alcuni comandi supportano anche l'uso da parte di agent/script tramite output JSON.

Comandi Solo Umani

Questi comandi sono interattivi e pensati per l'uso nel terminale:

Comando	Scopo
`openspec init`	Inizializza il progetto (domande interattive)
`openspec view`	Dashboard interattiva
`openspec workset open <name>`	Apre un workset salvato (finestra dell'editor o sessione agent del terminale)
`openspec config edit`	Apre la configurazione nell'editor
`openspec feedback`	Invia feedback tramite GitHub
`openspec completion install`	Installa i completamenti della shell

Comandi Compatibili con Agent

Questi comandi supportano l'output --json per l'uso programmatico da parte di agent AI e script:

Comando	Uso Umano	Uso Agent
`openspec list`	Esplora modifiche/spec	`--json` per dati strutturati
`openspec show <item>`	Legge il contenuto	`--json` per l'analisi
`openspec validate`	Verifica la presenza di problemi	`--all --json` per la validazione batch
`openspec status`	Visualizza lo stato degli artifact	`--json` per lo stato strutturato
`openspec instructions`	Ottiene i prossimi passaggi	`--json` per le istruzioni dell'agent
`openspec templates`	Trova i percorsi dei template	`--json` per la risoluzione dei percorsi
`openspec schemas`	Elenca gli schemi disponibili	`--json` per la scoperta degli schemi; `--store <id>` per selezionare una radice registrata
`openspec store setup <id>`	Crea e registra un archivio locale	`--json` con input espliciti per un output di configurazione strutturato
`openspec store register <path>`	Registra un archivio esistente	`--json` per un output di registrazione strutturato
`openspec store unregister <id>`	Dimentica la registrazione di un archivio locale	`--json` per un output di pulizia strutturato
`openspec store remove <id>`	Elimina la cartella di un archivio locale registrato	`--yes --json` per l'eliminazione non interattiva
`openspec store list`	Esplora gli archivi registrati	`--json` per le registrazioni strutturate
`openspec store doctor`	Verifica la configurazione dell'archivio locale	`--json` per la diagnostica strutturata
`openspec new change <id>`	Crea lo scheletro di una modifica locale al repository	`--json`, oltre a `--store <id>` per utilizzare un archivio registrato come radice OpenSpec
`openspec workset create [name]`	Composizione di una vista di lavoro personale	`--member <path> --json` per la composizione non interattiva
`openspec workset list`	Esplora i workset salvati	`--json` per le viste strutturate
`openspec workset remove <name>`	Elimina una vista salvata	`--yes --json` per la rimozione non interattiva

Opzioni Globali

Queste opzioni funzionano con tutti i comandi:

Opzione	Descrizione
`--version`, `-V`	Mostra il numero di versione
`--no-color`	Disabilita l'output colorato
`--help`, `-h`	Visualizza la guida per il comando

Comandi di Configurazione

`openspec init`

Inizializza OpenSpec nel tuo progetto. Crea la struttura delle cartelle e configura le integrazioni con gli strumenti AI.

Il comportamento predefinito utilizza le impostazioni globali predefinite: profilo core, consegna both, flussi di lavoro propose, explore, apply, update, sync, archive.

openspec init [path] [options]

Usa --language <language> per aggiungere un'istruzione linguistica alla configurazione openspec/config.yaml di un nuovo progetto. Per un progetto esistente, modifica il campo context della configurazione affinché OpenSpec non sovrascriva mai le indicazioni specifiche del progetto.

Argomenti:

Argomento	Obbligatorio	Descrizione
`path`	No	Directory di destinazione (predefinita: directory corrente)

Opzioni:

Opzione	Descrizione
`--tools <list>`	Configura gli strumenti AI in modo non interattivo. Usa `all`, `none` o un elenco separato da virgole
`--language <language>`	Scrivi gli artifact in questa lingua quando si crea una nuova configurazione
`--force`	Pulizia automatica dei file legacy senza richiedere conferma
`--profile <profile>`	Sovrascrive il profilo globale per questa esecuzione di inizializzazione (`core` o `custom`)
`--no-animation`	Mostra uno schermo di benvenuto statico invece di quello animato
`--copilot-cloud`	Configura i file dell'agent di codifica cloud di GitHub Copilot senza richiedere conferma
`--no-copilot-cloud`	Salta i file dell'agent di codifica cloud di GitHub Copilot senza richiedere conferma

--profile custom utilizza qualsiasi flusso di lavoro attualmente selezionato nella configurazione globale (openspec config profile).

L'animazione di benvenuto viene inoltre saltata quando la variabile di ambiente OPENSPEC_NO_ANIMATION è impostata (qualsiasi valore, incluso vuoto), quando NO_COLOR è impostato su un valore non vuoto o quando è abilitata la preferenza del sistema operativo per la riduzione del movimento (macOS Riduci Movimento, animazioni GNOME disabilitate).

ID degli strumenti supportati (--tools) — windsurf è accettato anche come alias per 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

Questo elenco riflette AI_TOOLS in src/core/config.ts. Vedi Strumenti Supportati per i percorsi delle competenze e dei comandi di ogni strumento.

Esempi:

bash

# Inizializzazione interattiva
openspec init

# Inizializzazione in una directory specifica
openspec init ./my-project

# Non interattivo: configura per Claude e Cursor
openspec init --tools claude,cursor

# Non interattivo: configura le competenze globali MiniMax Code
openspec init --tools minimax-code

# Configura per tutti gli strumenti supportati
openspec init --tools all

# Sovrascrivi il profilo per questa esecuzione
openspec init --profile core

# Salta le richieste e pulisci automaticamente i file legacy
openspec init --force

Cosa crea:

openspec/
├── specs/              # Le tue specifiche (fonte di verità)
├── changes/            # Modifiche proposte
└── config.yaml         # Configurazione del progetto

.claude/skills/         # Competenze Claude Code (se claude selezionato)
.cursor/skills/         # Competenze Cursor (se cursor selezionato)
.cursor/commands/       # Comandi OPSX Cursor (se la consegna include i comandi)
.agents/skills/         # Competenze condivise per strumenti compatibili con AGENTS.md (se agents selezionato)
... (altre configurazioni degli strumenti)

`openspec update`

Aggiorna i file di istruzione di OpenSpec dopo l'aggiornamento della CLI. Rigenera i file di configurazione degli strumenti AI utilizzando il profilo globale corrente, i flussi di lavoro selezionati e la modalità di consegna.

openspec update [path] [options]

Argomenti:

Argomento	Obbligatorio	Descrizione
`path`	No	Directory di destinazione (predefinita: directory corrente)

Opzioni:

Opzione	Descrizione
`--force`	Forza l'aggiornamento anche quando i file sono aggiornati

Esempio:

bash

# Aggiorna i file di istruzione dopo l'aggiornamento npm
npm install -g @fission-ai/openspec@latest
openspec update

Aggiorna prima il pacchetto. I file di istruzione vengono generati dalla CLI installata, quindi eseguire openspec update contro un'installazione obsoleta segnala che tutto è aggiornato senza aggiungere i flussi di lavoro forniti dalle versioni più recenti.

Per rendere ciò visibile, openspec update interroga il registro npm per verificare se è stata pubblicata una CLI più recente. Quando la tua versione è indietro, offre di effettuare l'aggiornamento:

text

È disponibile una versione più recente della CLI OpenSpec (v1.6.0 → v1.7.0).
  Esecuzione da: /usr/local/lib/node_modules/@fission-ai/openspec
? Aggiornare a v1.7.0 ora? (Y/n)

Rispondi sì ed eseguirà npm install -g @fission-ai/openspec@latest, quindi riavvierà l'aggiornamento con la nuova CLI in modo che i nuovi flussi di lavoro vengano applicati nello stesso comando. Conferma l'aggiornamento chiedendo alla binario installato la propria versione piuttosto che fidarsi del codice di uscita di npm, quindi se un'altra installazione precedente sul tuo PATH sta ancora rispondendo, ti informa invece di dichiarare il successo. Rispondi no e stamperà il comando e aggiornerà con la CLI che hai. Ctrl-C interrompe il comando.

L'offerta appare solo in un terminale interattivo e solo quando npm possiede l'installazione — l'unico caso in cui npm install -g risolve effettivamente il problema. Tutto il resto riceve il comando corrispondente al metodo di installazione utilizzato:

Come è installato OpenSpec	Cosa ottieni
Installazione npm globale	Il prompt e l'esecuzione dell'aggiornamento per te — in un terminale interattivo; l'output in pipe ottiene invece il comando stampato
Installazione globale pnpm, bun, yarn o volta	Il comando specifico di quel gestore: `pnpm add -g …@latest`, `bun add -g …@latest`, `yarn global add …@latest` o `volta install …@latest`
Una dipendenza del progetto	Una nota per aggiornare la dipendenza, poiché il suo package manager possiede il lockfile
Una cache `npx` / `dlx`	`npx @fission-ai/openspec@latest update` — quel comando è l'aggiornamento, quindi non c'è un secondo passaggio
Un clone git	Nulla — la tua versione è quella indicata dal branch

Ogni volta che viene stampato qualcosa, indica la directory da cui è stata caricata la CLI in esecuzione — il punto da controllare quando hai effettuato l'aggiornamento ma uno shim obsoleto possiede ancora il tuo PATH.

Interroga il registro in npm_config_registry quando npm lo esporta, e https://registry.npmjs.org altrimenti. Non viene letto alcun file .npmrc: lasciare che i contenuti del file scelgano dove inviare una richiesta in uscita è un flusso da evitare, e il .npmrc di un progetto viaggia insieme al repository. Su uno specchio privato, esporta npm_config_registry — oppure imposta OPENSPEC_NO_UPDATE_CHECK per saltare completamente il controllo. Il controllo viene saltato quando CI è impostato su qualsiasi valore diverso da un valore di spegnimento esplicito (false, 0, no, off o vuoto), sotto NODE_ENV=test e ogni volta che è impostato OPENSPEC_NO_UPDATE_CHECK (qualsiasi valore), DO_NOT_TRACK=1 o OPENSPEC_TELEMETRY=0. Viene eseguito prima dell'aggiornamento e può ritardarlo di al massimo 1,5 secondi — rinuncia dopo tale periodo anche quando la rete perde pacchetti in silenzio e rimane silenzioso quando il registro non è raggiungibile.

Come viene deciso "aggiornato": i file delle competenze registrano la versione che li ha generati, quindi OpenSpec confronta tale versione con la CLI installata. I file dei comandi non hanno un contrassegno di versione, quindi per uno strumento che ha comandi ma nessuna competenza (consegna commands), OpenSpec confronta i contenuti del file con ciò che verrebbe generato ora — le modifiche a questi file contano come drift e vengono sovrascritte. Con la consegna skills o both, viene controllata solo la versione registrata, quindi un file modificato a mano la cui versione corrisponde ancora viene lasciato intatto; usa --force per riscriverlo. In entrambi i casi, i file generati sono di proprietà di OpenSpec: tieni le tue istruzioni altrove.

Stores (repository OpenSpec autonomi)

Beta. Gli stores e le funzionalità costruite su di essi (riferimenti, contesto di lavoro, worksets) sono nuovi; i nomi dei comandi, le opzioni, i formati dei file e l'output JSON potrebbero cambiare tra le versioni. Per la panoramica orientata ai problemi, consulta la guida agli stores.

Uno store è un repository OpenSpec autonomo registrato su questa macchina — ad esempio un repository di pianificazione o un repository di contratti. Registrare uno store consente ai comandi normali (list, show, status, validate, new change, archive, ...) di operare al suo interno da qualsiasi posizione passando --store <id>.

`openspec store setup`

Crea e registra uno store locale. Senza argomenti in un terminale, OpenSpec guida l'utente attraverso la configurazione. Gli agenti e gli script devono passare input espliciti e usare --json.

bash

openspec store setup [id] [options]

Opzioni:

Opzione	Descrizione
`--path <path>`	Cartella in cui lo store deve risiedere (ad esempio `~/openspec/<id>`)
`--remote <url>`	Registra il remote canonico nel `store.yaml` del nuovo store
`--init-git`	Inizializza un repository Git con un commit iniziale (predefinito)
`--no-init-git`	Salta ogni azione Git: nessuna inizializzazione, nessun commit iniziale
`--json`	Output JSON

Le esecuzioni non interattive (--json, script, agenti) devono passare sia l'id dello store sia --path. In un terminale interattivo, la configurazione chiede la posizione con un suggerimento modificabile in un luogo visibile e di proprietà dell'utente (ad esempio ~/openspec/<id>); non usa mai come predefinito il directory dati gestito da OpenSpec.

Esempi:

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 cartella store locale esistente. Durante la beta degli stores, una root può essere registrata prima che esistano modifiche, che le specifiche siano state applicate o che le modifiche siano state archiviate; in tal caso openspec/changes/, openspec/specs/ e openspec/changes/archive/ potrebbero essere assenti fino a quando i comandi normali non li creano. Un repository solo di configurazione che dichiara store: <id> rimane un puntatore a un altro store e non viene registrato come root di uno store a meno che quel puntatore non venga rimosso.

bash

openspec store register [path] [options]

Opzioni:

Opzione	Descrizione
`--id <id>`	Id dello store; predefinito dai metadati dello store o dal nome della cartella
`--yes`	Conferma la creazione dei metadati di identità dello store per una root OpenSpec valida
`--json`	Output JSON

`openspec store unregister`

Dimentica una registrazione locale di uno store senza eliminare i file.

bash

openspec store unregister <id> [--json]

Usa questo comando quando uno store è stato spostato, clonato altrove o non deve più essere mostrato da OpenSpec su questa macchina.

`openspec store remove`

Dimentica una registrazione locale di uno store ed elimina la sua cartella locale.

bash

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

remove mostra la cartella esatta prima di eliminarla in un terminale interattivo. Agenti, script e chiamanti JSON devono passare --yes per confermare l'eliminazione. OpenSpec rifiuta di eliminare una cartella che non contiene metadati dello store corrispondenti.

`openspec store list`

Elenca gli stores registrati localmente.

bash

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

`openspec store doctor`

Verifica la registrazione locale, i metadati e la presenza di Git degli stores.

bash

openspec store doctor [id] [--json]

Doctor è solo diagnostico; riporta root mancanti, discrepanze nei metadati e stato del registro locale non valido senza modificare lo store.

Riferire agli stores da un progetto

Un repository di progetto può dichiarare quali stores il suo lavoro utilizza in openspec/config.yaml:

yaml

schema: spec-driven
references:
  - team-context

Da quel momento, l'output di openspec instructions in quel repository (sia le superfici per-artefatto sia apply, modalità JSON e umana) include un indice delle specifiche di ogni store referenziato — id delle specifiche, un riepilogo in una riga dalla sezione Purpose di ciascuna specifica e il comando di recupero (openspec show <spec-id> --type spec --store <id>). L'indice viene costruito in tempo reale dal checkout registrato ad ogni esecuzione; il contenuto delle specifiche non viene mai copiato nell'output.

I riferimenti sono contesto solo di lettura. Non cambiano mai dove operano i comandi: il lavoro rimane nella root del repository stesso e la scrittura in uno store referenziato rimane un'azione esplicita --store. Un riferimento che non può essere risolto (ad esempio, uno store non registrato su questa macchina) degrada a un avviso nell'indice con la correzione esatta e le istruzioni vengono comunque generate. openspec doctor riporta lo stato dei riferimenti in un unico punto.

Registrare da dove è clonato uno store

Uno store può registrare la sua fonte di clonazione canonica nel suo file di identità commitato, in modo che l'onboarding non si blocchi mai su "registra lo store":

bash

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

Il remote viene inserito in .openspec-store/store.yaml all'interno del commit iniziale, in modo che ogni clone nasca sapendolo. Per uno store esistente, modifica store.yaml manualmente e committa. store doctor mostra l'origin remoto registrato (e l'origin Git osservato del checkout); la guida di condivisione di setup/register lo cita; e register registra l'origin del checkout nel registro locale della macchina.

Una dichiarazione di riferimento può includere anche la fonte di clonazione, in modo che un collega che non ha ancora lo store riceva una correzione completa e copiabile (git clone <remote> <path> && openspec store register <path> --id <id>):

yaml

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

Registrare un remote non è sincronizzazione: OpenSpec non clona, non esegue pull né push di propria iniziativa.

Dichiarare uno store predefinito

Un repository la cui pianificazione è completamente esternalizzata — senza openspec/specs/ o openspec/changes/ locali — può dichiarare il proprio store una sola volta invece di passare --store a ogni comando:

yaml

# openspec/config.yaml (l'unico file sotto openspec/)
store: team-context

I comandi normali vengono quindi risolti automaticamente allo store dichiarato; la banner della root e il blocco JSON root riportano source: "declared" con l'id dello store, e gli hint stampati includono ancora --store <id>. La dichiarazione è un fallback, mai un override: --store esplicito vince sempre e una directory con cartelle di pianificazione reali ignora il puntatore (con un avviso). Per convertire un repository puntatore in una root OpenSpec locale, rimuovi la riga store: ed esegui openspec init — init rifiuta di creare la struttura mentre la dichiarazione è presente.

Una variante a livello di macchina copre tutti i repository contemporaneamente: openspec config set defaultStore <id> (vedi Configurazione). Viene consultata solo dopo che --store, una root locale e un puntatore di progetto hanno tutti fallito la risoluzione; la banner della root e il blocco JSON root riportano quindi source: "global_default".

Doctor (salute delle relazioni)

Una sola domanda di sola lettura, un unico luogo: la root di OpenSpec è in buono stato e gli store a cui fa riferimento sono disponibili su questa macchina?

bash

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

Il report suddivide la salute della root, la salute dei metadati dello store (inclusa una nota quando il remote registrato e l’origine del checkout divergono, e una nota quando il checkout dello store è rimasto indietro rispetto al suo branch di upstream di cui ha fatto l’ultimo fetch) e la salute dei riferimenti (le stesse istruzioni diagnostiche vengono mostrate, con correzioni clone per i riferimenti non risolti). Qualsiasi anomalia, indipendentemente dalla gravità, produce un exit code 0 — gli agent leggono gli array status; solo i fallimenti dei comandi (nessuna root, store sconosciuto) producono exit code 1. Doctor non clona, sincronizza o ripara mai. Per ottenere l’insieme assemblato stesso anziché il suo stato di salute, usa openspec context.

Contesto di lavoro (l’insieme assemblato)

Tutto ciò a cui questo lavoro si relaziona tramite le dichiarazioni OpenSpec, in un unico insieme di lavoro: la root di OpenSpec e gli store a cui fa riferimento.

bash

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

Il riepilogo JSON è pronto per essere consumato dagli agent (ogni store referenziato disponibile riporta la sua ricetta di fetch; i membri non risolti riportano le stesse istruzioni di correzione e la visualizzazione di doctor). --code-workspace scrive inoltre un file workspace di VS Code contenente la root più gli store referenziati disponibili (cartelle ref:<id>) — l’unica scrittura che questo comando esegue, rifiutata senza --force se il file esiste. I membri non disponibili vengono segnalati, mai ipotizzati.

“Contesto di lavoro” è l’insieme assemblato; il campo context: in openspec/config.yaml è lo sfondo del progetto iniettato nelle istruzioni — due cose diverse. openspec doctor risponde se l’insieme è sano; openspec context risponde cosa è l’insieme.

Workset personali

Beta. I workset fanno parte della nuova superficie beta; comandi, flag e formati di file potrebbero cambiare tra una release e l’altra. Per una guida dettagliata, consulta la guida agli store.

Un workset è una vista personale e nominata delle cartelle su cui lavori insieme — una root di pianificazione più tutto ciò che scegli — conservata sulla tua macchina e riaperta per nome nel tuo strumento. È puramente locale: mai committato, mai condiviso, mai derivato da dichiarazioni e la sua rimozione non tocca mai le cartelle membro.

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 esegue un breve flusso guidato (oppure accetta flag --member in modo non interattivo; il primo membro è quello primario — le sessioni partono da lì). open avvia lo strumento scelto: gli editor (VS Code, Cursor) aprono una finestra con ogni membro e restituiscono; gli agent CLI (Claude Code, codex) prendono il controllo di questo terminale come sessione con ogni membro collegato e nessun prompt pre-riempito, terminando quando esci. Una cartella membro mancante al momento dell’apertura viene saltata con una nota; il resto si apre. La preferenza dello strumento salvata è sovrascrivibile per ogni apertura con --tool.

Supportare un nuovo strumento è configurazione, non codice. Ogni strumento appartiene a uno dei due stili di lancio — workspace-file (lanciato con il file .code-workspace generato) o attach-dirs (un flag di attach per ogni membro) — e la chiave openers nel config.json globale (aprilo con openspec config edit) aggiunge strumenti o modifica quelli predefiniti per campo:

json

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

Tutto lo stato dei workset risiede sotto la cartella worksets/ nella directory dati globale (le viste salvate più i file generati <name>.code-workspace, rigenerati a ogni apertura); eliminare quella cartella rimuove ogni traccia.

Comandi di navigazione

`openspec list`

Elenca le modifiche o le specifiche nel tuo progetto.

openspec list [options]

Opzioni:

Opzione	Descrizione
`--specs`	Elenca le specifiche invece delle modifiche
`--changes`	Elenca le modifiche (predefinito)
`--sort <order>`	Ordina per `recent` (predefinito) o `name`
`--json`	Output in formato JSON

Esempi:

bash

# Elenca tutte le modifiche attive
openspec list

# Elenca tutte le specifiche
openspec list --specs

# Output JSON per script
openspec list --json

Output (testo):

Changes:
  add-dark-mode     No tasks      just now

`openspec view`

Visualizza un dashboard interattivo per esplorare specifiche e modifiche.

openspec view

Apre un’interfaccia a terminale per navigare le specifiche e le modifiche del progetto.

`openspec show`

Mostra i dettagli di una modifica o specifica.

openspec show [item-name] [options]

Argomenti:

Argomento	Obbligatorio	Descrizione
`item-name`	No	Nome della modifica o della specifica (richiede se omesso)

Opzioni:

Opzione	Descrizione
`--type <type>`	Specifica il tipo: `change` o `spec` (rilevato automaticamente se non ambiguo)
`--json`	Output in formato JSON
`--no-interactive`	Disabilita i prompt

Opzioni specifiche per le modifiche:

Opzione	Descrizione
`--deltas-only`	Mostra solo le specifiche delta (modalità JSON)

Opzioni specifiche per le specifiche:

Opzione	Descrizione
`--requirements`	Mostra solo i requisiti, escludi gli scenari (modalità JSON)
`--no-scenarios`	Escludi il contenuto degli scenari (modalità JSON)
`-r, --requirement <id>`	Mostra un requisito specifico per indice a base 1 (modalità JSON)

Esempi:

bash

# Selezione interattiva
openspec show

# Mostra una modifica specifica
openspec show add-dark-mode

# Mostra una specifica specifica
openspec show auth --type spec

# Output JSON per parsing
openspec show add-dark-mode --json

Comandi di validazione

`openspec validate`

Valida le modifiche e le specifiche per individuare problemi strutturali e controlla i requisiti MODIFIED di una modifica rispetto alle specifiche principali che andrebbero a sostituire.

openspec validate [item-name] [options]

Una modifica con zero delta di specifiche non supera la validazione, a meno che il suo .openspec.yaml non dichiari skip_specs: true (per refactoring puri, lavoro su tooling o documentazione — vedere Recipe 5).

Argomenti:

Argomento	Obbligatorio	Descrizione
`item-name`	No	Elemento specifico da validare (richiede input se omesso)

Opzioni:

Opzione	Descrizione
`--all`	Valida tutte le modifiche e le specifiche
`--changes`	Valida tutte le modifiche
`--specs`	Valida tutte le specifiche
`--archived`	Valida che le modifiche archiviate abbiano tutti i task completati (per linting pre-commit)
`--type <type>`	Specifica il tipo quando il nome è ambiguo: `change` o `spec`
`--strict`	Abilita la modalità di validazione rigorosa
`--json`	Output in formato JSON
`--concurrency <n>`	Massimo numero di validazioni parallele (predefinito: 6, oppure variabile d'ambiente `OPENSPEC_CONCURRENCY`)
`--no-interactive`	Disabilita i prompt interattivi

--archived ha un ambito proprio: non valida i delta di specifiche (già applicati al momento dell'archiviazione), ma verifica che ogni modifica sotto changes/archive/ abbia tutte le caselle di tasks.md spuntate, terminando con codice non zero se qualcuna è deselezionata. Questo individua modifiche archiviate con lavoro incompleto — utile in un hook pre-commit.

Esempi:

bash

# Validazione interattiva
openspec validate

# Valida una modifica specifica
openspec validate add-dark-mode

# Valida tutte le modifiche
openspec validate --changes

# Valida tutto con output JSON (per CI/script)
openspec validate --all --json

# Validazione rigorosa con parallelismo aumentato
openspec validate --all --strict --concurrency 12

# Fallisce se una modifica archiviata ha ancora task non spuntati
openspec validate --archived

Output (testo):

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

1 warning found

Output (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
  }
}

Comandi del ciclo di vita

`openspec archive`

Archivia una modifica completata e fonde i delta di specifiche nelle specifiche principali.

openspec archive [change-name] [options]

Argomenti:

Argomento	Obbligatorio	Descrizione
`change-name`	No	Modifica da archiviare (richiede input se omesso; obbligatorio quando nulla può rispondere al prompt)

Opzioni:

Opzione	Descrizione
`-y, --yes`	Salta i prompt di conferma. Obbligatorio quando nulla può rispondere — un agente AI, un job CI o qualsiasi esecuzione con stdin chiuso
`--skip-specs`	Salta gli aggiornamenti delle specifiche per un'archiviazione singola. Una modifica che permanentemente non ha delta di specifiche dovrebbe dichiarare `skip_specs: true` nel suo `.openspec.yaml` — si archivia senza flag
`--no-validate`	Salta la validazione (richiede conferma). Disabilita anche il ritiro delle capacità — senza un verdetto del validatore, nulla viene ritirato

Esempi:

bash

# Archiviazione interattiva (chiede quale modifica, poi conferma)
openspec archive

# Archivia una modifica specifica
openspec archive add-dark-mode

# Archivia senza prompt (agenti, CI, script)
openspec archive add-dark-mode --yes

# Archivia una modifica di tooling che non influisce sulle specifiche
openspec archive update-ci-config --skip-specs

Ritirare una capacità: Aggiungi il marcatore di ritiro ai metadati della modifica:

yaml

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

Poi archivia la modifica normalmente:

bash

openspec archive retire-legacy --yes

Quando la modifica rimuove l'ultimo requisito della capacità, OpenSpec elimina il relativo spec.md attivo. Gli altri delta di capacità nella stessa modifica aggiornano comunque le loro specifiche principali. Senza il marcatore, l'archiviazione si ferma prima di modificare qualsiasi file e ti chiede di aggiungerlo.

Cosa fa:

Valida l'archiviazione (a meno di --no-validate)
Richiede conferma (a meno di --yes)
Prende in carico la destinazione di archiviazione prima di modificare qualsiasi specifica principale
Valida e fonde i delta di specifiche attivi in openspec/specs/ — una capacità il cui ultimo requisito viene rimosso dalla modifica viene ritirata e il suo file di specifica eliminato, ma solo quando il .openspec.yaml della modifica dichiara retire_capabilities: true accanto al suo schema:
Sposta la cartella della modifica in openspec/changes/archive/YYYY-MM-DD-<name>/
Se una mutazione delle specifiche o lo spostamento finale fallisce prima che l'archiviazione completa sia garantita, ripristina le specifiche e lascia o riporta la modifica al suo percorso attivo
Se una copia di fallback verificata viene completata ma la pulizia della fonte staged fallisce, conserva l'archivio completo e lo stato delle specifiche commit per il recupero

Senza terminale: un agente AI, un job CI o qualsiasi esecuzione con stdin chiuso non può rispondere al passo 2, quindi l'archiviazione si ferma prima di toccare qualsiasi cosa, esce con codice 1 e indica il comando da rieseguire — openspec archive <name> --yes, con tutti gli altri flag che hai passato. Passa --yes (e il nome della modifica) in anticipo per evitare il round trip.

Comandi del Flusso di Lavoro

Questi comandi supportano il flusso di lavoro OPSX guidato dagli artifact. Sono utili sia per gli esseri umani che controllano lo stato di avanzamento sia per gli agenti che determinano i passi successivi.

`openspec new change`

Crea una directory di change e metadati opzionali con check-in nella root OpenSpec risolta.

bash

openspec new change <name> [options]

I nomi delle change devono usare kebab-case minuscolo: lettere minuscole, numeri e trattini singoli. Non possono contenere spazi, underscore, lettere maiuscole, trattini consecutivi o trattini iniziali/finali. Un numero iniziale è consentito, quindi puoi anteporre nomi per ordinare o livellare le change, ad esempio 100-add-feature o 00001-add-auth.

Opzioni:

Opzione	Descrizione
`--description <text>`	Descrizione da aggiungere a `index.md`
`--goal <text>`	Metadati opzionali sull'obiettivo da memorizzare con la change
`--schema <name>`	Schema del flusso di lavoro da utilizzare
`--store <id>`	ID dello store da utilizzare come root OpenSpec (uno store è un repo OpenSpec autonomo che hai registrato)
`--json`	Output in JSON

Esempi:

bash

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

`openspec status`

Mostra lo stato di completamento degli artifact per una change.

openspec status [options]

Opzioni:

Opzione	Descrizione
`--change <id>`	Nome della change (richiesto tramite prompt se omesso)
`--schema <name>`	Override dello schema (rilevato automaticamente dalla configurazione della change)
`--json`	Output in JSON

Esempi:

bash

# Controllo interattivo dello stato
openspec status

# Stato per una change specifica
openspec status --change add-dark-mode

# JSON per uso da parte degli agenti
openspec status --change add-dark-mode --json

Output (testo):

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

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

Una change che dichiara skip_specs: true mostra la sua fase specs come [~] specs (skipped: change declares skip_specs) e la esclude dal conteggio dello stato di avanzamento.

Output (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 indica se esiste ogni artifact di pianificazione non saltato; gli artifact saltati contano come soddisfatti senza essere creati. Non indica se le attività di implementazione sono complete. isComplete è mantenuto come alias di compatibilità con lo stesso valore.

Gli artifact sono elencati in ordine di dipendenza — una dipendenza non compare mai dopo qualcosa che la richiede — e gli artifact che diventano pronti nello stesso momento (specs e design di spec-driven richiedono entrambi solo proposal) mantengono l'ordine in cui lo schema li dichiara, non un ordine alfabetico. Quindi la prima voce ready è l'artifact da scrivere successivamente.

`openspec instructions`

Ottieni istruzioni arricchite per creare un artifact o applicare attività. Utilizzato dagli agenti AI per comprendere cosa creare dopo.

openspec instructions [artifact] [options]

Argomenti:

Argomento	Obbligatorio	Descrizione
`artifact`	No	ID dell'artifact o superficie di input del flusso di lavoro: `apply` o `archive`

Opzioni:

Opzione	Descrizione
`--change <id>`	Nome della change (obbligatorio in modalità non interattiva)
`--schema <name>`	Override dello schema
`--json`	Output in JSON

Casi particolari: Usa apply per ottenere istruzioni sull'implementazione delle attività. Usa archive per recuperare gli input di archivio correnti e di sola lettura (context e operationGuidance) per una change valida; non archivia né modifica nulla.

Esempi:

bash

# Ottieni istruzioni per il prossimo artifact
openspec instructions --change add-dark-mode

# Ottieni istruzioni per un artifact specifico
openspec instructions design --change add-dark-mode

# Ottieni istruzioni di apply/implementazione
openspec instructions apply --change add-dark-mode

# Ottieni gli input correnti delle operazioni di archivio senza archiviare
openspec instructions archive --change add-dark-mode --json

# JSON per il consumo da parte degli agenti
openspec instructions design --change add-dark-mode --json

L'output include:

Contenuto del template per l'artifact
Contesto del progetto dalla configurazione
Contenuto dagli artifact di dipendenza
Regole per singolo artifact dalla configurazione
Contesto corrente del progetto e guida operativa corrispondente per apply/archive

Gli input delle operazioni vengono letti dal repo risolto o dallo store selezionato a ogni invocazione. Il contesto del progetto è un input obbligatorio a livello di prompt: gli agenti lo leggono e applicano i fatti, le convenzioni e i vincoli di progetto rilevanti. La guida operativa è una consulenza additiva opzionale: gli agenti considerano ogni voce e seguono solo le voci che sono applicabili e compatibili con il flusso di lavoro integrato. Entrambi i campi restano separati dalle scelte esplicite dell'utente, dallo stato controllato dalla CLI, dalle istruzioni integrate e dalle regole degli artifact. I conflitti di contesto vengono segnalati; le guide in conflitto o non applicabili non vengono seguite e il motivo viene spiegato. Questi sono contratti comportamentali per gli agenti generati, non controlli CLI applicabili. instructions archive restituisce solo la change selezionata, gli input opzionali e i metadati della root; non include il flusso di lavoro di archivio statico.

Per un artifact saltato tramite skip_specs: true, l'output è solo un avviso (il JSON aggiunge i campi skipped/warning) — l'artifact non deve essere creato.

`openspec templates`

Mostra i percorsi dei template risolti per tutti gli artifact di uno schema.

openspec templates [options]

Opzioni:

Opzione	Descrizione
`--schema <name>`	Schema da ispezionare (predefinito: `spec-driven`)
`--json`	Output in JSON

Esempi:

bash

# Mostra i percorsi dei template per lo schema predefinito
openspec templates

# Mostra i template per uno schema personalizzato
openspec templates --schema my-workflow

# JSON per uso programmatico
openspec templates --json

Output (testo):

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`

Elenca gli schemi di flusso di lavoro disponibili con le loro descrizioni e i flussi di artifact.

openspec schemas [options]

Opzioni:

Opzione	Descrizione
`--json`	Output in JSON
`--store <id>`	Usa uno store registrato come root OpenSpec

Esempio:

bash

openspec schemas

Output:

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

Comandi per gli schemi

Comandi per creare e gestire schemi di flusso di lavoro personalizzati.

`openspec schema init`

Crea uno schema locale al progetto.

openspec schema init <name> [options]

Argomenti:

Argomento	Obbligatorio	Descrizione
`name`	Sì	Nome dello schema (kebab-case)

Opzioni:

Opzione	Descrizione
`--description <text>`	Descrizione dello schema
`--artifacts <list>`	ID degli artifact separati da virgola (default: `proposal,specs,design,tasks`)
`--default`	Imposta come schema predefinito del progetto
`--no-default`	Non chiedere se impostare come predefinito
`--force`	Sovrascrive lo schema esistente
`--json`	Output in formato JSON

Esempi:

bash

# Creazione interattiva dello schema
openspec schema init research-first

# Non interattivo con artifact specifici
openspec schema init rapid \
  --description "Flusso di iterazione rapida" \
  --artifacts "proposal,tasks" \
  --default

Cosa crea:

openspec/schemas/<name>/
├── schema.yaml           # Definizione dello schema
└── templates/
    ├── proposal.md       # Template per ogni artifact
    ├── specs.md
    ├── design.md
    └── tasks.md

`openspec schema fork`

Copia uno schema esistente nel tuo progetto per personalizzarlo.

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

Argomenti:

Argomento	Obbligatorio	Descrizione
`source`	Sì	Schema da copiare
`name`	No	Nuovo nome dello schema (default: `<source>-custom`)

Opzioni:

Opzione	Descrizione
`--force`	Sovrascrive la destinazione esistente
`--json`	Output in formato JSON

Esempio:

bash

# Fork dello schema spec-driven integrato
openspec schema fork spec-driven my-workflow

`openspec schema validate`

Convalida la struttura e i template di uno schema.

openspec schema validate [name] [options]

Argomenti:

Argomento	Obbligatorio	Descrizione
`name`	No	Schema da convalidare (convalida tutti se omesso)

Opzioni:

Opzione	Descrizione
`--verbose`	Mostra i passaggi dettagliati della convalida
`--json`	Output in formato JSON

Esempio:

bash

# Convalida uno schema specifico
openspec schema validate my-workflow

# Convalida tutti gli schemi
openspec schema validate

`openspec schema which`

Mostra da dove viene risolto uno schema (utile per il debug della precedenza).

openspec schema which [name] [options]

Argomenti:

Argomento	Obbligatorio	Descrizione
`name`	No	Nome dello schema

Opzioni:

Opzione	Descrizione
`--all`	Elenca tutti gli schemi con le relative origini
`--json`	Output in formato JSON

Esempio:

bash

# Verifica da dove proviene uno schema
openspec schema which spec-driven

Output:

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

Precedenza degli schemi:

Progetto: openspec/schemas/<name>/
Utente: ~/.local/share/openspec/schemas/<name>/
Pacchetto: Schemi integrati

Comandi di configurazione

`openspec config`

Visualizza e modifica la configurazione globale di OpenSpec.

openspec config <subcommand> [options]

Sottomandi:

Sottomando	Descrizione
`path`	Mostra la posizione del file di configurazione
`list`	Mostra tutte le impostazioni correnti
`get <key>`	Ottiene un valore specifico
`set <key> <value>`	Imposta un valore
`unset <key>`	Rimuove una chiave
`reset`	Reimposta ai valori predefiniti
`edit`	Apre nell'editor `$EDITOR`
`profile [preset]`	Configura il profilo del flusso di lavoro in modo interattivo o tramite preset

Esempi:

bash

# Mostra il percorso del file di configurazione
openspec config path

# Elencare tutte le impostazioni
openspec config list

# Ottenere un valore specifico
openspec config get telemetry.enabled

# Impostare un valore (disabilita la telemetria sull'utilizzo anonimo)
openspec config set telemetry.enabled false

# Impostare esplicitamente un valore stringa
openspec config set user.name "My Name" --string

# Rimuovere una configurazione personalizzata
openspec config unset user.name

# Impostare un archivio predefinito a livello di macchina (radice di fallback quando non ci sono --store,
# radice locale o archivio del progetto: il puntatore si risolve)
openspec config set defaultStore team-plans

# Reimpostare tutta la configurazione
openspec config reset --all --yes

# Modificare la configurazione nell'editor
openspec config edit

# Configurare il profilo con un wizard basato sulle azioni
openspec config profile

# Preset rapido: cambia i flussi di lavoro in core (mantiene la modalità di consegna)
openspec config profile core

Disattivazione della telemetria: telemetry.enabled è attivo per impostazione predefinita quando non è impostato (modello di disattivazione). Impostalo su false per disabilitare le statistiche sull'utilizzo anonimo e il controllo della versione di openspec update. Le variabili d'ambiente hanno la precedenza sulla configurazione: OPENSPEC_TELEMETRY=0, DO_NOT_TRACK=1, e un valore truthy di CI (es. true/1/yes) disabilitano sempre la telemetria indipendentemente dal valore di configurazione.

openspec config profile inizia con un riepilogo dello stato corrente, quindi ti permette di scegliere:

Cambia consegna + flussi di lavoro
Cambia solo la consegna
Cambia solo i flussi di lavoro
Mantieni le impostazioni correnti (esci)

Se mantieni le impostazioni correnti, non vengono scritte modifiche e non viene mostrato alcun prompt di aggiornamento. Se non ci sono modifiche alla configurazione ma i file del progetto corrente non sono sincronizzati con il tuo profilo/delivery globale, OpenSpec mostrerà un avviso e suggerirà openspec update. Premendo Ctrl+C si annulla il flusso in modo pulito (nessun stack trace) ed esce con codice 130. Nella checklist dei flussi di lavoro, [x] significa che il flusso di lavoro è selezionato nella configurazione globale. Per applicare queste selezioni ai file del progetto, esegui openspec update (o scegli Apply changes to this project now? quando richiesto all'interno di un progetto).

Esempi interattivi:

bash

# Aggiornamento solo della consegna
openspec config profile
# scegli: Change delivery only
# scegli delivery: Skills only

# Aggiornamento solo dei flussi di lavoro
openspec config profile
# scegli: Change workflows only
# attiva/disattiva i flussi di lavoro nella checklist, poi conferma

Comandi utilità

`openspec feedback`

Invia feedback su OpenSpec. Crea un issue su GitHub.

openspec feedback <message> [options]

Argomenti:

Argomento	Obbligatorio	Descrizione
`message`	Sì	Riepilogo del feedback; il testo lungo viene abbreviato nel titolo dell'issue e preservato nel corpo

Opzioni:

Opzione	Descrizione
`--body <text>`	Dettagli aggiuntivi inclusi dopo il riepilogo

Requisiti: È necessario avere installato e autenticato GitHub CLI (gh).

Esempio:

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`

Gestisci i completamenti della shell per la CLI di OpenSpec.

openspec completion <subcommand> [shell]

Sottomandi:

Sottomando	Descrizione
`generate [shell]`	Output dello script di completamento su stdout
`install [shell]`	Installa il completamento per la tua shell
`uninstall [shell]`	Rimuove i completamenti installati

Shell supportate: bash, zsh, fish, powershell

Esempi:

bash

# Installa i completamenti (rileva automaticamente la shell)
openspec completion install

# Installa per una shell specifica
openspec completion install zsh

# Genera lo script per l'installazione manuale (bash)
openspec completion generate bash > ~/.bash_completion.d/openspec

# Disinstalla
openspec completion uninstall

Windows (PowerShell): Installa i completamenti per l'host PowerShell corrente:

powershell

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

$env:PROFILE indica a OpenSpec quale profilo configurare in questa sessione. L'installer crea le directory del profilo mancanti e aggiunge un blocco gestito che carica OpenSpecCompletion.ps1. Il ricaricamento del profilo abilita immediatamente i completamenti.

Per disinstallare dall'host corrente, esegui:

powershell

$env:PROFILE = $PROFILE
openspec completion uninstall powershell

Riavvia PowerShell dopo la disinstallazione per cancellare i completamenti dalla sessione corrente.

I completamenti sono opzionali. La CLI li menziona una sola volta, su stderr, la prima volta che esegui un comando in un terminale interattivo, e mai più — rimane silenzioso anche se hai già installato i completamenti. Imposta OPENSPEC_NO_COMPLETIONS=1 per sopprimere completamente questo suggerimento.

Codici di uscita

Codice	Significato
`0`	Successo
`1`	Errore (fallimento della convalida, file mancanti, ecc.)

Variabili d'ambiente

Variabile	Descrizione
`OPENSPEC_TELEMETRY`	Imposta su `0` per disabilitare la telemetria e il controllo della versione di `openspec update` (sovrascrive `telemetry.enabled` nella configurazione globale)
`DO_NOT_TRACK`	Imposta su `1` per disabilitare la telemetria e il controllo della versione di `openspec update` (segnale DNT standard; sovrascrive la configurazione)
`OPENSPEC_CONCURRENCY`	Concorrenza predefinita per la convalida batch (default: 6)
`EDITOR` o `VISUAL`	Editor per `openspec config edit`
`NO_COLOR`	Disabilita l'output colorato quando impostato
`OPENSPEC_NO_ANIMATION`	Disabilita l'animazione di benvenuto di `openspec init` quando impostato
`OPENSPEC_NO_COMPLETIONS`	Imposta su `1` per sopprimere il suggerimento una tantum sui completamenti della shell
`OPENSPEC_NO_UPDATE_CHECK`	Disabilita il controllo `openspec update` per una CLI pubblicata più recente quando impostato (qualsiasi valore, incluso vuoto). Viene saltato anche quando `CI` è impostato (a meno che non sia `false`/`0`/`no`/`off`) o `NODE_ENV=test`
`npm_config_registry`	Registro a cui chiede il controllo della versione di `openspec update`. Deve essere un URL `http(s)` altrimenti ritorna a `https://registry.npmjs.org`. Non viene letto alcun file `.npmrc`

Documentazione correlata

Commands - Comandi slash AI (/opsx:propose, /opsx:apply, ecc.)
Workflows - Pattern comuni e quando usare ciascun comando
Customization - Crea schemi e template personalizzati
Getting Started - Guida alla configurazione iniziale

Riferimento CLI ​

Riepilogo ​

Comandi Umani vs Agent ​

Comandi Solo Umani ​

Comandi Compatibili con Agent ​

Opzioni Globali ​

Comandi di Configurazione ​

openspec init ​

openspec update ​

Stores (repository OpenSpec autonomi) ​

openspec store setup ​

openspec store register ​

openspec store unregister ​

openspec store remove ​

openspec store list ​

openspec store doctor ​

Riferire agli stores da un progetto ​

Registrare da dove è clonato uno store ​

Dichiarare uno store predefinito ​

Doctor (salute delle relazioni) ​

Contesto di lavoro (l’insieme assemblato) ​

Workset personali ​

Comandi di navigazione ​

openspec list ​

openspec view ​

openspec show ​

Comandi di validazione ​

openspec validate ​

Comandi del ciclo di vita ​

openspec archive ​

Comandi del Flusso di Lavoro ​

openspec new change ​

openspec status ​

openspec instructions ​

openspec templates ​

openspec schemas ​

Comandi per gli schemi ​

openspec schema init ​

openspec schema fork ​

openspec schema validate ​

openspec schema which ​

Comandi di configurazione ​

openspec config ​

Comandi utilità ​

openspec feedback ​

openspec completion ​

Codici di uscita ​

Variabili d'ambiente ​

Documentazione correlata ​

Riferimento CLI

Riepilogo

Comandi Umani vs Agent

Comandi Solo Umani

Comandi Compatibili con Agent

Opzioni Globali

Comandi di Configurazione

`openspec init`

`openspec update`

Stores (repository OpenSpec autonomi)

`openspec store setup`

`openspec store register`

`openspec store unregister`

`openspec store remove`

`openspec store list`

`openspec store doctor`

Riferire agli stores da un progetto

Registrare da dove è clonato uno store

Dichiarare uno store predefinito

Doctor (salute delle relazioni)

Contesto di lavoro (l’insieme assemblato)

Workset personali

Comandi di navigazione

`openspec list`

`openspec view`

`openspec show`

Comandi di validazione

`openspec validate`

Comandi del ciclo di vita

`openspec archive`

Comandi del Flusso di Lavoro

`openspec new change`

`openspec status`

`openspec instructions`

`openspec templates`

`openspec schemas`

Comandi per gli schemi

`openspec schema init`

`openspec schema fork`

`openspec schema validate`

`openspec schema which`

Comandi di configurazione

`openspec config`

Comandi utilità

`openspec feedback`

`openspec completion`

Codici di uscita

Variabili d'ambiente

Documentazione correlata