Odniesienie CLI

Interfejs wiersza poleceń OpenSpec (openspec) udostępnia polecenia terminalowe do konfiguracji projektu, walidacji, sprawdzania stanu i zarządzania. Polecenia te uzupełniają polecenia AI (takie jak /opsx:propose) opisane w Poleceniach.

Podsumowanie

Kategoria	Polecenia	Cel
Konfiguracja	`init`, `update`	Inicjalizacja i aktualizacja OpenSpec w projekcie
Store'y (samodzielne repozytoria OpenSpec)	`store setup`, `store register`, `store unregister`, `store remove`, `store list`, `store doctor`	Zarządzanie store'ami — samodzielnymi repozytoriami OpenSpec, które zarejestrowałeś
Zdrowie	`doctor`	Raportowanie stanu relacji dla rozwiązanego katalogu głównego
Kontekst roboczy	`context`	Zbierz zestaw roboczy (root + odwołane store'y)
Osobiste zestawy robocze	`workset create`, `workset list`, `workset open`, `workset remove`	Przechowuj i otwieraj osobiste, lokalne widoki robocze w swoim narzędziu
Przeglądanie	`list`, `view`, `show`	Przeglądaj zmiany i specyfikacje
Walidacja	`validate`	Sprawdź zmiany i specyfikacje pod kątem problemów
Cykl życia	`archive`	Finalizuj ukończone zmiany
Przepływ pracy	`new change`, `status`, `instructions`, `templates`, `schemas`	Wsparcie przepływu pracy sterowanego artefaktami
Schematy	`schema init`, `schema fork`, `schema validate`, `schema which`	Twórz i zarządzaj niestandardowymi przepływami pracy
Konfiguracja	`config`	Wyświetl i modyfikuj ustawienia
Narzędzia	`feedback`, `completion`	Opinie i integracja z powłoką

Polecenia dla człowieka i dla agenta

Większość poleceń CLI jest przeznaczona do użytku przez człowieka w terminalu. Niektóre polecenia obsługują również użycie przez agenta/skrypt za pomocą wyjścia JSON.

Polecenia tylko dla człowieka

Te polecenia są interaktywne i przeznaczone do użycia w terminalu:

Polecenie	Przeznaczenie
`openspec init`	Inicjalizuj projekt (interaktywne monity)
`openspec view`	Interaktywny panel
`openspec workset open <name>`	Otwiera zapisany zestaw roboczy (okno edytora lub sesja agenta terminala)
`openspec config edit`	Otwiera konfigurację w edytorze
`openspec feedback`	Wyślij opinię przez GitHub
`openspec completion install`	Instaluje uzupełnienia powłoki

Polecenia kompatybilne z agentem

Te polecenia obsługują wyjście --json do programowego użycia przez agentów AI i skrypty:

Polecenie	Użycie przez człowieka	Użycie przez agenta
`openspec list`	Przeglądaj zmiany/specyfikacje	`--json` dla danych strukturalnych
`openspec show <item>`	Wyświetl zawartość	`--json` do parsowania
`openspec validate`	Sprawdź problemy	`--all --json` dla walidacji masowej
`openspec status`	Zobacz postęp artefaktów	`--json` dla statusu strukturalnego
`openspec instructions`	Pobierz kolejne kroki	`--json` dla instrukcji agenta
`openspec templates`	Znajdź ścieżki szablonów	`--json` dla rozwiązywania ścieżek
`openspec schemas`	Wyświetl dostępne schematy	`--json` dla wykrywania schematów; `--store <id>` aby wybrać zarejestrowany root
`openspec store setup <id>`	Utwórz i zarejestruj lokalny magazyn	`--json` z jawnymi danymi wejściowymi dla strukturalnego wyjścia konfiguracji
`openspec store register <path>`	Zarejestruj istniejący magazyn	`--json` dla strukturalnego wyjścia rejestracji
`openspec store unregister <id>`	Zapomnij rejestrację lokalnego magazynu	`--json` dla strukturalnego wyjścia czyszczenia
`openspec store remove <id>`	Usuń folder zarejestrowanego lokalnego magazynu	`--yes --json` dla nieinterakcyjnego usuwania
`openspec store list`	Przeglądaj zarejestrowane magazyny	`--json` dla strukturalnych rejestracji
`openspec store doctor`	Sprawdź konfigurację lokalnego magazynu	`--json` dla strukturalnej diagnostyki
`openspec new change <id>`	Utwórz rusztowanie zmian lokalnych w repozytorium	`--json`, plus `--store <id>` aby użyć zarejestrowanego magazynu jako korzeń OpenSpec
`openspec workset create [name]`	Skomponuj osobisty widok roboczy	`--member <path> --json` dla nieinterakcyjnego komponowania
`openspec workset list`	Przeglądaj zapisane zestawy robocze	`--json` dla strukturalnych widoków
`openspec workset remove <name>`	Usuń zapisany widok	`--yes --json` dla nieinterakcyjnego usuwania

Opcje globalne

Te opcje działają ze wszystkimi poleceniami:

Opcja	Opis
`--version`, `-V`	Pokaż numer wersji
`--no-color`	Wyłącz kolorowe wyjście
`--help`, `-h`	Wyświetl pomoc dla polecenia

Polecenia konfiguracji

`openspec init`

Inicjalizuje OpenSpec w Twoim projekcie. Tworzy strukturę folderów i konfiguruje integracje narzędzi AI.

Domyślne zachowanie używa globalnych ustawień domyślnych: profil core, dostarczanie both, przepływy pracy propose, explore, apply, update, sync, archive.

openspec init [path] [options]

Użyj --language <language> aby dodać instrukcję językową do nowego pliku openspec/config.yaml projektu. Dla istniejącego projektu, edytuj pole context w konfiguracji, aby OpenSpec nigdy nie nadpisywał wskazówek specyficznych dla projektu.

Argumenty:

Argument	Wymagany	Opis
`path`	Nie	Katalog docelowy (domyślnie: bieżący katalog)

Opcje:

Opcja	Opis
`--tools <list>`	Skonfiguruj narzędzia AI nieinteraktywnie. Użyj `all`, `none` lub listy oddzielonej przecinkami
`--language <language>`	Pisz artefakty w tym języku podczas tworzenia nowej konfiguracji
`--force`	Automatycznie usuń stare pliki bez monitowania
`--profile <profile>`	Zastąp globalny profil dla tego uruchomienia init (`core` lub `custom`)
`--no-animation`	Pokaż statyczny ekran powitalny zamiast animowanego
`--copilot-cloud`	Skonfiguruj pliki agenta kodowania w chmurze GitHub Copilot cloud coding-agent files bez monitowania
`--no-copilot-cloud`	Pomiń pliki agenta kodowania w chmurze GitHub Copilot bez monitowania

--profile custom używa tych przepływów pracy, które są obecnie wybrane w globalnej konfiguracji (openspec config profile).

Animacja powitalna jest również pomijana, gdy ustawiona jest zmienna środowiskowa OPENSPEC_NO_ANIMATION (dowolna wartość, włącznie z pustą), gdy NO_COLOR jest ustawione na niepustą wartość, lub gdy włączona jest preferencja systemu operacyjnego dotycząca ograniczenia ruchu (macOS Reduce Motion, wyłączone animacje GNOME).

Obsługiwane identyfikatory narzędzi (--tools) — windsurf jest także akceptowane, jako alias dla 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

Ta lista odzwierciedla AI_TOOLS w src/core/config.ts. Zobacz Obsługiwane narzędzia dla ścieżek umiejętności i poleceń każdego narzędzia.

Przykłady:

bash

# Inicjalizacja interaktywna
openspec init

# Inicjalizacja w określonym katalogu
openspec init ./my-project

# Nieinteraktywnie: skonfiguruj dla Claude i Cursor
openspec init --tools claude,cursor

# Nieinteraktywnie: skonfiguruj globalne umiejętności MiniMax Code
openspec init --tools minimax-code

# Skonfiguruj dla wszystkich obsługiwanych narzędzi
openspec init --tools all

# Zastąp profil dla tego uruchomienia
openspec init --profile core

# Pomiń monity i automatycznie usuń stare pliki
openspec init --force

Co tworzy:

openspec/
├── specs/              # Twoje specyfikacje (źródło prawdy)
├── changes/            # Proponowane zmiany
└── config.yaml         # Konfiguracja projektu

.claude/skills/         # Umiejętności Claude Code (jeśli wybrano claude)
.cursor/skills/         # Umiejętności Cursor (jeśli wybrano cursor)
.cursor/commands/       # Polecenia Cursor OPSX (jeśli dostarczanie obejmuje polecenia)
.agents/skills/         # Współdzielone umiejętności dla narzędzi kompatybilnych z AGENTS.md (jeśli wybrano agents)
... (inne konfiguracje narzędzi)

`openspec update`

Aktualizuje pliki instrukcji OpenSpec po aktualizacji CLI. Ponownie generuje pliki konfiguracyjne narzędzi AI przy użyciu bieżącego profilu globalnego, wybranych przepływów pracy i trybu dostarczania.

openspec update [path] [options]

Argumenty:

Argument	Wymagany	Opis
`path`	Nie	Katalog docelowy (domyślnie: bieżący katalog)

Opcje:

Opcja	Opis
`--force`	Wymuś aktualizację nawet gdy pliki są aktualne

Przykład:

bash

# Aktualizuj pliki instrukcji po aktualizacji npm
npm install -g @fission-ai/openspec@latest
openspec update

Najpierw zaktualizuj pakiet. Pliki instrukcji są generowane przez zainstalowany CLI, więc uruchomienie openspec update wobec nieaktualnej instalacji zgłosi, że wszystko jest aktualne, bez dodawania przepływów pracy dostarczanych przez nowsze wydania.

Aby to uwidocznić, openspec update pyta rejestr npm, czy opublikowano nowszą wersję CLI. Gdy Twoja jest nieaktualna, proponuje aktualizację:

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)

Jeśli odpowiesz tak, wykonuje npm install -g @fission-ai/openspec@latest, a następnie ponownie uruchamia aktualizację z nowym CLI, aby nowe przepływy pracy trafiły do tego samego polecenia. Potwierdza aktualizację, pytając zainstalowany plik binarny o jego wersję, zamiast ufać kodowi wyjścia npm, więc jeśli inna wcześniejsza instalacja na Twojej ścieżce PATH wciąż odpowiada, informuje Cię o tym zamiast ogłaszać sukces. Jeśli odpowiesz nie, wypisuje polecenie i aktualizuje za pomocą CLI, które posiadasz. Ctrl-C zatrzymuje polecenie.

Propozycja pojawia się tylko w interaktywnym terminalu i tylko wtedy, gdy npm jest właścicielem instalacji — jedyny przypadek, który npm install -g faktycznie naprawia. Wszystko inne otrzymuje polecenie odpowiadające sposobowi instalacji:

Jak zainstalowano OpenSpec	Co otrzymujesz
Instalacja globalna npm	Monit i upgrade wykonany za Ciebie — w interaktywnym terminalu; przekierowane wyjście otrzymuje wydrukowane polecenie zamiast tego
Instalacja globalna pnpm, bun, yarn lub volta	Własne polecenie tego menedżera: `pnpm add -g …@latest`, `bun add -g …@latest`, `yarn global add …@latest` lub `volta install …@latest`
Zależność projektu	Informacja, aby zaktualizować zależność, ponieważ jej menedżer pakietów zarządza plikiem lock
Bufor `npx` / `dlx`	`npx @fission-ai/openspec@latest update` — to polecenie jest aktualizacją, więc nie ma drugiego kroku
Klon git	Nic — Twoja wersja to ta, którą wskazuje gałąź

Gdy cokolwiek zostanie wydrukowane, podaje katalog, z którego załadowano uruchomione CLI — rzecz do sprawdzenia, gdy zaktualizowałeś, ale nieaktualna nakładka wciąż panuje nad Twoją ścieżką PATH.

Pyta rejestr w npm_config_registry, gdy npm go eksportuje, a w przeciwnym razie https://registry.npmjs.org. Żaden plik .npmrc nie jest odczytywany: pozwalanie, aby zawartość pliku wybierała, gdzie trafi żądanie wychodzące, jest przepływem, którego warto unikać, a plik .npmrc projektu podróżuje z repozytorium. W przypadku prywatnego mirrora, wyeksportuj npm_config_registry — lub ustaw OPENSPEC_NO_UPDATE_CHECK, aby całkowicie pominąć sprawdzanie. Sprawdzanie jest pomijane, gdy CI jest ustawione na cokolwiek poza jawną wartością wyłączającą (false, 0, no, off lub puste), podczas NODE_ENV=test, a także gdy ustawione jest OPENSPEC_NO_UPDATE_CHECK (dowolna wartość), DO_NOT_TRACK=1 lub OPENSPEC_TELEMETRY=0. Uruchamia się przed aktualizacją i może ją opóźnić o co najwyżej 1,5 sekundy — rezygnuje po tym czasie, nawet gdy sieć po cichu gubi pakiety, i milczy, gdy rejestr jest nieosiągalny.

Jak ustalana jest "aktualność": pliki umiejętności zapisują wersję, która je wygenerowała, więc OpenSpec porównuje ją z zainstalowanym CLI. Pliki poleceń nie posiadają znacznika wersji, więc dla narzędzia, które ma polecenia, ale nie ma umiejętności (dostarczanie commands), OpenSpec porównuje zawartość plików z tym, co wygenerowałby teraz — edycje tych plików liczą się jako dryft i są nadpisywane. Przy dostarczaniu skills lub both, sprawdzana jest tylko zapisana wersja, więc ręcznie edytowany plik, którego wersja wciąż pasuje, pozostaje nietknięty; użyj --force, aby go przepisać. W każdym przypadku, wygenerowane pliki należą do OpenSpec — trzymaj własne instrukcje gdzie indziej.

Store (samodzielne repozytoria OpenSpec)

Beta. Store i funkcje zbudowane na nich (references, working context, worksets) są nowe; nazwy poleceń, flagi, formaty plików i wyjście JSON mogą zmieniać się między wydaniami. Aby zapoznać się z przewodnikiem skoncentrowanym na problemach, zobacz przewodnik po store.

Store to samodzielne repozytorium OpenSpec, które zarejestrowałeś na tej maszynie — na przykład repozytorium planowania lub repozytorium kontraktów. Zarejestrowanie store pozwala normalnym poleceniom (list, show, status, validate, new change, archive, ...) działać w nim z dowolnego miejsca poprzez podanie --store <id>.

`openspec store setup`

Tworzy i rejestruje lokalny store. Bez argumentów w terminalu OpenSpec prowadzi użytkownika przez proces konfiguracji. Agenci i skrypty powinny przekazywać jawne dane wejściowe i używać --json.

bash

openspec store setup [id] [options]

Opcje:

Opcja	Opis
`--path <path>`	Folder, w którym store powinien się znajdować (na przykład `~/openspec/<id>`)
`--remote <url>`	Zapisuje kanoniczne zdalne źródło w `store.yaml` nowego store
`--init-git`	Inicjalizuje repozytorium Git z początkowym commitem (domyślnie)
`--no-init-git`	Pomija wszystkie akcje Git: brak init, brak początkowego commita
`--json`	Wyjście w formacie JSON

Uruchomienia nieinteraktywne (--json, skrypty, agenci) muszą podawać zarówno identyfikator store, jak i --path. W terminalu interaktywnym konfiguracja pyta o lokalizację z edytowalną sugestią w widocznym, należącym do użytkownika miejscu (na przykład ~/openspec/<id>); nigdy nie domyślnie używa zarządzanego katalogu danych OpenSpec.

Przykłady:

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`

Rejestruje istniejący lokalny folder store. Podczas beta store, korzeń może być zarejestrowany zanim pojawią się jakiekolwiek zmiany, specyfikacje zostaną zastosowane, lub zmiany zostaną zarchiwizowane; w takim przypadku openspec/changes/, openspec/specs/ i openspec/changes/archive/ mogą być nieobecne, dopóki normalne polecenia ich nie utworzą. Repozytorium tylko z konfiguracją, które deklaruje store: <id>, pozostaje wskaźnikiem do innego store i nie jest rejestrowane jako korzeń store, dopóki ten wskaźnik nie zostanie usunięty.

bash

openspec store register [path] [options]

Opcje:

Opcja	Opis
`--id <id>`	Identyfikator store; domyślnie używany jest z metadanych store lub nazwy folderu
`--yes`	Potwierdza utworzenie metadanych tożsamości store dla zdrowego korzenia OpenSpec
`--json`	Wyjście w formacie JSON

`openspec store unregister`

Usuwa lokalną rejestrację store bez usuwania plików.

bash

openspec store unregister <id> [--json]

Użyj tego, gdy store został przeniesiony, sklonowany gdzie indziej lub nie powinien już być wyświetlany przez OpenSpec na tej maszynie.

`openspec store remove`

Usuwa lokalną rejestrację store i kasuje jego lokalny folder.

bash

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

remove pokazuje dokładny folder przed usunięciem w terminalu interaktywnym. Agenci, skrypty i wywołania JSON muszą podać --yes, aby potwierdzić usunięcie. OpenSpec odmawia usunięcia folderu, który nie zawiera pasujących metadanych store.

`openspec store list`

Wyświetla listę lokalnie zarejestrowanych store.

bash

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

`openspec store doctor`

Sprawdza lokalną rejestrację store, metadane i obecność Gita.

bash

openspec store doctor [id] [--json]

Doctor ma charakter wyłącznie diagnostyczny; raportuje brakujące korzenie, niezgodności metadanych i nieprawidłowy stan lokalnego rejestru bez modyfikowania store.

Odwoływanie się do store z projektu

Repozytorium projektu może zadeklarować, do których store jego praca się odwołuje w openspec/config.yaml:

yaml

schema: spec-driven
references:
  - team-context

Od tego momentu wyjście openspec instructions w tym repozytorium (zarówno powierzchnie per-artefakt i apply, tryby JSON i ludzki) zawiera indeks specyfikacji każdego odwołanego store — identyfikatory specyfikacji, jednoliniowe podsumowanie z sekcji Cel każdej specyfikacji oraz polecenie pobierania (openspec show <spec-id> --type spec --store <id>). Indeks jest budowany na żywo z zarejestrowanego checkout podczas każdego uruchomienia; treść specyfikacji nigdy nie jest kopiowana do wyjścia.

Referencje są kontekstem tylko do odczytu. Nigdy nie zmieniają miejsca działania poleceń: praca pozostaje w własnym korzeniu repozytorium, a zapis do odwołanego store pozostaje jawną akcją --store. Referencja, która nie może zostać rozwiązana (na przykład store niezarejestrowany na tej maszynie), staje się ostrzeżeniem w indeksie z dokładnym rozwiązaniem, a instrukcje nadal są generowane. openspec doctor raportuje zdrowie referencji w jednym miejscu.

Rejestrowanie skąd store jest klonowany

Store może zapisać swoje kanoniczne źródło klonowania w swoim zatwierdzonym pliku tożsamości, aby proces wdrażania nigdy nie kończył się na "zarejestruj store":

bash

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

Zdalne źródło trafia do .openspec-store/store.yaml w początkowym commicie, więc każdy klon od początku je zna. Dla istniejącego store, edytuj store.yaml ręcznie i zatwierdź. store doctor pokazuje zarejestrowane zdalne źródło (oraz obserwowane pochodzenie Git checkout); wskazówki konfiguracji/rejestracji podają jego nazwę; a rejestracja zapisuje pochodzenie checkout w rejestrze lokalnym maszyny.

Deklaracja referencji może również zawierać źródło klonowania, dzięki czemu współpracownik, który nie ma jeszcze store, otrzymuje kompletne, wklejane rozwiązanie (git clone <remote> <path> && openspec store register <path> --id <id>):

yaml

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

Rejestrowanie zdalnego źródła nie jest synchronizacją: OpenSpec nigdy sam nie klonuje, nie pobiera ani nie wypycha zmian.

Deklarowanie domyślnego store

Repozytorium, którego planowanie jest w pełni zewnętrzne — bez lokalnych openspec/specs/ lub openspec/changes/ — może zadeklarować swój store raz, zamiast podawać --store przy każdym poleceniu:

yaml

# openspec/config.yaml (jedyny plik w katalogu openspec/)
store: team-context

Normalne polecenia są wtedy automatycznie rozwiązywane do zadeklarowanego store; baner korzenia i blok root w JSON raportują source: "declared" z identyfikatorem store, a wydrukowane podpowiedzi nadal zawierają --store <id>. Deklaracja jest rozwiązaniem zapasowym, nigdy nadpisaniem: jawne --store zawsze wygrywa, a katalog z prawdziwymi folderami planowania ignoruje wskaźnik (z ostrzeżeniem). Aby przekonwertować repozytorium-wskaźnik na lokalny korzeń OpenSpec, usuń linię store: i uruchom openspec init — init odmawia tworzenia szkieletu, dopóki deklaracja jest obecna.

Wariant na poziomie maszyny obejmuje każde repozytorium naraz: openspec config set defaultStore <id> (zobacz Konfiguracja). Jest brany pod uwagę dopiero po tym, gdy --store, lokalny korzeń i wskaźnik projektu nie przyniosły rozwiązania; baner korzenia i blok root w JSON raportują wtedy source: "global_default".

Doktor (kondycja relacji)

Jedno pytanie tylko do odczytu, jedno miejsce: czy główny katalog OpenSpec jest w dobrym stanie i czy magazyny, do których się odwołuje, są dostępne na tej maszynie?

bash

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

Raport oddziela kondycję katalogu głównego, kondycję metadanych magazynów (w tym notatkę, gdy zarejestrowany zdalny i origin checkoutu się rozjeżdżają, oraz notatkę, gdy checkout magazynu opóźnił się względem ostatnio pobranego upstream śledzącego refsa) oraz kondycję referencji (te same instrukcje diagnostyczne, z poprawkami klonowania dla nierozwiązanych referencji). Wyniki kondycji dowolnej wagi kończą się kodem 0 — agenci odczytują tablice status; tylko błędy polecenia (brak katalogu głównego, nieznany magazyn) kończą się kodem 1. Doktor nigdy nie klonuje, nie synchronizuje ani nie naprawia. Aby uzyskać sam zbiór zamiast jego kondycji, użyj openspec context.

Kontekst roboczy (zbiór złożony)

Wszystko, z czym ta praca jest związana poprzez deklaracje OpenSpec, w jednym zestawie roboczym: główny katalog OpenSpec i magazyny, do których się odwołuje.

bash

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

Skrócony JSON jest przeznaczony dla agentów (każdy dostępny magazyn niesie ze sobą przepis pobierania; nierozwiązane elementy niosą te same instrukcje naprawcze i komunikat doktora). --code-workspace dodatkowo zapisuje plik przestrzeni roboczej VS Code zawierający katalog główny oraz dostępne magazyny (foldery ref:<id>) — jedyny zapis, który wykonuje to polecenie, odmawiany bez --force, jeśli plik istnieje. Niedostępne elementy są zgłaszane, nigdy zgadywane.

„Kontekst roboczy” to zbiór złożony; pole context: w openspec/config.yaml to tło projektu wstrzykiwane do instrukcji — dwie różne rzeczy. openspec doctor odpowiada, czy zbiór jest zdrowy; openspec context odpowiada, jaki jest zbiór.

Osobiste zestawy robocze

Beta. Zestawy robocze są częścią nowej powierzchni beta; polecenia, flagi i formaty plików mogą zmieniać kształt między wydaniami. Opis przejścia znajdziesz w przewodniku po magazynach.

Zestaw roboczy to osobisty, nazwany widok folderów, nad którymi pracujesz razem — korzeń planowania plus cokolwiek innego, co wybierzesz — przechowywany na twojej maszynie i otwierany ponownie po nazwie w twoim narzędziu. Jest czysto lokalny: nigdy nie jest committowany, nigdy nie udostępniany, nigdy nie wyprowadzany z deklaracji, a usunięcie go nigdy nie dotyka folderów składowych.

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 przeprowadza krótki proces z przewodnikiem (lub przyjmuje flagi --member nieinteraktywnie; pierwszy członek jest głównym — sesje zaczynają się tam). open uruchamia wybrane narzędzie: edytory (VS Code, Cursor) otwierają okno z każdym członkiem i wracają; agenci CLI (Claude Code, codex) przejmują ten terminal jako sesję z każdym dołączonym członkiem i bez wstępnie wypełnionego promptu, kończąc się, gdy wyjdziesz. Brakujący folder członkowski w momencie otwarcia jest pomijany z notatką; reszta się otwiera. Zapisane preferencje narzędzia można nadpisać przy każdym otwarciu za pomocą --tool.

Wsparcie nowego narzędzia to konfiguracja, nie kod. Każde narzędzie należy do jednego z dwóch stylów uruchamiania — workspace-file (uruchamiane z wygenerowanym plikiem .code-workspace) lub attach-dirs (jedna flaga dołączania na członka) — a klucz openers w globalnym config.json (otwórz go za pomocą openspec config edit) dodaje narzędzia lub dostosowuje wbudowane według pola:

json

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

Cały stan zestawów roboczych znajduje się w folderze worksets/ globalnego katalogu danych (zapisane widoki plus wygenerowane pliki <name>.code-workspace, regenerowane przy każdym otwarciu); usunięcie tego folderu usuwa wszelkie ślady.

Polecenia przeglądania

`openspec list`

Wyświetla zmiany lub specyfikacje w twoim projekcie.

openspec list [options]

Opcje:

Opcja	Opis
`--specs`	Wyświetla specyfikacje zamiast zmian
`--changes`	Wyświetla zmiany (domyślnie)
`--sort <order>`	Sortuj według `recent` (domyślnie) lub `name`
`--json`	Wypisuje dane jako JSON

Przykłady:

bash

# Wyświetl wszystkie aktywne zmiany
openspec list

# Wyświetl wszystkie specyfikacje
openspec list --specs

# Wyjście JSON dla skryptów
openspec list --json

Wyjście (tekstowe):

Zmiany:
  add-dark-mode     Brak zadań      przed chwilą

`openspec view`

Wyświetla interaktywny panel do eksploracji specyfikacji i zmian.

openspec view

Otwiera interfejs terminalowy do nawigacji po specyfikacjach i zmianach w twoim projekcie.

`openspec show`

Wyświetla szczegóły zmiany lub specyfikacji.

openspec show [item-name] [options]

Argumenty:

Argument	Wymagany	Opis
`item-name`	Nie	Nazwa zmiany lub specyfikacji (pyta, jeśli pominięto)

Opcje:

Opcja	Opis
`--type <type>`	Typ: `change` lub `spec` (automatycznie wykrywane, jeśli jednoznaczne)
`--json`	Wypisuje dane jako JSON
`--no-interactive`	Wyłącza monity interaktywne

Opcje specyficzne dla zmiany:

Opcja	Opis
`--deltas-only`	Pokaż tylko specyfikacje delta (tryb JSON)

Opcje specyficzne dla specyfikacji:

Opcja	Opis
`--requirements`	Pokaż tylko wymagania, pomiń scenariusze (tryb JSON)
`--no-scenarios`	Wyklucz zawartość scenariuszy (tryb JSON)
`-r, --requirement <id>`	Pokaż konkretne wymaganie wg indeksu (licząc od 1) (tryb JSON)

Przykłady:

bash

# Wybór interaktywny
openspec show

# Pokaż konkretną zmianę
openspec show add-dark-mode

# Pokaż konkretną specyfikację
openspec show auth --type spec

# Wyjście JSON do parsowania
openspec show add-dark-mode --json

Polecenia walidacji

`openspec validate`

Waliduj zmiany i specyfikacje pod kątem problemów strukturalnych oraz sprawdź wymagania MODIFIED zmiany względem głównych specyfikacji, które mają zostać zastąpione.

openspec validate [item-name] [options]

Zmiana z zerową liczbą delt specyfikacji nie przechodzi walidacji, chyba że jej plik .openspec.yaml deklaruje skip_specs: true (dla czystych refaktoryzacji, narzędzi lub prac dokumentacyjnych — patrz Przepis 5).

Argumenty:

Argument	Wymagany	Opis
`item-name`	Nie	Konkretny element do walidacji (wyświetla prompt, jeśli pominięty)

Opcje:

Opcja	Opis
`--all`	Waliduj wszystkie zmiany i specyfikacje
`--changes`	Waliduj wszystkie zmiany
`--specs`	Waliduj wszystkie specyfikacje
`--archived`	Waliduj, że archiwizowane zmiany mają wszystkie zadania ukończone (do lintingu przed commit)
`--type <type>`	Określ typ, gdy nazwa jest niejednoznaczna: `change` lub `spec`
`--strict`	Włącz tryb ścisłej walidacji
`--json`	Wyświetl wynik w formacie JSON
`--concurrency <n>`	Maksymalna liczba równoległych walidacji (domyślnie: 6 lub zmienna środowiskowa `OPENSPEC_CONCURRENCY`)
`--no-interactive`	Wyłącz prompty

--archived ma własny zakres: nie waliduje delt specyfikacji (już zastosowanych w momencie archiwizacji), lecz weryfikuje, że każda zmiana pod changes/archive/ ma wszystkie checkboxy w tasks.md zaznaczone, kończąc z kodem innym niż zero, jeśli którykolwiek jest niezaznaczony. Wykrywa to zmiany archiwizowane z niedokończoną pracą — przydatne w hooku przed commit.

Przykłady:

bash

# Walidacja interaktywna
openspec validate

# Waliduj konkretną zmianę
openspec validate add-dark-mode

# Waliduj wszystkie zmiany
openspec validate --changes

# Waliduj wszystko z wynikiem w JSON (do CI/skryptów)
openspec validate --all --json

# Ścisła walidacja z zwiększoną równoległością
openspec validate --all --strict --concurrency 12

# Błąd, jeśli jakakolwiek archiwizowana zmiana ma niezaznaczone zadania
openspec validate --archived

Wyjście (tekst):

Walidacja add-dark-mode...
  ✓ proposal.md poprawny
  ✓ specs/ui/spec.md poprawny
  ⚠ design.md: brak sekcji "Technical Approach"

Znaleziono 1 ostrzeżenie

Wyjście (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
  }
}

Polecenia cyklu życia

`openspec archive`

Archiwizuj ukończoną zmianę i scal delta specyfikacje z głównymi specyfikacjami.

openspec archive [change-name] [options]

Argumenty:

Argument	Wymagany	Opis
`change-name`	Nie	Zmiana do archiwizacji (wyświetla prompt, jeśli pominięty; wymagany, gdy nic nie może odpowiedzieć na prompt)

Opcje:

Opcja	Opis
`-y, --yes`	Pomiń prompty potwierdzenia. Wymagane, gdy nic nie może na nich odpowiedzieć — agent AI, zadanie CI lub dowolne uruchomienie z zamkniętym stdin
`--skip-specs`	Pomiń aktualizacje specyfikacji przy jednym uruchomieniu archiwizacji. Zmiana, która trwale nie ma delt specyfikacji, powinna zamiast tego zadeklarować `skip_specs: true` w swoim pliku `.openspec.yaml` — archiwizuje się bez flagi
`--no-validate`	Pomiń walidację (wymaga potwierdzenia). Wyłącza również wycofywanie funkcji — bez werdyktu walidatora nic nie jest wycofywane

Przykłady:

bash

# Archiwizacja interaktywna (pyta o zmianę, potem potwierdza)
openspec archive

# Archiwizuj konkretną zmianę
openspec archive add-dark-mode

# Archiwizuj bez promptów (agenci, CI, skrypty)
openspec archive add-dark-mode --yes

# Archiwizuj zmianę narzędziową, która nie wpływa na specyfikacje
openspec archive update-ci-config --skip-specs

Wycofanie funkcji: Dodaj znacznik wycofania do metadanych zmiany:

yaml

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

Następnie archiwizuj zmianę normalnie:

bash

openspec archive retire-legacy --yes

Gdy zmiana usuwa ostatnie wymaganie funkcji, OpenSpec usuwa jej aktywny plik spec.md. Inne delta funkcji w tej samej zmianie nadal aktualizują swoje główne specyfikacje. Bez znacznika archiwizacja zatrzymuje się przed zmianą jakichkolwiek plików i informuje, aby go dodać.

Co robi:

Waliduje zmianę (chyba że --no-validate)
Wyświetla prompt potwierdzenia (chyba że --yes)
Rezerwuje miejsce docelowe archiwum przed zmianą jakiejkolwiek głównej specyfikacji
Waliduje i scala aktywne delta specyfikacje do openspec/specs/ — funkcja, której ostatnie wymaganie zmiana usuwa, jest wycofywana, a jej plik specyfikacji usuwany, ale tylko wtedy, gdy .openspec.yaml zmiany deklaruje retire_capabilities: true obok schema:
Przenosi folder zmiany do openspec/changes/archive/YYYY-MM-DD-<name>/
Jeśli mutacja specyfikacji lub ostateczne przeniesienie nie powiedzie się przed zabezpieczeniem kompletnego archiwum, przywraca specyfikacje i pozostawia lub zwraca zmianę na jej aktywnej ścieżce
Jeśli zweryfikowana kopia zapasowa zostanie ukończona, ale sprzątanie źródła tymczasowego nie powiedzie się, zachowuje kompletne archiwum i zatwierdzony stan specyfikacji w celu odzyskania

Bez terminala: agent AI, zadanie CI lub dowolne uruchomienie z zamkniętym stdin nie może odpowiedzieć na krok 2, więc archiwizacja zatrzymuje się przed dotknięciem czegokolwiek, kończy się kodem 1 i podaje polecenie do ponownego uruchomienia — openspec archive <name> --yes, z pozostałymi flagami, które przekazałeś. Przekazuj --yes (oraz nazwę zmiany) od razu, aby pominąć tę rundę.

Polecenia przepływu pracy

Te polecenia wspierają przepływ pracy OPSX oparty na artefaktach. Są przydatne zarówno dla ludzi sprawdzających postęp, jak i agentów określających kolejne kroki.

`openspec new change`

Tworzy katalog zmiany i opcjonalne metadane śledzone w repozytorium w wskazanym katalogu głównym OpenSpec.

bash

openspec new change <name> [options]

Nazwy zmian muszą używać małych liter w formacie kebab-case: małe litery, cyfry i pojedyncze łączniki. Nie mogą zawierać spacji, podkreśleń, wielkich liter, kolejnych łączników ani łączników na początku lub końcu. Cyfra na początku jest dozwolona, więc możesz poprzedzać nazwy, aby porządkować lub poziomować zmiany, na przykład 100-add-feature lub 00001-add-auth.

Opcje:

Opcja	Opis
`--description <text>`	Opis do dodania do pliku `index.md`
`--goal <text>`	Opcjonalne metadane celu do przechowania wraz ze zmianą
`--schema <name>`	Schemat przepływu pracy do użycia
`--store <id>`	Identyfikator magazynu do użycia jako katalog główny OpenSpec (magazyn to samodzielne repozytorium OpenSpec, które zarejestrowałeś)
`--json`	Wyjście w formacie JSON

Przykłady:

bash

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

`openspec status`

Wyświetla status ukończenia artefaktów dla zmiany.

openspec status [options]

Opcje:

Opcja	Opis
`--change <id>`	Nazwa zmiany (pyta, jeśli pominięto)
`--schema <name>`	Nadpisanie schematu (automatycznie wykrywane z konfiguracji zmiany)
`--json`	Wyjście w formacie JSON

Przykłady:

bash

# Interaktywne sprawdzenie statusu
openspec status

# Status dla konkretnej zmiany
openspec status --change add-dark-mode

# JSON do użycia przez agenta
openspec status --change add-dark-mode --json

Wyjście (tekst):

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

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

Zmiana deklarująca skip_specs: true pokazuje swój etap specyfikacji jako [~] specs (skipped: change declares skip_specs) i wyklucza go z licznika postępu.

Wyjście (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 informuje, czy każdy niepominięty artefakt planowania istnieje; pominięte artefakty są uznawane za spełnione bez ich tworzenia. Nie informuje o tym, czy zadania implementacji są ukończone. isComplete jest zachowany jako kompatybilny alias o tej samej wartości.

Artefakty są wymienione w kolejności zależności — zależność nigdy nie pojawia się po czynś, co jej wymaga — a artefakty, które stają się gotowe w tym samym czasie (specs i design w schemacie spec-driven wymagają tylko proposal), zachowują kolejność zadeklarowaną przez schemat, a nie alfabetyczną. Zatem pierwszy wpis ready to artefakt, który należy napisać jako następny.

`openspec instructions`

Pobiera wzbogacone instrukcje dotyczące tworzenia artefaktu lub stosowania zadań. Używane przez agentów AI do zrozumienia, co należy utworzyć dalej.

openspec instructions [artifact] [options]

Argumenty:

Argument	Wymagany	Opis
`artifact`	Nie	Identyfikator artefaktu lub powierzchnia wejściowa przepływu pracy: `apply` lub `archive`

Opcje:

Opcja	Opis
`--change <id>`	Nazwa zmiany (wymagana w trybie nieinteraktywnym)
`--schema <name>`	Nadpisanie schematu
`--json`	Wyjście w formacie JSON

Przypadki szczególne: Użyj apply, aby uzyskać instrukcje implementacji zadań. Użyj archive, aby pobrać bieżące, tylko do odczytu dane wejściowe archiwizacji (context i operationGuidance) dla prawidłowej zmiany; nie archiwizuje ani nie modyfikuje niczego.

Przykłady:

bash

# Pobierz instrukcje dla następnego artefaktu
openspec instructions --change add-dark-mode

# Pobierz instrukcje dla konkretnego artefaktu
openspec instructions design --change add-dark-mode

# Pobierz instrukcje apply/implementacji
openspec instructions apply --change add-dark-mode

# Pobierz bieżące dane wejściowe operacji archiwizacji bez archiwizowania
openspec instructions archive --change add-dark-mode --json

# JSON do użycia przez agenta
openspec instructions design --change add-dark-mode --json

Wyjście zawiera:

Treść szablonu dla artefaktu
Kontekst projektu z konfiguracji
Treść z artefaktów zależnych
Reguły per-artefakt z konfiguracji
Bieżący kontekst projektu i pasujące wskazówki operacyjne dla apply/archive

Dane wejściowe operacji są odczytywane z wskazanego repozytorium lub wybranego magazynu przy każdym wywołaniu. Kontekst projektu jest wymaganym wejściem na poziomie promptu: agenci czytają go i stosują istotne fakty, konwencje i ograniczenia projektu. Wskazówki operacyjne są opcjonalną, dodatkową poradą: agenci rozważają każdy wpis i stosują tylko te wpisy, które są odpowiednie i kompatybilne z wbudowanym przepływem pracy. Obie te wartości pozostają oddzielone od jawnych wyborów użytkownika, stanu sterowanego przez CLI, wbudowanych instrukcji i reguł artefaktów. Konfliktowy kontekst jest raportowany; konfliktowe lub nieodpowiednie wskazówki nie są stosowane, a powód jest wyjaśniany. Są to kontrakty behawioralne dla generowanych agentów, a nie egzekwowalne kontrole CLI. instructions archive zwraca tylko wybraną zmianę, opcjonalne dane wejściowe i metadane katalogu głównego; nie obejmuje statycznego przepływu pracy archiwizacji.

Dla artefaktu pominiętego przez skip_specs: true wyjście zawiera tylko ostrzeżenie (JSON dodaje pola skipped/warning) — artefakt nie może zostać utworzony.

`openspec templates`

Pokazuje rozwiązane ścieżki szablonów dla wszystkich artefaktów w schemacie.

openspec templates [options]

Opcje:

Opcja	Opis
`--schema <name>`	Schemat do sprawdzenia (domyślnie: `spec-driven`)
`--json`	Wyjście w formacie JSON

Przykłady:

bash

# Pokazuje ścieżki szablonów dla domyślnego schematu
openspec templates

# Pokazuje szablony dla niestandardowego schematu
openspec templates --schema my-workflow

# JSON do użycia programistycznego
openspec templates --json

Wyjście (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`

Wyświetla listę dostępnych schematów przepływu pracy wraz z ich opisami i przepływami artefaktów.

openspec schemas [options]

Opcje:

Opcja	Opis
`--json`	Wyjście w formacie JSON
`--store <id>`	Użyj zarejestrowanego magazynu jako katalogu głównego OpenSpec

Przykład:

bash

openspec schemas

Wyjście:

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

Polecenia schematów

Polecenia do tworzenia i zarządzania niestandardowymi schematami przepływów pracy.

`openspec schema init`

Utwórz nowy schemat lokalny dla projektu.

openspec schema init <name> [options]

Argumenty:

Argument	Wymagany	Opis
`name`	Tak	Nazwa schematu (kebab-case)

Opcje:

Opcja	Opis
`--description <text>`	Opis schematu
`--artifacts <list>`	Rozdzielone przecinkami identyfikatory artefaktów (domyślnie: `proposal,specs,design,tasks`)
`--default`	Ustaw jako domyślny schemat projektu
`--no-default`	Nie pytaj o ustawienie jako domyślny
`--force`	Nadpisz istniejący schemat
`--json`	Wyjście w formacie JSON

Przykłady:

bash

# Interaktywne tworzenie schematu
openspec schema init research-first

# Nieinteraktywne z określonymi artefaktami
openspec schema init rapid \
  --description "Szybki przepływ iteracji" \
  --artifacts "proposal,tasks" \
  --default

Co tworzy:

openspec/schemas/<name>/
├── schema.yaml           # Definicja schematu
└── templates/
    ├── proposal.md       # Szablon dla każdego artefaktu
    ├── specs.md
    ├── design.md
    └── tasks.md

`openspec schema fork`

Skopiuj istniejący schemat do swojego projektu w celu dostosowania.

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

Argumenty:

Argument	Wymagany	Opis
`source`	Tak	Schemat do skopiowania
`name`	Nie	Nowa nazwa schematu (domyślnie: `<source>-custom`)

Opcje:

Opcja	Opis
`--force`	Nadpisz istniejące miejsce docelowe
`--json`	Wyjście w formacie JSON

Przykład:

bash

# Skopiuj wbudowany schemat spec-driven
openspec schema fork spec-driven my-workflow

`openspec schema validate`

Sprawdź strukturę schematu i szablony.

openspec schema validate [name] [options]

Argumenty:

Argument	Wymagany	Opis
`name`	Nie	Schemat do walidacji (waliduje wszystkie, jeśli pominięty)

Opcje:

Opcja	Opis
`--verbose`	Pokaż szczegółowe kroki walidacji
`--json`	Wyjście w formacie JSON

Przykład:

bash

# Walidacja konkretnego schematu
openspec schema validate my-workflow

# Walidacja wszystkich schematów
openspec schema validate

`openspec schema which`

Pokaż, skąd pochodzi schemat (przydatne do debugowania pierwszeństwa).

openspec schema which [name] [options]

Argumenty:

Argument	Wymagany	Opis
`name`	Nie	Nazwa schematu

Opcje:

Opcja	Opis
`--all`	Wyświetl wszystkie schematy wraz z ich źródłami
`--json`	Wyjście w formacie JSON

Przykład:

bash

# Sprawdź, skąd pochodzi schemat
openspec schema which spec-driven

Wyjście:

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

Pierwszeństwo schematów:

Projekt: openspec/schemas/<name>/
Użytkownik: ~/.local/share/openspec/schemas/<name>/
Pakiet: Wbudowane schematy

Polecenia konfiguracji

`openspec config`

Przeglądaj i modyfikuj globalną konfigurację OpenSpec.

openspec config <subcommand> [options]

Podkomendy:

Podkomenda	Opis
`path`	Pokaż lokalizację pliku konfiguracyjnego
`list`	Pokaż wszystkie bieżące ustawienia
`get <key>`	Pobierz konkretną wartość
`set <key> <value>`	Ustaw wartość
`unset <key>`	Usuń klucz
`reset`	Przywróć ustawienia domyślne
`edit`	Otwórz w `$EDITOR`
`profile [preset]`	Skonfiguruj profil przepływu pracy interaktywnie lub przez preset

Przykłady:

bash

# Pokaż ścieżkę pliku konfiguracyjnego
openspec config path

# Wyświetl wszystkie ustawienia
openspec config list

# Pobierz konkretną wartość
openspec config get telemetry.enabled

# Ustaw wartość (wyłącz anonimową telemetrię użycia)
openspec config set telemetry.enabled false

# Ustaw wartość tekstową jawnie
openspec config set user.name "My Name" --string

# Usuń niestandardowe ustawienie
openspec config unset user.name

# Ustaw domyślny magazyn na poziomie maszyny (fallback root, gdy brak --store,
# lokalnego root lub magazynu projektu: rozwiązywanie wskaźnika)
openspec config set defaultStore team-plans

# Zresetuj całą konfigurację
openspec config reset --all --yes

# Edytuj konfigurację w edytorze
openspec config edit

# Skonfiguruj profil za pomocą kreatora opartego na akcjach
openspec config profile

# Szybki preset: przełącz przepływy pracy na core (zachowuje tryb dostarczania)
openspec config profile core

Rezygnacja z telemetrii: telemetry.enabled domyślnie jest włączone, gdy nie ustawiono (model opt-out). Ustaw je na false, aby wyłączyć anonimowe statystyki użycia i sprawdzanie wersji openspec update. Zmienne środowiskowe mają pierwszeństwo nad konfiguracją: OPENSPEC_TELEMETRY=0, DO_NOT_TRACK=1, a wartość prawdziwa CI (np. true/1/yes) zawsze wyłącza telemetrię niezależnie od wartości konfiguracji.

openspec config profile zaczyna się od podsumowania bieżącego stanu, a następnie pozwala wybrać:

Zmień dostarczanie + przepływy pracy
Zmień tylko dostarczanie
Zmień tylko przepływy pracy
Zachowaj bieżące ustawienia (wyjście)

Jeśli zachowasz bieżące ustawienia, żadne zmiany nie są zapisywane i nie jest wyświetlany monit o aktualizację. Jeśli nie ma zmian w konfiguracji, ale bieżące pliki projektu nie są zgodne z globalnym profilem/dostarczaniem, OpenSpec wyświetli ostrzeżenie i zasugeruje openspec update. Naciśnięcie Ctrl+C również czysto anuluje przepływ (bez śladu stosu) i kończy działanie z kodem 130. W liście kontrolnej przepływów pracy [x] oznacza, że przepływ pracy jest wybrany w globalnej konfiguracji. Aby zastosować te wybory do plików projektu, uruchom openspec update (lub wybierz Zastosować zmiany do tego projektu teraz? po wyświetleniu monitu w projekcie).

Interaktywne przykłady:

bash

# Aktualizacja tylko dostarczania
openspec config profile
# wybierz: Zmień tylko dostarczanie
# wybierz dostarczanie: Tylko Skills

# Aktualizacja tylko przepływów pracy
openspec config profile
# wybierz: Zmień tylko przepływy pracy
# przełącz przepływy pracy w liście kontrolnej, a następnie potwierdź

Polecenia narzędziowe

`openspec feedback`

Wyślij opinię o OpenSpec. Tworzy zgłoszenie na GitHub.

openspec feedback <message> [options]

Argumenty:

Argument	Wymagany	Opis
`message`	Tak	Podsumowanie opinii; długi tekst jest skracany w tytule zgłoszenia i zachowany w treści

Opcje:

Opcja	Opis
`--body <text>`	Dodatkowe szczegóły zawarte po podsumowaniu

Wymagania: GitHub CLI (gh) musi być zainstalowane i uwierzytelnione.

Przykład:

bash

openspec feedback "Dodaj obsługę niestandardowych typów artefaktów" \
  --body "Chciałbym definiować własne typy artefaktów poza wbudowanymi."

`openspec completion`

Zarządzanie uzupełnianiem powłoki dla CLI OpenSpec.

openspec completion <subcommand> [shell]

Podkomendy:

Podkomenda	Opis
`generate [shell]`	Wypisz skrypt uzupełniania na stdout
`install [shell]`	Zainstaluj uzupełnianie dla swojej powłoki
`uninstall [shell]`	Usuń zainstalowane uzupełniania

Obsługiwane powłoki: bash, zsh, fish, powershell

Przykłady:

bash

# Zainstaluj uzupełniania (automatyczne wykrywanie powłoki)
openspec completion install

# Zainstaluj dla konkretnej powłoki
openspec completion install zsh

# Wygeneruj skrypt do ręcznej instalacji (bash)
openspec completion generate bash > ~/.bash_completion.d/openspec

# Odinstaluj
openspec completion uninstall

Windows (PowerShell): Zainstaluj uzupełniania dla bieżącego hosta PowerShell:

powershell

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

$env:PROFILE informuje OpenSpec, który profil skonfigurować w tej sesji. Instalator tworzy brakujące katalogi profilu i dodaje zarządzany blok, który ładuje OpenSpecCompletion.ps1. Ponowne załadowanie profilu natychmiast włącza uzupełniania.

Aby odinstalować z bieżącego hosta, uruchom:

powershell

$env:PROFILE = $PROFILE
openspec completion uninstall powershell

Uruchom ponownie PowerShell po odinstalowaniu, aby wyczyścić uzupełniania z bieżącej sesji.

Uzupełniania są opcjonalne. CLI wspomina o nich raz, na stderr, przy pierwszym uruchomieniu polecenia w terminalu interaktywnym, i nigdy więcej — pozostaje też ciche, jeśli masz już zainstalowane uzupełniania. Ustaw OPENSPEC_NO_COMPLETIONS=1, aby całkowicie pominąć tę wskazówkę.

Kody wyjścia

Kod	Znaczenie
`0`	Sukces
`1`	Błąd (błąd walidacji, brakujące pliki itp.)

Zmienne środowiskowe

Zmienna	Opis
`OPENSPEC_TELEMETRY`	Ustaw na `0`, aby wyłączyć telemetrię i sprawdzanie wersji `openspec update` (nadpisuje `telemetry.enabled` w globalnej konfiguracji)
`DO_NOT_TRACK`	Ustaw na `1`, aby wyłączyć telemetrię i sprawdzanie wersji `openspec update` (standardowy sygnał DNT; nadpisuje konfigurację)
`OPENSPEC_CONCURRENCY`	Domyślna współbieżność dla walidacji zbiorczej (domyślnie: 6)
`EDITOR` lub `VISUAL`	Edytor dla `openspec config edit`
`NO_COLOR`	Wyłącza kolorowe wyjście, gdy ustawione
`OPENSPEC_NO_ANIMATION`	Wyłącza animację powitalną `openspec init`, gdy ustawione
`OPENSPEC_NO_COMPLETIONS`	Ustaw na `1`, aby pominąć jednorazową wskazówkę o uzupełnianiu powłoki
`OPENSPEC_NO_UPDATE_CHECK`	Wyłącza sprawdzanie `openspec update` dla nowszej opublikowanej wersji CLI, gdy ustawione (dowolna wartość, w tym pusta). Pomijane również, gdy ustawione `CI` (chyba że `false`/`0`/`no`/`off`) lub `NODE_ENV=test`
`npm_config_registry`	Rejestr, o który pyta sprawdzanie wersji `openspec update`. Musi być URL `http(s)` lub używa `https://registry.npmjs.org`. Żaden plik `.npmrc` nie jest czytany

Powiązana dokumentacja

Polecenia - Polecenia AI slash (/opsx:propose, /opsx:apply itp.)
Przepływy pracy - Typowe wzorce i kiedy używać każdego polecenia
Dostosowywanie - Twórz niestandardowe schematy i szablony
Rozpoczęcie pracy - Przewodnik konfiguracji po raz pierwszy

Odniesienie CLI ​

Podsumowanie ​

Polecenia dla człowieka i dla agenta ​

Polecenia tylko dla człowieka ​

Polecenia kompatybilne z agentem ​

Opcje globalne ​

Polecenia konfiguracji ​

openspec init ​

openspec update ​

Store (samodzielne repozytoria OpenSpec) ​

openspec store setup ​

openspec store register ​

openspec store unregister ​

openspec store remove ​

openspec store list ​

openspec store doctor ​

Odwoływanie się do store z projektu ​

Rejestrowanie skąd store jest klonowany ​

Deklarowanie domyślnego store ​

Doktor (kondycja relacji) ​

Kontekst roboczy (zbiór złożony) ​

Osobiste zestawy robocze ​

Polecenia przeglądania ​

openspec list ​

openspec view ​

openspec show ​

Polecenia walidacji ​

openspec validate ​

Polecenia cyklu życia ​

openspec archive ​

Polecenia przepływu pracy ​

openspec new change ​

openspec status ​

openspec instructions ​

openspec templates ​

openspec schemas ​

Polecenia schematów ​

openspec schema init ​

openspec schema fork ​

openspec schema validate ​

openspec schema which ​

Polecenia konfiguracji ​

openspec config ​

Polecenia narzędziowe ​

openspec feedback ​

openspec completion ​

Kody wyjścia ​

Zmienne środowiskowe ​

Powiązana dokumentacja ​

Odniesienie CLI

Podsumowanie

Polecenia dla człowieka i dla agenta

Polecenia tylko dla człowieka

Polecenia kompatybilne z agentem

Opcje globalne

Polecenia konfiguracji

`openspec init`

`openspec update`

Store (samodzielne repozytoria OpenSpec)

`openspec store setup`

`openspec store register`

`openspec store unregister`

`openspec store remove`

`openspec store list`

`openspec store doctor`

Odwoływanie się do store z projektu

Rejestrowanie skąd store jest klonowany

Deklarowanie domyślnego store

Doktor (kondycja relacji)

Kontekst roboczy (zbiór złożony)

Osobiste zestawy robocze

Polecenia przeglądania

`openspec list`

`openspec view`

`openspec show`

Polecenia walidacji

`openspec validate`

Polecenia cyklu życia

`openspec archive`

Polecenia przepływu pracy

`openspec new change`

`openspec status`

`openspec instructions`

`openspec templates`

`openspec schemas`

Polecenia schematów

`openspec schema init`

`openspec schema fork`

`openspec schema validate`

`openspec schema which`

Polecenia konfiguracji

`openspec config`

Polecenia narzędziowe

`openspec feedback`

`openspec completion`

Kody wyjścia

Zmienne środowiskowe

Powiązana dokumentacja