Obsługiwane narzędzia
OpenSpec współpracuje z wieloma asystentami kodowania AI. Po uruchomieniu openspec init, OpenSpec konfiguruje wybrane narzędzia na podstawie aktywnego profilu/wyboru przepływu pracy oraz trybu dostarczania.
Jak to działa
Dla każdego wybranego narzędzia OpenSpec może zainstalować:
- Umiejętności (jeśli dostarczanie obejmuje umiejętności):
.../skills/openspec-*/SKILL.md - Polecenia (jeśli dostarczanie obejmuje polecenia): specyficzne dla narzędzia pliki poleceń
opsx-*
Codex obsługuje wyłącznie umiejętności: OpenSpec instaluje .agents/skills/openspec-*/SKILL.md dla Codex nawet gdy dostarczanie jest ustawione na commands, i nie generuje plików niestandardowych promptów Codex. Istniejące umiejętności zarządzane przez OpenSpec pod ścieżką legacy .codex/skills są synchronizowane po zapisaniu ich zamienników; pliki niestandardowe i rozbieżne są zachowywane.
Domyślnie OpenSpec używa profilu core, który obejmuje:
proposeexploreapplyupdatesyncarchive
Możesz włączyć rozszerzone przepływy pracy (new, continue, ff, verify, bulk-archive, onboard) za pomocą openspec config profile, a następnie uruchomić openspec update.
Jak wywoływać
Niniejsza dokumentacja używa /opsx:propose jako nazwy kanonicznej, ale każde narzędzie zapisuje ją w sposób, w jaki ładuje plik wygenerowany przez OpenSpec. Znajdź ścieżkę polecenia swojego narzędzia w Dokumentacji katalogów narzędzi poniżej, a następnie dopasuj jej postać tutaj.
| Plik polecenia zapisywany przez OpenSpec | Wpisujesz | Narzędzia |
|---|---|---|
.../commands/opsx/<id>.* — folder opsx/ tworzy przestrzeń nazw | /opsx:<id> | Claude Code, CodeBuddy, Crush, Gemini CLI, Lingma, Qoder, ZCode |
.../opsx-<id>.* — nazwa pliku jest poleceniem | /opsx-<id> | Każde inne narzędzie z wygenerowanymi plikami poleceń, z wyjątkiem Amazon Q i Devin |
.devin/workflows/opsx-<id>.md — odczytywany tylko przez jednego z dwóch agentów Devin | /opsx-<id> w Devin Desktop, /openspec-<skill> w Devin Local | Devin Desktop**** |
.amazonq/prompts/opsx-<id>.md — prompt, a nie polecenie | @opsx-<id> | Amazon Q Developer |
| brak — tylko umiejętności | /openspec-<skill> | CodeArts, ForgeCode, Hermes, MiniMax Code, Mistral Vibe, Zed Agent, współdzielone .agents |
| brak — Kimi Code | /skill:openspec-<skill> | Kimi Code |
| brak — Codex CLI | $openspec-<skill> | Codex (/openspec-<skill> nie jest rozpoznawane) |
Zatem /opsx:propose to /opsx-propose w Cursor, @opsx-propose w Amazon Q i $openspec-propose w Codex.
Dwie rzeczy różnią się niezależnie, dlatego wiersze się nie scalają:
- Nazwa. Wiersze 1–2 różnią się jedynie tym, jak plik nazywa polecenie, a rdzeń
opsx-<id>/opsx:<id>jest taki sam dla każdego narzędzia z wygenerowanymi plikami poleceń. - Opakowanie. Amazon Q ładuje swoje pliki do biblioteki promptów wywoływanej za pomocą
@. Narzędzia korzystające wyłącznie z umiejętności w ogóle nie generują plików poleceń, więc ich trzy ostatnie wiersze używają nazw umiejętności — wymienionych w sekcji Wygenerowane nazwy umiejętności — które nie odwzorowują się jeden do jednego na identyfikatory poleceń (/opsx:applyto umiejętnośćopenspec-apply-change).
Wzorce ścieżek poleceń powyżej są celowo neutralne względem rozszerzenia (.*): rozszerzenie należy do narzędzia (.toml dla Gemini CLI, .prompt dla Continue, .prompt.md dla Kiro i GitHub Copilot), a kilka narzędzi pokazuje nazwę z rozszerzeniem w selektorze. Dopasuj strukturę katalogu, nie rozszerzenie.
Pliki generowane przez OpenSpec oraz podpowiedź „Getting started” wyświetlana po konfiguracji już używają właściwej formy dla wybranych narzędzi — więc najszybszą odpowiedzią jest przeczytanie podpowiedzi.
Dokumentacja katalogów narzędzi
| Narzędzie (ID) | Wzorzec ścieżki umiejętności | Wzorzec ścieżki polecenia |
|---|---|---|
Amazon Q Developer (amazon-q) | .amazonq/skills/openspec-*/SKILL.md | .amazonq/prompts/opsx-<id>.md |
Antigravity (antigravity) | .agent/skills/openspec-*/SKILL.md | .agent/workflows/opsx-<id>.md |
Auggie (auggie) | .augment/skills/openspec-*/SKILL.md | .augment/commands/opsx-<id>.md |
IBM Bob Shell (bob) | .bob/skills/openspec-*/SKILL.md | .bob/commands/opsx-<id>.md |
Claude Code (claude) | .claude/skills/openspec-*/SKILL.md | .claude/commands/opsx/<id>.md |
Cline (cline) | .cline/skills/openspec-*/SKILL.md | .clinerules/workflows/opsx-<id>.md |
Command Code (command-code) | .commandcode/skills/openspec-*/SKILL.md | .commandcode/commands/opsx-<id>.md |
CodeArts (codeartsagent) | .codeartsdoer/skills/openspec-*/SKILL.md | Nie generowane (brak adaptera poleceń; użyj wywołań /openspec-* opartych na umiejętnościach) |
CodeBuddy (codebuddy) | .codebuddy/skills/openspec-*/SKILL.md | .codebuddy/commands/opsx/<id>.md |
Codex (codex) | .agents/skills/openspec-*/SKILL.md | Nie generowane (tylko umiejętności; użyj $openspec-*) |
Devin Desktop, dawniej Windsurf (devin) | .devin/skills/openspec-*/SKILL.md | .devin/workflows/opsx-<id>.md**** |
ForgeCode (forgecode) | .forge/skills/openspec-*/SKILL.md | Nie generowane (brak adaptera poleceń; użyj wywołań /openspec-* opartych na umiejętnościach) |
Continue (continue) | .continue/skills/openspec-*/SKILL.md | .continue/prompts/opsx-<id>.prompt |
CoStrict (costrict) | .cospec/skills/openspec-*/SKILL.md | .cospec/openspec/commands/opsx-<id>.md |
Crush (crush) | .crush/skills/openspec-*/SKILL.md | .crush/commands/opsx/<id>.md |
Cursor (cursor) | .cursor/skills/openspec-*/SKILL.md | .cursor/commands/opsx-<id>.md |
Factory Droid (factory) | .factory/skills/openspec-*/SKILL.md | .factory/commands/opsx-<id>.md |
Gemini CLI (gemini) | .gemini/skills/openspec-*/SKILL.md | .gemini/commands/opsx/<id>.toml |
GitHub Copilot (github-copilot) | .github/skills/openspec-*/SKILL.md | .github/prompts/opsx-<id>.prompt.md** |
Hermes Agent (hermes) | .hermes/skills/openspec-*/SKILL.md*** | Nie generowane (brak adaptera poleceń; użyj wywołań /openspec-* opartych na umiejętnościach) |
iFlow (iflow) | .iflow/skills/openspec-*/SKILL.md | .iflow/commands/opsx-<id>.md |
Junie (junie) | .junie/skills/openspec-*/SKILL.md | .junie/commands/opsx-<id>.md |
Kilo Code (kilocode) | .kilocode/skills/openspec-*/SKILL.md | .kilocode/workflows/opsx-<id>.md |
Kimi Code (kimi) | .kimi-code/skills/openspec-*/SKILL.md | Nie generowane (brak adaptera poleceń; użyj wywołań /skill:openspec-* opartych na umiejętnościach) |
Kiro (kiro) | .kiro/skills/openspec-*/SKILL.md | .kiro/prompts/opsx-<id>.prompt.md |
Lingma (lingma) | .lingma/skills/openspec-*/SKILL.md | .lingma/commands/opsx/<id>.md |
MiniMax Code (minimax-code) | ~/.minimax/skills/openspec-*/SKILL.md | Nie generowane (brak adaptera poleceń; użyj umiejętności MiniMax Code) |
Mistral Vibe (vibe) | .vibe/skills/openspec-*/SKILL.md | Nie generowane (brak adaptera poleceń; użyj wywołań /openspec-* opartych na umiejętnościach) |
Oh My Pi (oh-my-pi) | .omp/skills/openspec-*/SKILL.md | .omp/commands/opsx-<id>.md |
OpenCode (opencode) | .opencode/skills/openspec-*/SKILL.md | .opencode/commands/opsx-<id>.md |
Pi (pi) | .pi/skills/openspec-*/SKILL.md | .pi/prompts/opsx-<id>.md |
SourceCraft Code Assistant dla VS Code (codeassistant) | .codeassistant/skills/openspec-*/SKILL.md | .codeassistant/commands/opsx-<id>.md |
Qoder (qoder) | .qoder/skills/openspec-*/SKILL.md | .qoder/commands/opsx/<id>.md |
Qwen Code (qwen) | .qwen/skills/openspec-*/SKILL.md | .qwen/commands/opsx-<id>.md |
Rovo Dev CLI (rovodev) | .rovodev/skills/openspec-*/SKILL.md | Nie generowane. Rovo nie ma interfejsu poleceń ukośnikowych — dopasowuje umiejętności automatycznie lub przez prompt (np. „użyj umiejętności openspec-propose”); /skills tylko nimi zarządza. Wygenerowana zawartość odwołuje się do umiejętności po nazwie, nigdy jako polecenia /openspec-*. |
Zoo Code (roocode) | .roo/skills/openspec-*/SKILL.md | .roo/commands/opsx-<id>.md |
Trae (trae) | .trae/skills/openspec-*/SKILL.md | .trae/commands/opsx-<id>.md |
Zed Agent (zed) | .agents/skills/openspec-*/SKILL.md | Nie generowane (tylko umiejętności; użyj /openspec-* lub @openspec-*) |
ZCode (zcode) | .zcode/skills/openspec-*/SKILL.md | .zcode/commands/opsx/<id>.md |
Współdzielone umiejętności .agents (agents) | .agents/skills/openspec-*/SKILL.md | Nie generowane (brak adaptera poleceń; użyj wywołań /openspec-* opartych na umiejętnościach) |
** Pliki promptów GitHub Copilot są rozpoznawane jako niestandardowe polecenia ukośnikowe w rozszerzeniach IDE (VS Code, JetBrains, Visual Studio). Copilot CLI obecnie nie używa bezpośrednio .github/prompts/*.prompt.md. Wybranie github-copilot może również skonfigurować hostowanego w GitHub agenta kodowania w chmurze — zobacz Agent kodowania w chmurze GitHub Copilot poniżej.
*** Hermes domyślnie ładuje umiejętności z ~/.hermes/skills/. Aby używać lokalnych dla projektu umiejętności OpenSpec, dodaj katalog .hermes/skills/ projektu do skills.external_dirs w ~/.hermes/config.yaml; Hermes udostępnia wtedy umiejętności z wywołaniami ukośnikowymi widocznymi dla użytkownika, takimi jak /openspec-propose.
**** Windsurf został przemianowany na Devin Desktop 2 czerwca 2026 r., a jego katalog konfiguracyjny zmienił się: .devin/ jest preferowaną lokalizacją do odczytu i zapisu, .windsurf/ to starsza lokalizacja tylko do odczytu. OpenSpec podąża za zmianą nazwy — identyfikatorem narzędzia jest devin, a --tools windsurf nadal na nie wskazuje, aby istniejące skrypty konfiguracyjne działały. Projekt, który nadal przechowuje pliki OpenSpec w .windsurf/, otrzymuje propozycję przeniesienia przy następnym openspec update; odrzucenie pozostawia je na miejscu, a pliki napisane przez Ciebie nigdy nie są dotykane. Przepływy pracy są wywoływane po nazwie pliku, więc .devin/workflows/opsx-apply.md to /opsx-apply. Devin Local agent nie obsługuje przepływów pracy — tylko umiejętności i w ogóle nie czyta .windsurf/ — dlatego za każdym razem, gdy OpenSpec zapisuje umiejętności Devin, zachowuje ich treść, a podpowiedź startowa używa wywołań /openspec-* działających na obu agentach. Przy dostarczaniu wyłącznie poleceń nie są zapisywane żadne umiejętności i oba środowiska wracają do /opsx-*.
Wsparcie dla SourceCraft Code Assistant dotyczy jego rozszerzenia VS Code. Jego niestandardowe polecenia i umiejętności są dostępne wyłącznie w VS Code. Ta integracja nie konfiguruje SourceCraft web ani JetBrains.
Przy dostarczaniu wyłącznie umiejętności poproś Code Assistant, aby użył umiejętności openspec-propose z Twoim pomysłem. Umiejętności aktywują się przez dopasowanie żądań; OpenSpec nie generuje poleceń /openspec-* dla tego narzędzia.
MiniMax Code to integracja globalna oparta wyłącznie na umiejętnościach. OpenSpec zapisuje tylko swoje katalogi openspec-* w ~/.minimax/skills/; nie tworzy lokalnych dla repozytorium katalogów .minimax ani .mavis. Dostarczanie wyłącznie poleceń pozostawia istniejące globalne umiejętności MiniMax Code nietknięte, więc ustawienie dostarczania jednego projektu nie może usunąć umiejętności używanych przez inny projekt.
Agent kodowania w chmurze GitHub Copilot
Agent kodowania Copilot firmy GitHub działa na GitHubie w środowisku GitHub Actions — niezależnie od Copilot w edytorze. OpenSpec może go skonfigurować do korzystania z CLI OpenSpec, generując dwa pliki:
.github/workflows/copilot-setup-steps.yml— instaluje@fission-ai/openspecw środowisku agenta.github/agents/openspec.agent.md— mówi agentowi, jak obsługiwać OpenSpec
Ponieważ zapisuje to workflow GitHub Actions w Twoim repozytorium, jest to opcjonalne:
| Sposób | Zachowanie |
|---|---|
openspec init (interaktywny) | Pyta, czy skonfigurować pliki chmury. Domyślnie Nie. |
openspec init --copilot-cloud | Konfiguruje je bez pytania (dla skryptów/CI). |
openspec init --no-copilot-cloud | Pomija je bez pytania i usuwa wszelkie wcześniej wygenerowane. |
openspec update | Nigdy nie pyta. Odświeża pliki tylko jeśli wyraziłeś zgodę (lub projekt już je ma). Jeśli zrezygnowałeś, usuwa zarządzane przez OpenSpec pliki chmury. |
Twój wybór jest zapisywany w openspec/config.yaml jako githubCopilot.cloudAgent: true|false, więc nieinteraktywne aktualizacje go honorują. OpenSpec zapisuje lub usuwa tylko pliki, których zawartość sam wygenerował — jeśli dostosujesz copilot-setup-steps.yml lub openspec.agent.md, albo masz już własne, pozostaną nietknięte (a init/update poinformuje Cię o tym).
Kiedy wybrać współdzielony cel .agents
agents to opcja neutralna dostawcy: zapisuje umiejętności w .agents/skills/, współdzielonym katalogu czytanym przez wiele narzędzi agentowych, zamiast w katalogu specyficznym dla narzędzia.
| Sytuacja | Wybierz |
|---|---|
| Twoje narzędzie ma swój własny wiersz powyżej | Jego własny ID — otrzymujesz integrację dla tego narzędzia, w tym polecenia ukośnikowe tam, gdzie są obsługiwane |
Kilka agentów w jednym repozytorium, wszystkie czytające .agents/skills | agents — jedno drzewo umiejętności zamiast osobnego dla każdego narzędzia |
Twoje narzędzie nie jest jeszcze wymienione, ale czyta .agents/skills | agents |
Wybranie go razem z identyfikatorem specyficznym dla narzędzia jest w porządku; każde normalnie zapisuje do własnego katalogu. Codex i Zed Agent są wyjątkami, ponieważ używają tego samego kanonicznego katalogu .agents. Jeśli Codex zostanie wybrany razem z Zed lub agents, OpenSpec zachowuje jedno drzewo pod kontrolą Codexa. Jego przekazania zawierają zarówno $openspec-* dla Codexa, jak i /openspec-* dla innych agentów, więc --tools all i istniejące konfiguracje wieloagentowe działają bez nadpisywania tych samych plików przez dwóch zapisujących. OpenSpec proponuje to również automatycznie, gdy projekt ma już katalog .agents/skills/ — sam .agents/ nie wystarczy, ponieważ narzędzia używają tego katalogu również do reguł i definicji podagentów. Zwróć uwagę, że .agents to nie .agent: katalog w liczbie pojedynczej należy do Antigravity.
Dwie rzeczy, które warto wiedzieć:
- Tylko umiejętności. Nie istnieje adapter poleceń, więc żadne pliki poleceń
opsx-*nie są zapisywane; przy trybie dostarczania zawierającym poleceniaopenspec initwymieniaagentswśród narzędzi zgłaszanych jakoCommands skipped for: … (no adapter). Wywołuj przepływy pracy po nazwie umiejętności — większość asystentów czytających.agents/skillszapisuje to jako/openspec-propose, czyli formę, którą drukuje podpowiedź konfiguracyjna OpenSpec. Cel jest neutralny dostawcy, więc sprawdź dokumentację swojego asystenta, jeśli używa innej formy. - Żaden
AGENTS.mdnie jest tworzony ani edytowany. Celem jest katalog.agents/. Jeśli Twój głównyAGENTS.mdnadal zawiera bloki znaczników OpenSpec ze starszej wersji,openspec updateje usuwa — zobacz Przewodnik migracji.
Wsparcie dla Zed dotyczy tutaj wbudowanego Zed Agent. Zed External Agents i Terminal Threads używają własnych integracji. Umiejętności agenta wymagają Zed v1.4.2 lub nowszego. Umiejętności lokalne dla projektu są niedostępne w niezaufanym drzewie roboczym, dopóki nie udzielisz zaufania.
Ponieważ .agents/skills/ jest współdzielony przez Codex, Zed Agent i cel neutralny dostawcy, warto wiedzieć, co OpenSpec tam deklaruje: zapisuje, odświeża i usuwa tylko katalogi umiejętności openspec-* dla wybranych przepływów pracy oraz znacznik .openspec-target, który rejestruje, czy Codex, Zed Agent czy cel neutralny dostawcy wyrenderował to współdzielone drzewo. Wszystko inne w tym katalogu pozostaje nietknięte. Traktuj nazwy openspec-* i znacznik jako należące do OpenSpec — edycje w ich wnętrzu są zastępowane przy następnym openspec update, tak samo jak dla każdego innego narzędzia.
W przypadku projektów sprzed znacznika OpenSpec wnioskuje o własności na podstawie zarządzanych odwołań do umiejętności: $openspec-* oznacza Codex, a /openspec-* oznacza cel neutralny dostawcy. Generyczne kanoniczne drzewo obok starszego .codex/skills jest traktowane jako starsza instalacja dwucelowa i konsolidowane do kompatybilnego współdzielonego drzewa.
openspec update honoruje tę własność. Jeśli projekt posiada .agents jako cel neutralny dostawcy, a pozostała instalacja Codexa jest wykrywana tylko na podstawie zabłąkanych plików promptów, aktualizacja pozostawia ustalone drzewo agents na miejscu, zamiast nadpisywać je składnią Codexa, i zachowuje te starsze pliki promptów zamiast je usuwać. Aby przekazać współdzielone drzewo Codexowi, uruchom jawnie openspec init --tools codex.
Konfiguracja nielinteraktywna
W przypadku konfiguracji CI/CD lub skryptowej użyj --tools (opcjonalnie --profile):
# Konfiguracja konkretnych narzędzi
openspec init --tools claude,cursor
# Konfiguracja wszystkich obsługiwanych narzędzi
openspec init --tools all
# Pominięcie konfiguracji narzędzi
openspec init --tools none
# Nadpisanie profilu dla tego uruchomienia init
openspec init --profile coreDostępne identyfikatory narzędzi (--tools) — windsurf jest również akceptowany 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, qoder, qwen, roocode, codeassistant, trae, zed, zcode, agents
Instalacja zależna od przepływu pracy
OpenSpec instaluje artefakty przepływu pracy na podstawie wybranych przepływów:
- Profil Core (domyślny):
propose,explore,apply,update,sync,archive - Wybór niestandardowy: dowolny podzbiór wszystkich identyfikatorów przepływów:
propose,explore,new,continue,apply,update,ff,sync,archive,bulk-archive,verify,onboard
Innymi słowy, liczba umiejętności/polecień zależy od profilu i sposobu dostarczania, a nie jest stała.
Wygenerowane nazwy umiejętności
Po wybraniu przez konfigurację profilu/przepływu pracy OpenSpec generuje następujące umiejętności:
openspec-proposeopenspec-exploreopenspec-new-changeopenspec-continue-changeopenspec-apply-changeopenspec-update-changeopenspec-ff-changeopenspec-sync-specsopenspec-archive-changeopenspec-bulk-archive-changeopenspec-verify-changeopenspec-onboard
Zobacz Polecenia w celu zapoznania się z zachowaniem poleceń oraz CLI w celu zapoznania się z opcjami init/update.
Powiązane
- Referencja CLI — Polecenia terminala
- Polecenia — Polecenia z ukośnikiem i umiejętności
- Szybki start — Pierwsza konfiguracja