Polecenia

To jest odniesienie do poleceń slash OpenSpec. Polecenia te są wywoływane w interfejsie czatu twojego asystenta programowania AI (np. Claude Code, Cursor, Devin Desktop).

Wzorce przepływów pracy i informacje, kiedy używać danego polecenia, znajdziesz w Workflows. Polecenia CLI znajdziesz w CLI.

Niniejsze strony używają /opsx:<command> jako kanonicznej nazwy. Niektóre narzędzia zapisują ją inaczej — Cursor i GitHub Copilot rejestrują /opsx-propose, Codex używa $openspec-propose — sprawdź How To Invoke dla swojego narzędzia. Pliki generowane przez OpenSpec już korzystają z właściwej formy.

Szybki przegląd

Domyślna szybka ścieżka (profil `core`)

Polecenie	Cel
`/opsx:propose`	Utwórz zmianę i generuj artefakty planistyczne w jednym kroku
`/opsx:explore`	Przeanalizuj pomysły przed podjęciem decyzji o zmianie
`/opsx:apply`	Wdrażaj zadania wynikające ze zmiany
`/opsx:update`	Popraw artefakty planistyczne zmiany i zachowaj ich spójność
`/opsx:sync`	Scal specyfikacje delta z głównymi specyfikacjami
`/opsx:archive`	Zarchiwizuj zakończoną zmianę

Polecenia rozszerzonego przepływu pracy (wybór niestandardowego przepływu)

Polecenie	Cel
`/opsx:new`	Rozpocznij szkielet nowej zmiany
`/opsx:continue`	Utwórz kolejny artefakt na podstawie zależności
`/opsx:ff`	Szybkie przejście: utwórz wszystkie artefakty planistyczne za jednym razem
`/opsx:verify`	Zweryfikuj, czy implementacja jest zgodna z artefaktami
`/opsx:bulk-archive`	Zarchiwizuj wiele zmian jednocześnie
`/opsx:onboard`	Samouczek z przewodnikiem po całym przepływie pracy

Domyślnym profilem globalnym jest core. Aby włączyć polecenia rozszerzonego przepływu pracy, uruchom openspec config profile, wybierz workflows, a następnie uruchom openspec update w swoim projekcie.

Dokumentacja poleceń

`/opsx:propose`

Utwórz nową zmianę i wygeneruj artefakty planowania w jednym kroku. To domyślne polecenie startowe w profilu core.

Składnia:

text

/opsx:propose [nazwa-zmiany-lub-opis]

Argumenty:

Argument	Wymagany	Opis
`nazwa-zmiany-lub-opis`	Nie	Nazwa w formacie kebab-case lub opis zmiany zwykłym językiem

Co robi:

Tworzy openspec/changes/<nazwa-zmiany>/
Generuje artefakty potrzebne przed implementacją (dla spec-driven: propozycję, specyfikacje, projekt, zadania)
Zatrzymuje się, gdy zmiana jest gotowa do /opsx:apply

Przykład:

text

Ty: /opsx:propose add-dark-mode

AI:  Utworzono openspec/changes/add-dark-mode/
     ✓ proposal.md
     ✓ specs/ui/spec.md
     ✓ design.md
     ✓ tasks.md
     Gotowe do implementacji. Uruchom /opsx:apply.

Wskazówki:

Użyj tego polecenia, aby uzyskać najszybszą ścieżkę end-to-end
Jeśli chcesz pełną kontrolę nad artefaktami krok po kroku, włącz rozszerzone przepływy pracy i użyj /opsx:new + /opsx:continue

`/opsx:explore`

Zacznij tutaj, gdy nie jesteś pewien. Explore to bezpieczny partner do myślenia: czyta Twój kod, porównuje opcje i przekształca mglisty pomysł w konkretny plan, zanim powstanie jakakolwiek zmiana. Jest dostępny w domyślnym profilu. Pełny opis i więcej przykładów znajdziesz w przewodniku Explore First.

Przemyśl pomysły, zbadaj problemy i wyjaśnij wymagania przed podjęciem decyzji o zmianie.

Składnia:

/opsx:explore [temat]

Argumenty:

Argument	Wymagany	Opis
`temat`	Nie	Co chcesz zbadać lub sprawdzić

Co robi:

Rozpoczyna eksploracyjną rozmowę bez wymaganej struktury
Bada bazę kodu, aby odpowiedzieć na pytania
Porównuje opcje i podejścia
Tworzy diagramy wizualne, aby wyjaśnić myślenie
Może przejść do /opsx:propose (domyślnie) lub /opsx:new (rozszerzony przepływ pracy), gdy wnioski się skrystalizują

Przykład:

text

Ty: /opsx:explore

AI:  Co chciałbyś zbadać?

Ty: Jak powinniśmy obsłużyć uwierzytelnianie dla aplikacji mobilnej?

AI:  Pozwól, że zbadam Twoją obecną konfigurację uwierzytelniania...
     [Analizuje bazę kodu]

     Widzę, że używasz uwierzytelniania sesyjnego dla aplikacji webowej.
     Dla aplikacji mobilnej mamy trzy główne opcje:

     1. Tokeny JWT (bezstanowe, działają offline)
     2. OAuth2 (jeśli potrzebujesz logowania przez zewnętrznych dostawców)
     3. Rozszerzenie obecnych sesji (prostsze, ale wymaga połączenia)

     Twoje API ma już skonfigurowany CORS. Który kierunek Cię interesuje?

Ty: Wybierzmy JWT. Czy możemy rozpocząć zmianę dla tego?

AI:  Gotowe, gdy będziesz. Uruchom /opsx:propose add-jwt-auth, aby zacząć.

Wskazówki:

Użyj, gdy wymagania są niejasne lub musisz coś zbadać
Podczas eksploracji nie są tworzone żadne artefakty
Dobre do porównywania wielu podejść przed podjęciem decyzji
Może czytać pliki i przeszukiwać bazę kodu

`/opsx:new`

Rozpocznij nowy szkielet zmiany. Tworzy folder zmiany i czeka, aż wygenerujesz artefakty za pomocą /opsx:continue lub /opsx:ff.

To polecenie jest częścią rozszerzonego zestawu przepływów pracy (nie jest zawarte w domyślnym profilu core).

Składnia:

/opsx:new [nazwa-zmiany] [--schema <nazwa-schematu>]

Argumenty:

Argument	Wymagany	Opis
`nazwa-zmiany`	Nie	Nazwa folderu zmiany (monituje o podanie, jeśli nie jest podana)
`--schema`	Nie	Schemat przepływu pracy do użycia (domyślnie: z konfiguracji lub `spec-driven`)

Co robi:

Tworzy katalog openspec/changes/<nazwa-zmiany>/
Tworzy plik metadanych .openspec.yaml w folderze zmiany
Pokazuje pierwszy szablon artefaktu gotowy do utworzenia
Pyta o nazwę zmiany i schemat, jeśli nie są podane

Co tworzy:

openspec/changes/<nazwa-zmiany>/
└── .openspec.yaml    # Metadane zmiany (schemat, data utworzenia)

Przykład:

Ty: /opsx:new add-dark-mode

AI:  Utworzono openspec/changes/add-dark-mode/
     Schemat: spec-driven

     Gotowe do utworzenia: proposal
     Użyj /opsx:continue, aby je utworzyć, lub /opsx:ff, aby utworzyć wszystkie artefakty.

Wskazówki:

Używaj opisowych nazw: add-feature, fix-bug, refactor-module
Unikaj ogólnych nazw, takich jak update, changes, wip
Schemat można również ustawić w konfiguracji projektu (openspec/config.yaml)

`/opsx:continue`

Utwórz kolejny artefakt w łańcuchu zależności. Tworzy jeden artefakt na raz, aby zapewnić postęp przyrostowy.

Składnia:

/opsx:continue [nazwa-zmiany]

Argumenty:

Argument	Wymagany	Opis
`nazwa-zmiany`	Nie	Którą zmianę kontynuować (wnioskowane z kontekstu, jeśli nie podano)

Co robi:

Odczytuje graf zależności artefaktów
Pokazuje, które artefakty są gotowe, a które zablokowane
Tworzy pierwszy gotowy artefakt
Czyta pliki zależności dla kontekstu
Pokazuje, co stanie się dostępne po utworzeniu

Przykład:

Ty: /opsx:continue

AI:  Zmiana: add-dark-mode

     Status artefaktów:
     ✓ proposal    (zrobione)
     ◆ specs       (gotowe)
     ◆ design      (gotowe)
     ○ tasks       (zablokowane - wymaga: specs, design)

     Tworzenie specs...

     [Czyta proposal.md, tworzy specs na podstawie wymagań]

     ✓ Utworzono openspec/changes/add-dark-mode/specs/ui/spec.md

     Teraz dostępne: design
     Uruchom /opsx:continue, aby utworzyć kolejny artefakt.

Wskazówki:

Użyj, gdy chcesz przejrzeć każdy artefakt przed kontynuowaniem
Dobre dla złożonych zmian, gdzie chcesz mieć kontrolę
Wiele artefaktów może stać się gotowych jednocześnie
Możesz edytować utworzone artefakty przed kontynuowaniem

`/opsx:ff`

Szybkie przewinięcie przez tworzenie artefaktów. Tworzy wszystkie artefakty planowania naraz.

Składnia:

/opsx:ff [nazwa-zmiany]

Argumenty:

Argument	Wymagany	Opis
`nazwa-zmiany`	Nie	Którą zmianę przewinąć do przodu (wnioskowane z kontekstu, jeśli nie podano)

Co robi:

Tworzy wszystkie artefakty w kolejności zależności
Śledzi postęp za pomocą listy zadań
Zatrzymuje się, gdy wszystkie artefakty apply-required są ukończone
Czyta każdą zależność przed utworzeniem następnego artefaktu

Przykład:

Ty: /opsx:ff add-dark-mode

AI:  Przewijanie do przodu add-dark-mode...

     ✓ Tworzenie proposal.md
     ✓ Tworzenie specs/ui/spec.md
     ✓ Tworzenie design.md
     ✓ Tworzenie tasks.md

     Wszystkie artefakty planowania ukończone!
     Gotowe do implementacji. Uruchom /opsx:apply, aby rozpocząć.

Wskazówki:

Użyj, gdy masz jasny obraz tego, co budujesz
Szybsze niż /opsx:continue dla prostych zmian
Możesz nadal edytować artefakty później
Dobre dla małych i średnich funkcji

`/opsx:apply`

Implementuj zadania ze zmiany. Przepracowuje listę zadań, pisząc kod i odznaczając pozycje.

Składnia:

/opsx:apply [nazwa-zmiany]

Argumenty:

Argument	Wymagany	Opis
`nazwa-zmiany`	Nie	Którą zmianę zaimplementować (wnioskowane z kontekstu, jeśli nie podano)

Co robi:

Czyta tasks.md i identyfikuje nieukończone zadania
Przepracowuje zadania jedno po drugim
Pisze kod, tworzy pliki, uruchamia testy w razie potrzeby
Oznacza zadania jako ukończone checkboxami [x]

Przykład:

Ty: /opsx:apply

AI:  Implementacja add-dark-mode...

     Czytanie tasks.md:
     - [ ] 1.1 Utwórz ThemeContext
     - [ ] 1.2 Dodaj właściwości niestandardowe CSS
     - [ ] 1.3 Zaimplementuj trwałość localStorage

     Praca nad 1.1: Utwórz ThemeContext...
     [Tworzy src/context/ThemeContext.tsx]

     ✓ 1.1 Ukończone

     Praca nad 1.2: Dodaj właściwości niestandardowe CSS...
     [Aktualizuje src/styles/globals.css]

     ✓ 1.2 Ukończone
     ...

Wskazówki:

Może wznowić pracę tam, gdzie przerwano, jeśli zostanie przerwane
Użyj do równoległych zmian, podając nazwę zmiany
Stan ukończenia jest śledzony w checkboxach tasks.md

`/opsx:update`

Zrewiduj istniejące artefakty planowania zmiany i utrzymaj ich spójność. Tylko artefakty planowania — nigdy nie edytuje kodu.

Składnia:

text

/opsx:update [nazwa-zmiany]

Argumenty:

Argument	Wymagany	Opis
`nazwa-zmiany`	Nie	Którą zmianę zaktualizować (wnioskowane z kontekstu, jeśli nie podano)

Co robi:

Czyta artefakty zmiany przez openspec status --change <nazwa> --json
Stosuje żądaną rewizję lub przegląda artefakty pod kątem sprzeczności, jeśli nie podano żadnej
Uzgadnia inne istniejące artefakty w dowolnym kierunku (edycja projektu może wpłynąć z powrotem na propozycję)
Potwierdza każdą edycję z Tobą przed zapisaniem, jeden artefakt na raz
Kończy, zalecając następny krok: /opsx:continue (brakujące artefakty), /opsx:apply (przeniesienie zrewidowanego planu do kodu) lub /opsx:archive (wszystko gotowe)

Przykład:

text

Ty: /opsx:update add-dark-mode — przechowujemy motyw w cookie, a nie w localStorage

AI:  Czytanie artefaktów add-dark-mode...

     Projekt odnosi się do localStorage w dwóch miejscach; zadanie 1.3 obejmuje
     trwałość localStorage; propozycja nie wspomina o przechowywaniu.

     Proponowane rewizje:
     1. design.md — zamień decyzję o localStorage na przechowywanie w cookie
     2. tasks.md — przeformułuj zadanie 1.3 na trwałość w cookie

     Zastosować rewizję 1? (design.md)

Wskazówki:

Nie tworzy brakujących artefaktów — to zadanie /opsx:continue
Jeśli zmiana została już zaimplementowana, kontynuuj przez /opsx:apply, aby kod odpowiadał zrewidowanemu planowi
Jeśli Twoja rewizja zmienia intencję zmiany, rozpocznij od nowa z nową zmianą (zobacz Kiedy aktualizować, a kiedy zaczynać od nowa)

`/opsx:verify`

Sprawdź, czy implementacja odpowiada artefaktom zmiany. Weryfikuje kompletność, poprawność i spójność.

Składnia:

/opsx:verify [nazwa-zmiany]

Argumenty:

Argument	Wymagany	Opis
`nazwa-zmiany`	Nie	Którą zmianę zweryfikować (wnioskowane z kontekstu, jeśli nie podano)

Co robi:

Sprawdza trzy wymiary jakości implementacji
Przeszukuje bazę kodu w poszukiwaniu dowodów implementacji
Zgłasza problemy sklasyfikowane jako KRYTYCZNE, OSTRZEŻENIA lub SUGESTIE
Nie blokuje archiwizacji, ale uwypukla problemy

Wymiary weryfikacji:

Wymiar	Co weryfikuje
Kompletność	Wszystkie zadania wykonane, wszystkie wymagania zaimplementowane, scenariusze pokryte
Poprawność	Implementacja zgodna z intencją specyfikacji, przypadki brzegowe obsłużone
Spójność	Decyzje projektowe odzwierciedlone w kodzie, wzorce spójne

Przykład:

Ty: /opsx:verify

AI:  Weryfikacja add-dark-mode...

     KOMPLETNOŚĆ
     ✓ Wszystkie 8 zadań w tasks.md jest zaznaczonych
     ✓ Wszystkie wymagania w specs mają odpowiadający kod
     ⚠ Scenariusz „Wykrywanie preferencji systemu" nie ma pokrycia testami

     POPRAWNOŚĆ
     ✓ Implementacja zgodna z intencją specyfikacji
     ✓ Przypadki brzegowe ze scenariuszy są obsłużone
     ✓ Stany błędów zgodne z definicjami specyfikacji

     SPÓJNOŚĆ
     ✓ Decyzje projektowe odzwierciedlone w strukturze kodu
     ✓ Konwencje nazewnictwa zgodne z design.md
     ⚠ Projekt wspomina „zmienne CSS", ale implementacja używa klas Tailwind

     PODSUMOWANIE
     ─────────────────────────────
     Problemy krytyczne: 0
     Ostrzeżenia: 2
     Gotowe do archiwizacji: Tak (z ostrzeżeniami)

     Rekomendacje:
     1. Dodaj test dla wykrywania preferencji systemu
     2. Zaktualizuj design.md, aby odzwierciedlić użycie Tailwind, lub przeprowadź refaktoryzację do zmiennych CSS

Wskazówki:

Uruchom przed archiwizacją, aby wcześnie wykryć rozbieżności
Ostrzeżenia nie blokują archiwizacji, ale wskazują potencjalne problemy
Dobre do przeglądu pracy AI przed zatwierdzeniem
Może ujawnić rozbieżności między artefaktami a implementacją

`/opsx:sync`

Polecenie opcjonalne. Scal specyfikacje delta ze zmiany do głównych specyfikacji. Archiwizacja zaproponuje synchronizację, jeśli jest potrzebna, więc zwykle nie musisz uruchamiać tego ręcznie.

Składnia:

/opsx:sync [nazwa-zmiany]

Argumenty:

Argument	Wymagany	Opis
`nazwa-zmiany`	Nie	Którą zmianę zsynchronizować (wnioskowane z kontekstu, jeśli nie podano)

Co robi:

Czyta specyfikacje delta z folderu zmiany
Analizuje sekcje ADDED/MODIFIED/REMOVED/RENAMED
Scala zmiany do głównego katalogu openspec/specs/
Zachowuje istniejącą zawartość nieuwzględnioną w delcie
Nie archiwizuje zmiany (pozostaje aktywna)

Przykład:

text

Ty: /opsx:sync

AI:  Synchronizacja specyfikacji delta add-dark-mode...

     Czytanie: openspec/changes/add-dark-mode/specs/ui/spec.md
     Cel:      openspec/specs/ui/spec.md

     Zmiany do zastosowania:
     ✓ DODANE: wymaganie Theme Selection (2 scenariusze)
     ✓ DODANE: wymaganie Accessibility (1 scenariusz)

     Scalanie...
     ✓ openspec/specs/ui/spec.md zaktualizowane

     Zmiana pozostaje aktywna. Uruchom /opsx:archive, gdy będzie gotowa do zakończenia.

Kiedy używać ręcznie:

Scenariusz	Użyć synchronizacji?
Długotrwała zmiana, chcesz mieć specyfikacje w głównych przed archiwizacją	Tak
Wiele równoległych zmian wymaga zaktualizowanych bazowych specyfikacji	Tak
Chcesz podglądnąć/przejrzeć scalanie osobno	Tak
Szybka zmiana, idziesz prosto do archiwizacji	Nie (archiwizacja to obsłuży)

Wskazówki:

Synchronizacja jest inteligentna, a nie kopiuj-wklej
Może dodawać scenariusze do istniejących wymagań bez duplikowania
Zmiana pozostaje aktywna po synchronizacji (nie jest archiwizowana)
Większość użytkowników nigdy nie będzie musiała wywoływać tego bezpośrednio — archiwizacja zapyta, jeśli będzie potrzebne

`/opsx:archive`

Zarchiwizuj ukończoną zmianę. Finalizuje zmianę i przenosi ją do folderu archiwum.

Składnia:

/opsx:archive [nazwa-zmiany]

Argumenty:

Argument	Wymagany	Opis
`nazwa-zmiany`	Nie	Którą zmianę zarchiwizować (wnioskowane z kontekstu, jeśli nie podano)

Co robi:

Sprawdza status ukończenia artefaktów
Sprawdza ukończenie zadań (ostrzega, jeśli nieukończone)
Proponuje synchronizację specyfikacji delta, jeśli nie są jeszcze zsynchronizowane
Przenosi folder zmiany do openspec/changes/archive/YYYY-MM-DD-<nazwa>/
Zachowuje wszystkie artefakty dla śladu audytu

Przykład:

text

Ty: /opsx:archive

AI:  Archiwizacja add-dark-mode...

     Status artefaktów:
     ✓ proposal.md istnieje
     ✓ specs/ istnieje
     ✓ design.md istnieje
     ✓ tasks.md istnieje (8/8 zadań ukończonych)

     Specyfikacje delta: Nie zsynchronizowane
     → Zsynchronizować teraz? (zalecane)

Ty: Tak

AI:  ✓ Zsynchronizowano specyfikacje do openspec/specs/ui/spec.md
     ✓ Przeniesiono do openspec/changes/archive/2025-01-24-add-dark-mode/

     Zmiana zarchiwizowana pomyślnie.

Wskazówki:

Archiwizacja nie blokuje nieukończonych zadań, ale ostrzeże
Specyfikacje delta można zsynchronizować podczas archiwizacji lub wcześniej
Zarchiwizowane zmiany są zachowywane dla historii
Użyj /opsx:verify najpierw, aby wykryć problemy

`/opsx:bulk-archive`

Zarchiwizuj wiele ukończonych zmian naraz. Obsługuje konflikty specyfikacji między zmianami.

Składnia:

/opsx:bulk-archive [nazwy-zmian...]

Argumenty:

Argument	Wymagany	Opis
`nazwy-zmian`	Nie	Konkretne zmiany do zarchiwizowania (monituje o wybór, jeśli nie podano)

Co robi:

Listuje wszystkie ukończone zmiany
Weryfikuje każdą zmianę przed archiwizacją
Wykrywa konflikty specyfikacji między zmianami
Rozwiązuje konflikty, sprawdzając, co faktycznie zostało zaimplementowane
Archiwizuje w kolejności chronologicznej

Przykład:

Ty: /opsx:bulk-archive

AI:  Znaleziono 3 ukończone zmiany:
     - add-dark-mode (8/8 zadań ukończonych)
     - fix-login-bug (3/3 zadania ukończone)
     - update-footer (2/2 zadania ukończone)

     Sprawdzanie konfliktów specyfikacji...
     ⚠ add-dark-mode i update-footer obie dotyczą specs/ui/

     Sprawdzanie bazy kodu w celu rozwiązania...
     Obie zmiany są zaimplementowane. Scalę w kolejności chronologicznej:
     1. add-dark-mode (utworzona 20 stycznia)
     2. update-footer (utworzona 22 stycznia)

     Zarchiwizować wszystkie 3 zmiany?

Ty: Tak

AI:  ✓ Zarchiwizowano add-dark-mode
     ✓ Zarchiwizowano fix-login-bug
     ✓ Zarchiwizowano update-footer
     Specyfikacje scalone: add-dark-mode → update-footer

Wskazówki:

Dobre dla równoległych strumieni pracy
Rozwiązywanie konfliktów jest agentowe (sprawdza bazę kodu)
Zmiany są archiwizowane w kolejności utworzenia
Pyta przed nadpisaniem zawartości specyfikacji

`/opsx:onboard`

Prowadzone wprowadzenie przez pełny przepływ pracy OpenSpec. Interaktywny samouczek wykorzystujący Twoją faktyczną bazę kodu.

Składnia:

/opsx:onboard

Co robi:

Przeprowadza przez pełny cykl przepływu pracy z narracją
Skanuje Twoją bazę kodu w poszukiwaniu rzeczywistych możliwości ulepszeń
Tworzy rzeczywistą zmianę z prawdziwymi artefaktami
Implementuje rzeczywistą pracę (małe, bezpieczne zmiany)
Archiwizuje ukończoną zmianę
Wyjaśnia każdy krok na bieżąco

Fazy:

Powitanie i analiza bazy kodu
Znalezienie możliwości ulepszenia
Tworzenie zmiany (/opsx:new)
Pisanie propozycji
Tworzenie specyfikacji
Pisanie projektu
Tworzenie zadań
Implementacja zadań (/opsx:apply)
Weryfikacja implementacji
Archiwizacja zmiany
Podsumowanie i następne kroki

Przykład:

Ty: /opsx:onboard

AI:  Witaj w OpenSpec!

     Przeprowadzę Cię przez pełny przepływ pracy, używając Twojej faktycznej bazy kodu.
     Znajdziemy coś małego do ulepszenia, utworzymy odpowiednią zmianę,
     zaimplementujemy ją i zarchiwizujemy.

     Pozwól, że przeskanuję Twoją bazę kodu w poszukiwaniu możliwości...

     [Analizuje bazę kodu]

     Znalazłem kilka rzeczy, nad którymi moglibyśmy popracować:
     1. Dodanie walidacji wejścia do formularza kontaktowego
     2. Poprawa komunikatów błędów w przepływie uwierzytelniania
     3. Dodanie stanów ładowania do przycisków asynchronicznych

     Która Cię interesuje? (lub zaproponuj coś innego)

Wskazówki:

Najlepsze dla nowych użytkowników uczących się przepływu pracy
Używa prawdziwego kodu, a nie przykładowych zabawek
Tworzy prawdziwą zmianę, którą możesz zachować lub odrzucić
Zajmuje 15-30 minut do ukończenia

Składnia poleceń według narzędzia AI

Różne narzędzia AI używają nieco innej składni poleceń. Użyj formatu odpowiadającego Twojemu narzędziu:

Plik poleceń Twojego narzędzia	Przykład składni	Przykładowe narzędzia
`.../commands/opsx/<id>.*`	`/opsx:propose`, `/opsx:apply`	Claude Code, Gemini CLI, Crush
`.../opsx-<id>.*`	`/opsx-propose`, `/opsx-apply`	Cursor, Devin Desktop, Copilot (IDE), Trae, Oh My Pi
brak — tylko umiejętności	`/openspec-propose`, `/openspec-apply-change`	CodeArts, ForgeCode, Hermes, MiniMax Code, Mistral Vibe, Zed Agent, współdzielone `.agents`
brak — Kimi Code	`/skill:openspec-propose`	Kimi Code
brak — Codex CLI	`$openspec-propose`	Codex

Devin Desktop vs Devin Local: pliki .devin/workflows/opsx-*.md nadają Devin Desktop polecenie /opsx-propose. Devin Local nie ma workflow — użyj umiejętności, które OpenSpec zapisuje w .devin/skills/, np. /openspec-propose, które działają na obu agentach.

Intencja jest taka sama we wszystkich narzędziach, ale sposób prezentacji poleceń może się różnić w zależności od integracji. How To Invoke zawiera listę wszystkich obsługiwanych narzędzi; poniższa tabela pokazuje jedynie przykłady każdego wariantu.

Uwaga: Polecenia GitHub Copilot (.github/prompts/*.prompt.md) są dostępne wyłącznie w rozszerzeniach IDE (VS Code, JetBrains, Visual Studio). GitHub Copilot CLI nie obsługuje obecnie niestandardowych plików promptów — szczegóły i obejścia znajdziesz w Supported Tools.

Polecenia legacy

Te polecenia używają starszego przepływu pracy „wszystko naraz". Nadal działają, ale zalecane są polecenia OPSX.

Polecenie	Co robi
`/openspec:proposal`	Tworzy wszystkie artefakty naraz (propozycja, specyfikacje, projekt, zadania)
`/openspec:apply`	Wdraża zmianę
`/openspec:archive`	Archiwizuje zmianę

Kiedy używać poleceń legacy:

Istniejące projekty korzystające ze starego przepływu pracy
Proste zmiany, w których nie potrzebujesz inkrementalnego tworzenia artefaktów
Preferencja podejścia typu „wszystko albo nic"

Migracja do OPSX: Zmiany legacy można kontynuować za pomocą poleceń OPSX. Struktura artefaktów jest kompatybilna.

Rozwiązywanie problemów

"Change not found"

Polecenie nie mogło zidentyfikować, nad którą zmianą ma pracować.

Rozwiązania:

Określ nazwę zmiany wprost: /opsx:apply add-dark-mode
Sprawdź, czy folder zmiany istnieje: openspec list
Zweryfikuj, czy jesteś w odpowiednim katalogu projektu

"No artifacts ready"

Wszystkie artefakty są ukończone lub zablokowane przez brakujące zależności.

Rozwiązania:

Uruchom openspec status --change <name>, aby sprawdzić, co blokuje postęp
Sprawdź, czy wymagane artefakty istnieją
Najpierw utwórz brakujące artefakty zależności

"Schema not found"

Określony schemat nie istnieje.

Rozwiązania:

Wylistuj dostępne schematy: openspec schemas
Sprawdź pisownię nazwy schematu
Utwórz schemat, jeśli jest niestandardowy: openspec schema init <name>

Polecenia nie są rozpoznawane

Narzędzie AI nie rozpoznaje poleceń OpenSpec.

Rozwiązania:

Upewnij się, że OpenSpec jest zainicjalizowany: openspec init
Odtwórz umiejętności: openspec update
Sprawdź, czy istnieje katalog .claude/skills/ (dla Claude Code)
Uruchom ponownie narzędzie AI, aby załadować nowe umiejętności

Artefakty nie generują się poprawnie

AI tworzy niekompletne lub niepoprawne artefakty.

Rozwiązania:

Dodaj kontekst projektu w openspec/config.yaml
Dodaj reguły per artefakt dla bardziej szczegółowych wytycznych
Podaj więcej szczegółów w opisie zmiany
Użyj /opsx:continue zamiast /opsx:ff, aby uzyskać większą kontrolę

Kolejne kroki

Workflows — Typowe wzorce i kiedy używać każdego polecenia
CLI — Polecenia terminalowe do zarządzania i walidacji
Customization — Tworzenie niestandardowych schematów i workflow

Polecenia ​

Szybki przegląd ​

Domyślna szybka ścieżka (profil core) ​

Polecenia rozszerzonego przepływu pracy (wybór niestandardowego przepływu) ​

Dokumentacja poleceń ​

/opsx:propose ​

/opsx:explore ​

/opsx:new ​

/opsx:continue ​

/opsx:ff ​

/opsx:apply ​

/opsx:update ​

/opsx:verify ​

/opsx:sync ​

/opsx:archive ​

/opsx:bulk-archive ​

/opsx:onboard ​

Składnia poleceń według narzędzia AI ​

Polecenia legacy ​

Rozwiązywanie problemów ​

"Change not found" ​

"No artifacts ready" ​

"Schema not found" ​

Polecenia nie są rozpoznawane ​

Artefakty nie generują się poprawnie ​

Kolejne kroki ​

Polecenia

Szybki przegląd

Domyślna szybka ścieżka (profil `core`)

Polecenia rozszerzonego przepływu pracy (wybór niestandardowego przepływu)

Dokumentacja poleceń

`/opsx:propose`

`/opsx:explore`

`/opsx:new`

`/opsx:continue`

`/opsx:ff`

`/opsx:apply`

`/opsx:update`

`/opsx:verify`

`/opsx:sync`

`/opsx:archive`

`/opsx:bulk-archive`

`/opsx:onboard`

Składnia poleceń według narzędzia AI

Polecenia legacy

Rozwiązywanie problemów

"Change not found"

"No artifacts ready"

"Schema not found"

Polecenia nie są rozpoznawane

Artefakty nie generują się poprawnie

Kolejne kroki