CLI-referentie

De OpenSpec CLI (openspec) biedt terminalopdrachten voor projectconfiguratie, validatie, statusinspectie en beheer. Deze opdrachten vormen een aanvulling op de AI slash-commando's (zoals /opsx:propose) die worden beschreven in Commando's.

Samenvatting

Categorie	Opdrachten	Doel
Opzet	`init`, `update`	OpenSpec in uw project initialiseren en bijwerken
Stores (zelfstandige OpenSpec-repositories)	`store setup`, `store register`, `store unregister`, `store remove`, `store list`, `store doctor`	Stores beheren — zelfstandige OpenSpec-repositories die u hebt geregistreerd
Gezondheid	`doctor`	Relatiegezondheid voor de opgeloste root rapporteren
Werkcontext	`context`	Werkset samenstellen (root + gerefereerde stores)
Persoonlijke werksets	`workset create`, `workset list`, `workset open`, `workset remove`	Persoonlijke, lokale werkweergaven bewaren en openen in uw tool
Bladeren	`list`, `view`, `show`	Wijzigingen en specificaties verkennen
Validatie	`validate`	Wijzigingen en specificaties controleren op problemen
Levenscyclus	`archive`	Voltooide wijzigingen afronden
Workflow	`new change`, `status`, `instructions`, `templates`, `schemas`	Ondersteuning voor artefactgestuurde workflows
Schema's	`schema init`, `schema fork`, `schema validate`, `schema which`	Aangepaste workflows aanmaken en beheren
Configuratie	`config`	Instellingen bekijken en wijzigen
Hulpprogramma's	`feedback`, `completion`	Feedback en shell-integratie

Human vs Agent Commands

De meeste CLI-commando's zijn ontworpen voor gebruik door mensen in een terminal. Sommige commando's ondersteunen ook gebruik door agenten/scripts via JSON-output.

Alleen voor Mensen

Deze commando's zijn interactief en ontworpen voor gebruik in een terminal:

Commando	Doel
`openspec init`	Project initialiseren (interactieve prompts)
`openspec view`	Interactief dashboard
`openspec workset open <name>`	Een opgeslagen workset openen (editorvenster of terminal agentsessie)
`openspec config edit`	Configuratie openen in editor
`openspec feedback`	Feedback indienen via GitHub
`openspec completion install`	Shell-completies installeren

Agent-Compatibele Commando's

Deze commando's ondersteunen --json-output voor programmatisch gebruik door AI-agenten en scripts:

Commando	Gebruik door Mensen	Gebruik door Agenten
`openspec list`	Wijzigingen/specs bekijken	`--json` voor gestructureerde data
`openspec show <item>`	Inhoud lezen	`--json` voor parsing
`openspec validate`	Problemen controleren	`--all --json` voor bulkvalidatie
`openspec status`	Voortgang van artefacten bekijken	`--json` voor gestructureerde status
`openspec instructions`	Volgende stappen ophalen	`--json` voor agentinstructies
`openspec templates`	Templatepaden vinden	`--json` voor padoplossing
`openspec schemas`	Beschikbare schemas weergeven	`--json` voor schema-ontdekking; `--store <id>` om een geregistreerde root te selecteren
`openspec store setup <id>`	Een lokale store aanmaken en registreren	`--json` met expliciete invoer voor gestructureerde setup-output
`openspec store register <path>`	Een bestaande store registreren	`--json` voor gestructureerde registratie-output
`openspec store unregister <id>`	Een lokale store-registratie vergeten	`--json` voor gestructureerde opschonings-output
`openspec store remove <id>`	Een geregistreerde lokale store-map verwijderen	`--yes --json` voor niet-interactieve verwijdering
`openspec store list`	Geregistreerde stores bekijken	`--json` voor gestructureerde registraties
`openspec store doctor`	Lokale store-setup controleren	`--json` voor gestructureerde diagnostiek
`openspec new change <id>`	Repo-lokale change-scaffolding aanmaken	`--json`, plus `--store <id>` om een geregistreerde store als OpenSpec-root te gebruiken
`openspec workset create [name]`	Een persoonlijke werkweergave samenstellen	`--member <path> --json` voor niet-interactieve samenstelling
`openspec workset list`	Opgeslagen worksets bekijken	`--json` voor gestructureerde weergaven
`openspec workset remove <name>`	Een opgeslagen weergave verwijderen	`--yes --json` for niet-interactieve verwijdering

Globale Opties

Deze opties werken met alle commando's:

Optie	Beschrijving
`--version`, `-V`	Versienummer weergeven
`--no-color`	Kleuroutput uitschakelen
`--help`, `-h`	Hulp voor commando weergeven

Setup-Commando's

`openspec init`

Initialiseer OpenSpec in uw project. Maakt de mapstructuur aan en configureert AI-tool-integraties.

Het standaardgedrag gebruikt de globale configuratie-standaardwaarden: profiel core, levering both, workflows propose, explore, apply, update, sync, archive.

openspec init [path] [options]

Gebruik --language <language> om een taalinstructie toe te voegen aan openspec/config.yaml van een nieuw project. Voor een bestaand project bewerkt u het context-veld van de configuratie zodat OpenSpec project-specifieke begeleiding nooit overschrijft.

Argumenten:

Argument	Vereist	Beschrijving
`path`	Nee	Doelmap (standaard: huidige map)

Opties:

Optie	Beschrijving
`--tools <list>`	AI-tools niet-interactief configureren. Gebruik `all`, `none`, of een met komma's gescheiden lijst
`--language <language>`	Artefacten in deze taal schrijven bij het aanmaken van een nieuwe configuratie
`--force`	Legacy-bestanden automatisch opruimen zonder prompt
`--profile <profile>`	Globaal profiel voor deze init-run overschrijven (`core` of `custom`)
`--no-animation`	Een statisch welkomstscherm tonen in plaats van het geanimeerde
`--copilot-cloud`	GitHub Copilot cloud coding-agent-bestanden configureren zonder prompt
`--no-copilot-cloud`	GitHub Copilot cloud coding-agent-bestanden overslaan zonder prompt

--profile custom gebruikt de workflows die momenteel zijn geselecteerd in de globale configuratie (openspec config profile).

De welkomstanimatie wordt ook overgeslagen wanneer de OPENSPEC_NO_ANIMATION-omgevingsvariabele is ingesteld (elke waarde, inclusief leeg), wanneer NO_COLOR is ingesteld op een niet-lege waarde, of wanneer de OS-voorkeur voor verminderde beweging is ingeschakeld (macOS Reduce Motion, GNOME-animaties uitgeschakeld).

Ondersteunde tool-ID's (--tools) — windsurf wordt ook geaccepteerd als alias voor 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

Deze lijst spiegelt AI_TOOLS in src/core/config.ts. Zie Ondersteunde Tools voor de vaardigheids- en commandopaden van elke tool.

Voorbeelden:

bash

# Interactieve initialisatie
openspec init

# Initialiseren in een specifieke map
openspec init ./my-project

# Niet-interactief: configureren voor Claude en Cursor
openspec init --tools claude,cursor

# Niet-interactief: globale MiniMax Code-vaardigheden configureren
openspec init --tools minimax-code

# Configureren voor alle ondersteunde tools
openspec init --tools all

# Profiel voor deze run overschrijven
openspec init --profile core

# Prompts overslaan en legacy-bestanden automatisch opruimen
openspec init --force

Wat het aanmaakt:

openspec/
├── specs/              # Uw specificaties (bron van waarheid)
├── changes/            # Voorgestelde wijzigingen
└── config.yaml         # Projectconfiguratie

.claude/skills/         # Claude Code-vaardigheden (als claude is geselecteerd)
.cursor/skills/         # Cursor-vaardigheden (als cursor is geselecteerd)
.cursor/commands/       # Cursor OPSX-commando's (als levering commando's bevat)
.agents/skills/         # Gedeelde vaardigheden voor AGENTS.md-compatibele tools (als agents is geselecteerd)
... (andere toolconfiguraties)

`openspec update`

Werk OpenSpec-instructiebestanden bij na het upgraden van de CLI. Genereert AI-tool-configuratiebestanden opnieuw met behulp van uw huidige globale profiel, geselecteerde workflows en leveringsmodus.

openspec update [path] [options]

Argumenten:

Argument	Vereist	Beschrijving
`path`	Nee	Doelmap (standaard: huidige map)

Opties:

Optie	Beschrijving
`--force`	Update forceren, zelfs wanneer bestanden up-to-date zijn

Voorbeeld:

bash

# Instructiebestanden bijwerken na npm-upgrade
npm install -g @fission-ai/openspec@latest
openspec update

Werk eerst het pakket bij. Instructiebestanden worden gegenereerd door de geïnstalleerde CLI, dus het uitvoeren van openspec update tegen een verouderde installatie rapporteert dat alles up-to-date is zonder de workflows van nieuwere releases toe te voegen.

Om dat zichtbaar te maken, vraagt openspec update de npm-registry of er een nieuwere CLI is gepubliceerd. Wanneer u achterloopt, biedt het een upgrade aan:

text

A newer OpenSpec CLI is available (v1.6.0 → v1.7.0).
  Running from: /usr/local/lib/node_modules/@fission-ai/openspec
? Upgrade to v1.7.0 now? (Y/n)

Bevestig met ja en het voert npm install -g @fission-ai/openspec@latest uit, waarna het de update opnieuw uitvoert met de nieuwe CLI zodat de nieuwe workflows in hetzelfde commando worden geïmplementeerd. Het bevestigt de upgrade door de geïnstalleerde binary zijn versie te vragen in plaats van de exit code van npm te vertrouwen, zodat als een andere installatie eerder op uw PATH nog steeds antwoordt, het u dit vertelt in plaats van succes te claimen. Bevestig met nee en het toont het commando en werkt bij met de CLI die u heeft. Ctrl-C stopt het commando.

Het aanbod verschijnt alleen in een interactieve terminal en alleen wanneer npm de installatie bezit — het enige geval dat npm install -g daadwerkelijk oplost. Alles anders krijgt het commando dat overeenkomt met hoe het is geïnstalleerd:

Hoe OpenSpec is geïnstalleerd	Wat u krijgt
Globale npm-installatie	De prompt en de upgrade wordt voor u uitgevoerd — in een interactieve terminal; gepijpte output krijgt in plaats daarvan het gedrukte commando
Globale pnpm, bun, yarn of volta-installatie	Het eigen commando van die manager: `pnpm add -g …@latest`, `bun add -g …@latest`, `yarn global add …@latest`, of `volta install …@latest`
Een afhankelijkheid van het project	Een opmerking om de afhankelijkheid bij te werken, aangezien de pakketmanager van die afhankelijkheid de lockfile bezit
Een `npx` / `dlx`-cache	`npx @fission-ai/openspec@latest update` — dat commando is de update, dus er is geen tweede stap
Een git-clone	Niets — uw versie is wat de branch aangeeft

Wanneer er iets wordt gedrukt, noemt het de map waaruit de draaiende CLI is geladen — het ding om te controleren wanneer u wel heeft geüpgraded maar een verouderde shim nog steeds uw PATH bezit.

Het vraagt de registry in npm_config_registry wanneer npm die exporteert, en anders https://registry.npmjs.org. Er wordt geen .npmrc gelezen: het laten kiezen van bestandsinhoud waar een uitgaande aanvraag naartoe gaat is een flow die het vermijden waard is, en een .npmrc van een project reist mee met de repository. Op een privé-mirror exporteert u npm_config_registry — of stelt u OPENSPEC_NO_UPDATE_CHECK in om de controle volledig te overslaan. De controle wordt overgeslagen wanneer CI op iets anders dan een expliciete off-waarde is ingesteld (false, 0, no, off, of leeg), onder NODE_ENV=test, en wanneer OPENSPEC_NO_UPDATE_CHECK (elke waarde), DO_NOT_TRACK=1, of OPENSPEC_TELEMETRY=0 is ingesteld. Het wordt uitgevoerd vóór de update en kan deze met maximaal 1,5 seconden vertragen — het geeft op na die tijd, zelfs wanneer het netwerk pakketjes stilzwijgend verliest, en blijft stil wanneer de registry onbereikbaar is.

Hoe "up-to-date" wordt bepaald: vaardigheidsbestanden registreren de versie die ze heeft gegenereerd, dus OpenSpec vergelijkt die met de geïnstalleerde CLI. Commandobestanden bevatten geen versiestempel, dus voor een tool die commando's heeft maar geen vaardigheden (levering commands), vergelijkt OpenSpec de bestandsinhoud met wat het nu zou genereren — bewerkingen aan die bestanden tellen als drift en worden overschreven. Met levering skills of both wordt alleen de geregistreerde versie gecontroleerd, dus een handmatig bewerkt bestand waarvan de versie nog steeds overeenkomt wordt niet aangeraakt; gebruik --force om het te herschrijven. In beide gevallen zijn gegenereerde bestanden eigendom van OpenSpec — bewaar uw eigen instructies elders.

Stores (zelfstandige OpenSpec-repositories)

Bèta. Stores en de daarop gebouwde functies (verwijzingen, werkcontext, werksets) zijn nieuw; commandonamen, vlaggen, bestandsindelingen en JSON-uitvoer kunnen tussen releases veranderen. Voor de probleemgerichte doorloop, zie de stores-handleiding.

Een store is een zelfstandige OpenSpec-repo die je op deze machine hebt geregistreerd — bijvoorbeeld een planningsrepo of een contractenrepo. Door een store te registreren kunnen normale commando's (list, show, status, validate, new change, archive, ...) er overal in werken door --store <id> mee te geven.

`openspec store setup`

Maak een lokale store aan en registreer deze. Zonder argumenten in een terminal begeleidt OpenSpec de gebruiker door de installatie. Agents en scripts moeten expliciete invoer doorgeven en --json gebruiken.

bash

openspec store setup [id] [options]

Opties:

Optie	Beschrijving
`--path <path>`	Map waar de store moet leven (bijvoorbeeld `~/openspec/<id>`)
`--remote <url>`	Neem de canonieke remote op in de `store.yaml` van de nieuwe store
`--init-git`	Initialiseer een Git-repository met een eerste commit (standaard)
`--no-init-git`	Sla elke Git-actie over: geen init, geen eerste commit
`--json`	Uitvoer als JSON

Niet-interactieve runs (--json, scripts, agents) moeten zowel het store-id als --path doorgeven. In een interactieve terminal vraagt de setup om de locatie met een aanpasbaar voorstel op een zichtbare, gebruiker-eigen plaats (bijvoorbeeld ~/openspec/<id>); het gebruikt nooit standaard OpenSpec's beheerde datamap.

Voorbeelden:

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`

Registreer een bestaande lokale store-map. Tijdens de stores-bèta kan een root worden geregistreerd voordat er wijzigingen bestaan, specs zijn toegepast of wijzigingen zijn gearchiveerd; in dat geval kunnen openspec/changes/, openspec/specs/ en openspec/changes/archive/ ontbreken totdat normale commando's ze aanmaken. Een config-only repo die store: <id> declareert, blijft een verwijzing naar een andere store en wordt niet geregistreerd als een store-root, tenzij die verwijzing wordt verwijderd.

bash

openspec store register [path] [options]

Opties:

Optie	Beschrijving
`--id <id>`	Store-id; standaard store-metadata of mapnaam
`--yes`	Bevestig het aanmaken van store-identiteitsmetadata voor een gezonde OpenSpec-root
`--json`	Uitvoer als JSON

`openspec store unregister`

Vergeet een lokale store-registratie zonder bestanden te verwijderen.

bash

openspec store unregister <id> [--json]

Gebruik dit wanneer een store is verplaatst, ergens anders gekloond, of niet meer door OpenSpec op deze machine getoond hoeft te worden.

`openspec store remove`

Vergeet een lokale store-registratie en verwijder de lokale map.

bash

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

remove toont de exacte map voordat deze wordt verwijderd in een interactieve terminal. Agents, scripts en JSON-aanroepers moeten --yes doorgeven om de verwijdering te bevestigen. OpenSpec weigert een map te verwijderen die geen overeenkomende store-metadata bevat.

`openspec store list`

Lijst lokaal geregistreerde stores.

bash

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

`openspec store doctor`

Controleer lokale store-registratie, metadata en Git-aanwezigheid.

bash

openspec store doctor [id] [--json]

Doctor is alleen diagnostisch; het rapporteert ontbrekende roots, metadata-afwijkingen en ongeldige lokale registerstatus zonder de store te wijzigen.

Verwijzen naar stores vanuit een project

Een projectrepo kan declareren op welke stores het werk betrekking heeft in openspec/config.yaml:

yaml

schema: spec-driven
references:
  - team-context

Vanaf dat moment bevat de uitvoer van openspec instructions in die repo (zowel de per-artefact- als de apply-oppervlakken, JSON- en menselijke modi) een index van de specs van elke gerefereerde store — spec-ids, een eenregelige samenvatting uit de Purpose-sectie van elke spec, en het ophaalcommando (openspec show <spec-id> --type spec --store <id>). De index wordt bij elke run live opgebouwd uit de geregistreerde checkout; spec-inhoud wordt nooit in de uitvoer gekopieerd.

Verwijzingen zijn alleen-lezen context. Ze veranderen nooit waar commando's op werken: werk blijft in de eigen root van de repo, en schrijven naar een gerefereerde store blijft een expliciete --store-actie. Een verwijzing die niet kan worden opgelost (bijvoorbeeld een store die niet op deze machine is geregistreerd) vervalt tot een waarschuwing in de index met de exacte oplossing, en instructies worden nog steeds gegenereerd. openspec doctor rapporteert de gezondheid van verwijzingen op één plaats.

Vastleggen waar een store vandaan is gekloond

Een store kan zijn canonieke clone-bron vastleggen in zijn vastgelegde identiteitsbestand, zodat onboarding nooit doodloopt bij "registreer de store":

bash

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

De remote komt terecht in .openspec-store/store.yaml in de eerste commit, zodat elke clone er vanaf het begin van weet. Voor een bestaande store, bewerk store.yaml handmatig en commit. store doctor toont de vastgelegde remote (en de waargenomen Git-origin van de checkout); setup/register-delingstips noemen het; en register legt de origin van de checkout vast in het machine-lokale register.

Een verwijzingsdeclaratie kan ook de clone-bron bevatten, zodat een teamgenoot die de store nog niet heeft een complete, plakbare oplossing krijgt (git clone <remote> <path> && openspec store register <path> --id <id>):

yaml

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

Het vastleggen van een remote is geen synchronisatie: OpenSpec klonert, trekt of duwt nooit op eigen initiatief.

Een standaardstore declareren

Een repo waarvan de planning volledig extern is — geen lokale openspec/specs/ of openspec/changes/ — kan zijn store één keer declareren in plaats van --store bij elk commando door te geven:

yaml

# openspec/config.yaml (the only file under openspec/)
store: team-context

Normale commando's lossen dan automatisch op naar de gedeclareerde store; de root-banner en het JSON-root-blok rapporteren source: "declared" met het store-id, en afgedrukte hints bevatten nog steeds --store <id>. De declaratie is een terugval, nooit een overschrijving: expliciete --store wint altijd, en een map met echte planningsmappen negeert de verwijzing (met een waarschuwing). Om een verwijzingsrepo om te zetten naar een lokale OpenSpec-root, verwijder de store:-regel en voer openspec init uit — init weigert te scaffolden zolang de declaratie aanwezig is.

Een machine-niveau variant dekt elke repo in één keer: openspec config set defaultStore <id> (zie Configuratie). Deze wordt alleen geraadpleegd nadat --store, een lokale root en een projectwijzer allemaal niet hebben opgelost; de root-banner en het JSON-root-blok rapporteren dan source: "global_default".

Doctor (relatiegezondheid)

Eén alleen-lezen vraag, één plek: is de OpenSpec-root gezond, en zijn de stores waarnaar het verwijst beschikbaar op deze machine?

bash

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

Het rapport scheidt rootgezondheid, store-metadatagezondheid (inclusief een opmerking wanneer de geregistreerde remote en de oorsprong van de checkout afwijken, en een opmerking wanneer de store-checkout is afgedwaald van de laatst opgehaalde upstream-tracking-ref), en referentiegezondheid (dezelfde diagnostische instructies die show toont, met clone-fixes voor onopgeloste referenties). Gezondheidsbevindingen van elke ernst eindigen met afsluitcode 0 — agents lezen de status-arrays; alleen opdrachtfouten (geen root, onbekende store) eindigen met afsluitcode 1. Doctor cloneert, synchroniseert of repareert nooit. Om de samengestelde set zelf te krijgen in plaats van de gezondheid, gebruik openspec context.

Werkcontext (de samengestelde set)

Alles waarmee dit werk verband houdt via OpenSpec-declaraties, in één werkset: de OpenSpec-root en de stores waarnaar het verwijst.

bash

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

De JSON-brief is agent-consumeerbaar (elke beschikbare referentiestore bevat zijn fetch-recept; onopgeloste leden dragen dezelfde fix-instructies als doctor toont). --code-workspace schrijft bovendien een VS Code-werkruimtebestand met de root plus de beschikbare referentiestores (ref:<id>-mappen) — de enige schrijfactie die dit commando uitvoert, geweigerd zonder --force als het bestand bestaat. Onbeschikbare leden worden gerapporteerd, nooit geraden.

Werkcontext is de samengestelde set; het veld context: in openspec/config.yaml is projectachtergrond die in instructies wordt geïnjecteerd — twee verschillende dingen. openspec doctor beantwoordt of de set gezond is; openspec context beantwoordt wat de set is.

Persoonlijke worksets

Bèta. Worksets maken deel uit van het nieuwe bèta-oppervlak; commando's, vlaggen en bestandsformaten kunnen tussen releases veranderen. Voor de doorloop, zie de stores-gids.

Een workset is een persoonlijke, benoemde weergave van de mappen waaraan je samen werkt — een planningsroot plus alles wat je verder kiest — bewaard op je machine en op naam heropend in je tool. Het is puur lokaal: nooit gecommit, nooit gedeeld, nooit afgeleid van declaraties, en het verwijderen ervan raakt nooit een lidmap.

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 voert een korte begeleide flow uit (of neemt --member-vlaggen non-interactief aan; het eerste lid is het primaire — sessies starten daar). open start de gekozen tool: editors (VS Code, Cursor) openen een venster met elk lid en keren terug; CLI-agents (Claude Code, codex) nemen deze terminal over als een sessie met elk lid eraan gekoppeld en zonder vooraf ingevulde prompt, eindigend wanneer je afsluit. Een lidmap die ontbreekt bij het openen wordt overgeslagen met een opmerking; de rest opent. De opgeslagen toolvoorkeur kan per opening worden overschreven met --tool.

Het ondersteunen van een nieuwe tool is configuratie, geen code. Elke tool heeft een van twee opstartstijlen — workspace-file (gestart met het gegenereerde .code-workspace) of attach-dirs (één attach-vlag per lid) — en de openers-sleutel in de globale config.json (open het met openspec config edit) voegt tools toe of past ingebouwde tools aan per veld:

json

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

Alle workset-status leeft onder de worksets/-map van de globale datamap (de opgeslagen weergaven plus de gegenereerde <naam>.code-workspace-bestanden, bij elke opening opnieuw gegenereerd); het verwijderen van die map verwijdert elk spoor.

Bladercommando's

`openspec list`

Lijst wijzigingen of specificaties in je project.

openspec list [options]

Opties:

Optie	Beschrijving
`--specs`	Lijst specificaties in plaats van wijzigingen
`--changes`	Lijst wijzigingen (standaard)
`--sort <order>`	Sorteer op `recent` (standaard) of `name`
`--json`	Uitvoer als JSON

Voorbeelden:

bash

# Lijst alle actieve wijzigingen
openspec list

# Lijst alle specificaties
openspec list --specs

# JSON-uitvoer voor scripts
openspec list --json

Uitvoer (tekst):

Wijzigingen:
  add-dark-mode     Geen taken      zojuist

`openspec view`

Toon een interactief dashboard voor het verkennen van specificaties en wijzigingen.

openspec view

Opent een terminalgebaseerde interface voor het navigeren door de specificaties en wijzigingen van je project.

`openspec show`

Toon details van een wijziging of specificatie.

openspec show [item-name] [options]

Argumenten:

Argument	Vereist	Beschrijving
`item-name`	Nee	Naam van wijziging of specificatie (vraagt om invoer als weggelaten)

Opties:

Optie	Beschrijving
`--type <type>`	Specificeer type: `change` of `spec` (automatisch gedetecteerd indien ondubbelzinnig)
`--json`	Uitvoer als JSON
`--no-interactive`	Schakel prompts uit

Wijzigingsspecifieke opties:

Optie	Beschrijving
`--deltas-only`	Toon alleen delta-specificaties (JSON-modus)

Specificatiespecifieke opties:

Optie	Beschrijving
`--requirements`	Toon alleen vereisten, scenario's uitsluiten (JSON-modus)
`--no-scenarios`	Scenario-inhoud uitsluiten (JSON-modus)
`-r, --requirement <id>`	Toon specifieke vereiste op basis van 1-gebaseerde index (JSON-modus)

Voorbeelden:

bash

# Interactieve selectie
openspec show

# Toon een specifieke wijziging
openspec show add-dark-mode

# Toon een specifieke specificatie
openspec show auth --type spec

# JSON-uitvoer voor verwerking
openspec show add-dark-mode --json

Validatieopdrachten

`openspec validate`

Valideer wijzigingen en specs op structurele problemen en controleer de AANGEPASTE vereisten van een wijziging tegenover de hoofdspecs die ze zouden vervangen.

openspec validate [item-name] [options]

Een wijziging zonder spec-delta's faalt validatie tenzij de bijbehorende .openspec.yaml skip_specs: true verklaart (voor pure refactors, tooling- of documentatiewerk — zie Recept 5).

Argumenten:

Argument	Vereist	Beschrijving
`item-name`	Nee	Specifiek item dat gevalideerd moet worden (vraagt om invoer indien weggelaten)

Opties:

Optie	Beschrijving
`--all`	Valideer alle wijzigingen en specs
`--changes`	Valideer alle wijzigingen
`--specs`	Valideer alle specs
`--archived`	Valideer dat gearchiveerde wijzigingen alle taken voltooid hebben (voor pre-commit linting)
`--type <type>`	Specificeer het type wanneer de naam dubbelzinnig is: `change` of `spec`
`--strict`	Schakel strikte validatiemodus in
`--json`	Uitvoer als JSON
`--concurrency <n>`	Maximale parallelle validaties (standaard: 6, of `OPENSPEC_CONCURRENCY` omgevingsvariabele)
`--no-interactive`	Schakel prompts uit

--archived is een eigen scope: het valideert de spec-delta's niet (die al toegepast zijn op het moment van archivering), maar controleert dat elke wijziging onder changes/archive/ alle vinkjes in zijn tasks.md heeft aangevinkt, en sluit af met een niet-nul status indien er nog openstaande taken zijn. Dit vangt wijzigingen op die gearchiveerd zijn met onvoltooid werk — handig in een pre-commit hook.

Voorbeelden:

bash

# Interactieve validatie
openspec validate

# Valideer een specifieke wijziging
openspec validate add-dark-mode

# Valideer alle wijzigingen
openspec validate --changes

# Valideer alles met JSON-uitvoer (voor CI/scripts)
openspec validate --all --json

# Strikte validatie met verhoogde parallellie
openspec validate --all --strict --concurrency 12

# Misluk als een gearchiveerde wijziging nog openstaande taken heeft
openspec validate --archived

Uitvoer (tekst):

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

1 warning found

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

Levenscyclusopdrachten

`openspec archive`

Archiveer een voltooide wijziging en voeg delta-specs samen in hoofdspecs.

openspec archive [change-name] [options]

Argumenten:

Argument	Vereist	Beschrijving
`change-name`	Nee	Wijziging om te archiveren (vraagt om invoer indien weggelaten; vereist wanneer niets de prompt kan beantwoorden)

Opties:

Optie	Beschrijving
`-y, --yes`	Overslaan van bevestigingsprompts. Vereist wanneer niets ze kan beantwoorden — een AI-agent, een CI-taak of elke uitvoering met gesloten stdin
`--skip-specs`	Spec-updates overslaan voor één archiveringsrun. Een wijziging die permanent geen spec-delta's heeft, moet `skip_specs: true` in zijn `.openspec.yaml` declareren — dan archiveert het zonder vlag
`--no-validate`	Validatie overslaan (vereist bevestiging). Schakelt ook de buitengebruikstelling van capaciteiten uit — zonder validatieoordeel wordt niets buitengebruikgesteld

Voorbeelden:

bash

# Interactief archiveren (vraagt welke wijziging, daarna bevestigen)
openspec archive

# Specifieke wijziging archiveren
openspec archive add-dark-mode

# Archiveren zonder prompts (agents, CI, scripts)
openspec archive add-dark-mode --yes

# Een tooling-wijziging archiveren die geen invloed op specs heeft
openspec archive update-ci-config --skip-specs

Een capaciteit buiten gebruik stellen: Voeg de marker voor buitengebruikstelling toe aan de metadata van de wijziging:

yaml

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

Archiveer vervolgens de wijziging normaal:

bash

openspec archive retire-legacy --yes

Wanneer de wijziging de laatste vereiste van de capaciteit verwijdert, verwijdert OpenSpec zijn live spec.md. Andere capaciteitsdelta's in dezelfde wijziging updaten nog steeds hun hoofdspecs. Zonder de marker stopt het archiveren voordat er bestanden gewijzigd worden en wordt aangegeven dat je deze moet toevoegen.

Wat het doet:

Valideert de wijziging (tenzij --no-validate)
Vraagt om bevestiging (tenzij --yes)
Claimt de archiefdoelmap voordat er een hoofdspec wordt gewijzigd
Valideert en voegt de actieve delta-specs samen in openspec/specs/ — een capaciteit waarvan de laatste vereiste door de wijziging wordt verwijderd, wordt buitengebruikgesteld en het spec-bestand ervan wordt verwijderd, maar alleen wanneer de .openspec.yaml van de wijziging retire_capabilities: true declareert naast de schema:
Verplaatst de wijzigingsmap naar openspec/changes/archive/YYYY-MM-DD-<name>/
Als een spec-mutatie of de uiteindelijke verplaatsing mislukt voordat een volledig archief is veiliggesteld, worden de specs hersteld en blijft of keert de wijziging terug naar zijn actieve pad
Als een geverifieerde fallback-kopie slaagt, maar het opschonen van de gestagde bron mislukt, wordt het complete archief en de vastgelegde spec-status behouden voor herstel

Zonder een terminal: een AI-agent, een CI-taak of elke uitvoering met gesloten stdin kan stap 2 niet beantwoorden, dus stopt archiveren voordat er iets wordt aangeraakt, sluit af met exitcode 1 en toont het commando om opnieuw uit te voeren — openspec archive <name> --yes, met alle andere vlaggen die je hebt doorgegeven. Geef --yes (en de wijzigingsnaam) van tevoren op om de extra stap over te slaan.

Workflow Commando's

Deze commando's ondersteunen de artefactgedreven OPSX-workflow. Ze zijn nuttig voor zowel mensen die de voortgang controleren als agents die volgende stappen bepalen.

`openspec new change`

Maak een changedirectory en optionele ingecheckte metadata in de opgeloste OpenSpec-root.

bash

openspec new change <naam> [opties]

Changenamen moeten lowercase kebab-case gebruiken: kleine letters, cijfers en enkele afbreekstreepjes. Ze mogen geen spaties, underscores, hoofdletters, opeenvolgende afbreekstreepjes of voorafgaande/afsluitende afbreekstreepjes bevatten. Een voorafgaand cijfer is toegestaan, dus je kunt namen voorvoegen om wijzigingen te ordenen of te nivelleren, bijvoorbeeld 100-add-feature of 00001-add-auth.

Opties:

Optie	Beschrijving
`--description <tekst>`	Beschrijving om toe te voegen aan `index.md`
`--goal <tekst>`	Optionele doelen-metadata om op te slaan bij de change
`--schema <naam>`	Workflowschema om te gebruiken
`--store <id>`	Store-id om te gebruiken als OpenSpec-root (een store is een zelfstandige OpenSpec-repo die je hebt geregistreerd)
`--json`	Uitvoer als JSON

Voorbeelden:

bash

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

`openspec status`

Toon de artefactvoltooiingsstatus voor een change.

openspec status [opties]

Opties:

Optie	Beschrijving
`--change <id>`	Changenaam (vraagt indien weggelaten)
`--schema <naam>`	Schema-overschrijving (automatisch gedetecteerd uit de config van de change)
`--json`	Uitvoer als JSON

Voorbeelden:

bash

# Interactieve statuscontrole
openspec status

# Status voor specifieke change
openspec status --change add-dark-mode

# JSON voor agentgebruik
openspec status --change add-dark-mode --json

Uitvoer (tekst):

Change: add-dark-mode
Schema: spec-driven
Voortgang: 2/4 artefacten voltooid

[x] proposal
[x] specs
[ ] design
[-] tasks (geblokkeerd door: design)

Een change die skip_specs: true declareert, toont zijn specs-fase als [~] specs (overgeslagen: change declareert skip_specs) en sluit het uit van de voortgangstelling.

Uitvoer (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 rapporteert of elk niet-overgeslagen planningsartefact bestaat; overgeslagen artefacten tellen als voldaan zonder te worden gemaakt. Het rapporteert niet of implementatietaken zijn voltooid. isComplete is behouden als een compatibiliteitsalias met dezelfde waarde.

Artefacten worden vermeld in afhankelijkheidsvolgorde - een afhankelijkheid verschijnt nooit na iets dat ervan afhankelijk is - en artefacten die tegelijkertijd gereed worden (spec-driven's specs en design hebben beide alleen proposal nodig) behouden de volgorde die het schema declareert in plaats van een alfabetische. Dus de eerste ready-vermelding is het artefact dat als volgende moet worden geschreven.

`openspec instructions`

Haal verrijkte instructies op voor het maken van een artefact of het toepassen van taken. Wordt gebruikt door AI-agents om te begrijpen wat ze vervolgens moeten maken.

openspec instructions [artefact] [opties]

Argumenten:

Argument	Vereist	Beschrijving
`artefact`	Nee	Artefact-ID, of workflow-invoeroppervlak: `apply` of `archive`

Opties:

Optie	Beschrijving
`--change <id>`	Changenaam (vereist in niet-interactieve modus)
`--schema <naam>`	Schema-overschrijving
`--json`	Uitvoer als JSON

Speciale gevallen: Gebruik apply om taakimplementatie-instructies te krijgen. Gebruik archive om huidige, alleen-lezen archiefinvoeren (context en operationGuidance) op te halen voor een geldige change; het archiveert of muteert niets.

Voorbeelden:

bash

# Instructies voor volgende artefact
openspec instructions --change add-dark-mode

# Specifieke artefactinstructies
openspec instructions design --change add-dark-mode

# Apply/implementatie-instructies
openspec instructions apply --change add-dark-mode

# Huidige archiefoperatie-invoeren ophalen zonder te archiveren
openspec instructions archive --change add-dark-mode --json

# JSON voor agentgebruik
openspec instructions design --change add-dark-mode --json

Uitvoer omvat:

Template-inhoud voor het artefact
Projectcontext uit config
Inhoud van afhankelijkheidsartefacten
Per-artefactregels uit config
Huidige projectcontext en bijpassende operation guidance voor apply/archive

Operationele invoeren worden bij elke aanroep gelezen uit de opgeloste repo of geselecteerde store. Projectcontext is een vereiste prompt-niveau-invoer: agents lezen het en passen relevante projectfeiten, conventies en beperkingen toe. Operation guidance is optioneel additief advies: agents overwegen elke vermelding en volgen alleen vermeldingen die van toepassing en compatibel zijn met de ingebouwde workflow. Beide velden blijven gescheiden van expliciete gebruikerskeuzes, CLI-gestuurde status, ingebouwde instructies en artefactregels. Conflicterende context wordt gerapporteerd; conflicterende of niet-toepasselijke guidance wordt niet gevolgd en de reden wordt uitgelegd. Dit zijn gedragscontracten voor gegenereerde agents, geen afdwingbare CLI-controles. instructions archive retourneert alleen de geselecteerde change, optionele invoeren en rootmetadata; het bevat niet de statische archiefworkflow.

Voor een artefact dat is overgeslagen via skip_specs: true, is de uitvoer alleen een waarschuwing (JSON voegt skipped/warning-velden toe) - het artefact mag niet worden gemaakt.

`openspec templates`

Toon opgeloste templatepaden voor alle artefacten in een schema.

openspec templates [opties]

Opties:

Optie	Beschrijving
`--schema <naam>`	Schema om te inspecteren (standaard: `spec-driven`)
`--json`	Uitvoer als JSON

Voorbeelden:

bash

# Toon templatepaden voor standaardschema
openspec templates

# Toon templates voor aangepast schema
openspec templates --schema my-workflow

# JSON voor programmatisch gebruik
openspec templates --json

Uitvoer (tekst):

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`

Lijst beschikbare workflowschema's met hun beschrijvingen en artefactstromen.

openspec schemas [opties]

Opties:

Optie	Beschrijving
`--json`	Uitvoer als JSON
`--store <id>`	Gebruik een geregistreerde store als OpenSpec-root

Voorbeeld:

bash

openspec schemas

Uitvoer:

Beschikbare schema's:

  spec-driven (pakket)
    Het standaard spec-gedreven ontwikkelworkflow
    Stroom: proposal → specs → design → tasks

  my-custom (project)
    Aangepaste workflow voor dit project
    Stroom: research → proposal → tasks

Schema-commando's

Commando's voor het maken en beheren van aangepaste workflow-schema's.

`openspec schema init`

Maak een nieuw project-lokaal schema.

openspec schema init <name> [options]

Argumenten:

Argument	Verplicht	Beschrijving
`name`	Ja	Schemanaam (kebab-case)

Opties:

Optie	Beschrijving
`--description <text>`	Schemabeschrijving
`--artifacts <list>`	Met komma's gescheiden artifact-ID's (standaard: `proposal,specs,design,tasks`)
`--default`	Instellen als projectstandaardschema
`--no-default`	Geen prompt om als standaard in te stellen
`--force`	Bestaand schema overschrijven
`--json`	Uitvoer als JSON

Voorbeelden:

bash

# Interactieve schemacreatie
openspec schema init research-first

# Niet-interactief met specifieke artifacts
openspec schema init rapid \
  --description "Rapid iteration workflow" \
  --artifacts "proposal,tasks" \
  --default

Wat het aanmaakt:

openspec/schemas/<name>/
├── schema.yaml           # Schema-definitie
└── templates/
    ├── proposal.md       # Sjabloon voor elk artifact
    ├── specs.md
    ├── design.md
    └── tasks.md

`openspec schema fork`

Kopieer een bestaand schema naar uw project voor aanpassing.

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

Argumenten:

Argument	Verplicht	Beschrijving
`source`	Ja	Schema om te kopiëren
`name`	Nee	Nieuwe schemanaam (standaard: `<source>-custom`)

Opties:

Optie	Beschrijving
`--force`	Bestaande bestemming overschrijven
`--json`	Uitvoer als JSON

Voorbeeld:

bash

# Fork het ingebouwde spec-driven schema
openspec schema fork spec-driven my-workflow

`openspec schema validate`

Valideer de structuur en sjablonen van een schema.

openspec schema validate [name] [options]

Argumenten:

Argument	Verplicht	Beschrijving
`name`	Nee	Schema om te valideren (valideert alles indien weggelaten)

Opties:

Optie	Beschrijving
`--verbose`	Toon gedetailleerde validatiestappen
`--json`	Uitvoer als JSON

Voorbeeld:

bash

# Valideer een specifiek schema
openspec schema validate my-workflow

# Valideer alle schema's
openspec schema validate

`openspec schema which`

Toon waar een schema vandaan komt (handig voor het debuggen van prioriteit).

openspec schema which [name] [options]

Argumenten:

Argument	Verplicht	Beschrijving
`name`	Nee	Schemanaam

Opties:

Optie	Beschrijving
`--all`	Alle schema's met hun bronnen tonen
`--json`	Uitvoer als JSON

Voorbeeld:

bash

# Controleer waar een schema vandaan komt
openspec schema which spec-driven

Uitvoer:

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

Schemaprioriteit:

Project: openspec/schemas/<name>/
Gebruiker: ~/.local/share/openspec/schemas/<name>/
Pakket: Ingebouwde schema's

Configuratie-commando's

`openspec config`

Bekijk en wijzig de globale OpenSpec-configuratie.

openspec config <subcommand> [options]

Ondercommando's:

Ondercommando	Beschrijving
`path`	Configuratiebestandslocatie tonen
`list`	Alle huidige instellingen tonen
`get <key>`	Een specifieke waarde ophalen
`set <key> <value>`	Een waarde instellen
`unset <key>`	Een sleutel verwijderen
`reset`	Terugzetten naar standaardwaarden
`edit`	Openen in `$EDITOR`
`profile [preset]`	Workflowprofiel interactief of via preset configureren

Voorbeelden:

bash

# Configuratiebestandspad tonen
openspec config path

# Alle instellingen tonen
openspec config list

# Een specifieke waarde ophalen
openspec config get telemetry.enabled

# Een waarde instellen (anonieme gebruikstelemetrie uitschakelen)
openspec config set telemetry.enabled false

# Een tekenreekswaarde expliciet instellen
openspec config set user.name "My Name" --string

# Een aangepaste instelling verwijderen
openspec config unset user.name

# Een machine-niveau standaardopslag instellen (fallback-root wanneer geen --store,
# lokale root of projectopslag: pointer oplost)
openspec config set defaultStore team-plans

# Alle configuratie terugzetten
openspec config reset --all --yes

# Configuratie bewerken in uw editor
openspec config edit

# Profiel configureren met actie-gebaseerde wizard
openspec config profile

# Snel preset: werkstromen wisselen naar core (behoudt leveringsmodus)
openspec config profile core

Telemetrie opt-out: telemetry.enabled staat standaard aan wanneer niet ingesteld (opt-out-model). Stel deze in op false om anonieme gebruiksstatistieken en de openspec update versiecontrole uit te schakelen. Omgevingsvariabelen hebben voorrang op configuratie: OPENSPEC_TELEMETRY=0, DO_NOT_TRACK=1, en een waar-waarde voor CI (bijv. true/1/yes) schakelen telemetrie altijd uit, ongeacht de configuratiewaarde.

openspec config profile begint met een samenvatting van de huidige staat, waarna u kunt kiezen:

Levering + werkstromen wijzigen
Alleen levering wijzigen
Alleen werkstromen wijzigen
Huidige instellingen behouden (afsluiten)

Als u de huidige instellingen behoudt, worden er geen wijzigingen geschreven en wordt er geen updateprompt getoond. Als er geen configuratiewijzigingen zijn maar de huidige projectbestanden niet synchroon zijn met uw globale profiel/levering, toont OpenSpec een waarschuwing en suggereert openspec update. Het indrukken van Ctrl+C annuleert de flow ook netjes (geen stack trace) en sluit af met code 130. In de werkstroom-checklist betekent [x] dat de werkstroom is geselecteerd in de globale configuratie. Om die selecties toe te passen op projectbestanden, voert u openspec update uit (of kiest u Apply changes to this project now? wanneer u wordt gevraagd binnen een project).

Interactieve voorbeelden:

bash

# Alleen levering bijwerken
openspec config profile
# kies: Change delivery only
# kies levering: Skills only

# Alleen werkstromen bijwerken
openspec config profile
# kies: Change workflows only
# schakel werkstromen in de checklist, bevestig daarna

Hulpmiddel-commando's

`openspec feedback`

Verstuur feedback over OpenSpec. Maakt een GitHub-issue aan.

openspec feedback <message> [options]

Argumenten:

Argument	Verplicht	Beschrijving
`message`	Ja	Feedbacksamenvatting; lange tekst wordt verkort in de issue-titel en behouden in de body

Opties:

Optie	Beschrijving
`--body <text>`	Aanvullende details die na de samenvatting worden opgenomen

Vereisten: GitHub CLI (gh) moet geïnstalleerd en geauthenticeerd zijn.

Voorbeeld:

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`

Beheer shell-completions voor de OpenSpec CLI.

openspec completion <subcommand> [shell]

Ondercommando's:

Ondercommando	Beschrijving
`generate [shell]`	Completion-script naar stdout uitvoeren
`install [shell]`	Completion voor uw shell installeren
`uninstall [shell]`	Geïnstalleerde completions verwijderen

Ondersteunde shells: bash, zsh, fish, powershell

Voorbeelden:

bash

# Completions installeren (detecteert shell automatisch)
openspec completion install

# Installeren voor specifieke shell
openspec completion install zsh

# Script genereren voor handmatige installatie (bash)
openspec completion generate bash > ~/.bash_completion.d/openspec

# Deïnstalleren
openspec completion uninstall

Windows (PowerShell): Installeer completions voor de huidige PowerShell-host:

powershell

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

$env:PROFILE vertelt OpenSpec welk profiel in deze sessie moet worden geconfigureerd. De installateur maakt ontbrekende profielmappen aan en voegt een beheerd blok toe dat OpenSpecCompletion.ps1 laadt. Het opnieuw laden van het profiel activeert completions onmiddellijk.

Om te deïnstalleren van de huidige host, voert u uit:

powershell

$env:PROFILE = $PROFILE
openspec completion uninstall powershell

Herstart PowerShell na het deïnstalleren om completions uit de huidige sessie te wissen.

Completions zijn opt-in. De CLI noemt ze een keer, op stderr, de eerste keer dat u een commando uitvoert in een interactieve terminal, en nooit meer — het blijft ook stil als u al completions hebt geïnstalleerd. Stel OPENSPEC_NO_COMPLETIONS=1 in om die tip volledig te onderdrukken.

Exit-codes

Code	Betekenis
`0`	Succes
`1`	Fout (validatiefout, ontbrekende bestanden, etc.)

Omgevingsvariabelen

Variabele	Beschrijving
`OPENSPEC_TELEMETRY`	Stel in op `0` om telemetrie en de `openspec update` versiecontrole uit te schakelen (overschrijft `telemetry.enabled` in de globale configuratie)
`DO_NOT_TRACK`	Stel in op `1` om telemetrie en de `openspec update` versiecontrole uit te schakelen (standaard DNT-signaal; overschrijft configuratie)
`OPENSPEC_CONCURRENCY`	Standaard concurrentie voor bulkvalidatie (standaard: 6)
`EDITOR` of `VISUAL`	Editor voor `openspec config edit`
`NO_COLOR`	Schakel kleuruitvoer uit wanneer ingesteld
`OPENSPEC_NO_ANIMATION`	Schakel de `openspec init` welkomstanimatie uit wanneer ingesteld
`OPENSPEC_NO_COMPLETIONS`	Stel in op `1` om de eenmalige tip over shell-completions te onderdrukken
`OPENSPEC_NO_UPDATE_CHECK`	Schakel de `openspec update` controle voor een nieuwere gepubliceerde CLI uit wanneer ingesteld (elke waarde, inclusief leeg). Wordt ook overgeslagen wanneer `CI` is ingesteld (tenzij `false`/`0`/`no`/`off`) of `NODE_ENV=test`
`npm_config_registry`	Registry waar de `openspec update` versiecontrole naar vraagt. Moet een `http(s)`-URL zijn, anders valt het terug op `https://registry.npmjs.org`. Er wordt geen `.npmrc`-bestand gelezen

Gerelateerde documentatie

Commands - AI slash-commando's (/opsx:propose, /opsx:apply, etc.)
Workflows - Veelvoorkomende patronen en wanneer elk commando te gebruiken
Customization - Aangepaste schema's en sjablonen maken
Getting Started - Eerste keer installatiegids

CLI-referentie ​

Samenvatting ​

Human vs Agent Commands ​

Alleen voor Mensen ​

Agent-Compatibele Commando's ​

Globale Opties ​

Setup-Commando's ​

openspec init ​

openspec update ​

Stores (zelfstandige OpenSpec-repositories) ​

openspec store setup ​

openspec store register ​

openspec store unregister ​

openspec store remove ​

openspec store list ​

openspec store doctor ​

Verwijzen naar stores vanuit een project ​

Vastleggen waar een store vandaan is gekloond ​

Een standaardstore declareren ​

Doctor (relatiegezondheid) ​

Werkcontext (de samengestelde set) ​

Persoonlijke worksets ​

Bladercommando's ​

openspec list ​

openspec view ​

openspec show ​

Validatieopdrachten ​

openspec validate ​

Levenscyclusopdrachten ​

openspec archive ​

Workflow Commando's ​

openspec new change ​

openspec status ​

openspec instructions ​

openspec templates ​

openspec schemas ​

Schema-commando's ​

openspec schema init ​

openspec schema fork ​

openspec schema validate ​

openspec schema which ​

Configuratie-commando's ​

openspec config ​

Hulpmiddel-commando's ​

openspec feedback ​

openspec completion ​

Exit-codes ​

Omgevingsvariabelen ​

Gerelateerde documentatie ​

CLI-referentie

Samenvatting

Human vs Agent Commands

Alleen voor Mensen

Agent-Compatibele Commando's

Globale Opties

Setup-Commando's

`openspec init`

`openspec update`

Stores (zelfstandige OpenSpec-repositories)

`openspec store setup`

`openspec store register`

`openspec store unregister`

`openspec store remove`

`openspec store list`

`openspec store doctor`

Verwijzen naar stores vanuit een project

Vastleggen waar een store vandaan is gekloond

Een standaardstore declareren

Doctor (relatiegezondheid)

Werkcontext (de samengestelde set)

Persoonlijke worksets

Bladercommando's

`openspec list`

`openspec view`

`openspec show`

Validatieopdrachten

`openspec validate`

Levenscyclusopdrachten

`openspec archive`

Workflow Commando's

`openspec new change`

`openspec status`

`openspec instructions`

`openspec templates`

`openspec schemas`

Schema-commando's

`openspec schema init`

`openspec schema fork`

`openspec schema validate`

`openspec schema which`

Configuratie-commando's

`openspec config`

Hulpmiddel-commando's

`openspec feedback`

`openspec completion`

Exit-codes

Omgevingsvariabelen

Gerelateerde documentatie