Unterstützte Tools

OpenSpec funktioniert mit vielen KI-Coding-Assistenten. Wenn Sie openspec init ausführen, konfiguriert OpenSpec die ausgewählten Tools basierend auf Ihrer aktiven Profil-/Workflow-Auswahl und dem Bereitstellungsmodus.

Funktionsweise

Für jedes ausgewählte Tool kann OpenSpec Folgendes installieren:

1. Skills (falls die Bereitstellung Skills umfasst): .../skills/openspec-*/SKILL.md
2. Commands (falls die Bereitstellung Commands umfasst): toolspezifische opsx-*-Befehlsdateien

Codex unterstützt ausschließlich Skills: OpenSpec installiert .agents/skills/openspec-*/SKILL.md für Codex, auch wenn der Bereitstellungsmodus auf commands eingestellt ist, und generiert keine benutzerdefinierten Prompt-Dateien für Codex. Bestehende, von OpenSpec verwaltete Skills unter dem veralteten Pfad .codex/skills werden nach dem Schreiben ihrer Ersatzdateien konsolidiert; benutzerdefinierte und abweichende Dateien bleiben erhalten.

Standardmäßig verwendet OpenSpec das Profil core, das folgende Elemente enthält:

• propose
• explore
• apply
• update
• sync
• archive

Erweiterte Workflows (new, continue, ff, verify, bulk-archive, onboard) können Sie über openspec config profile aktivieren und anschließend openspec update ausführen.

So rufen Sie die Befehle auf

In diesen Dokumenten wird /opsx:propose als kanonischer Name verwendet, aber jedes Tool schreibt den Pfad so, wie es die von OpenSpec geschriebene Datei lädt. Finden Sie den Befehlspfad Ihres Tools in der Tool Directory Reference unten und passen Sie ihn hier an.

Command-Datei, die OpenSpec schreibt	Sie tippen	Tools
.../commands/opsx/<id>.* — ein opsx/-Ordner namespace-t es	/opsx:<id>	Claude Code, CodeBuddy, Crush, Gemini CLI, Lingma, Qoder, ZCode
.../opsx-<id>.* — der Dateiname ist der Befehl	/opsx-<id>	Jedes andere Tool mit generierten Befehlsdateien, außer Amazon Q und Devin
.devin/workflows/opsx-<id>.md — gelesen nur von einem der beiden Devin-Agenten	/opsx-<id> auf Devin Desktop, /openspec-<skill> auf Devin Local	Devin Desktop****
.amazonq/prompts/opsx-<id>.md — ein Prompt, kein Befehl	@opsx-<id>	Amazon Q Developer
keine — nur Skills	/openspec-<skill>	CodeArts, ForgeCode, Hermes, MiniMax Code, Mistral Vibe, Zed Agent, shared .agents
keine — Kimi Code	/skill:openspec-<skill>	Kimi Code
keine — Codex CLI	$openspec-<skill>	Codex (/openspec-<skill> wird nicht erkannt)

Also ist /opsx:propose in Cursor /opsx-propose, in Amazon Q @opsx-propose und in Codex $openspec-propose.

Zwei Dinge variieren unabhängig voneinander, weshalb sich die Zeilen nicht zusammenfassen lassen:

• Der Name. Die Zeilen 1–2 unterscheiden sich nur darin, wie die Datei den Befehl benennt, und der Stamm opsx-<id> / opsx:<id> ist für jedes Tool mit generierten Befehlsdateien gleich.
• Der Wrapper. Amazon Q lädt seine Dateien in eine Prompt-Bibliothek, die mit @ aufgerufen wird. Nur-Skills-Tools generieren überhaupt keine Befehlsdateien, daher verwenden ihre letzten drei Zeilen Skill-Namen — aufgelistet unter Generated Skill Names — die nicht eins-zu-eins auf Befehls-IDs abbilden (/opsx:apply ist der openspec-apply-change Skill).

Die oben genannten Befehlspfad-Muster sind abschlussneutral (.*): Die Erweiterung ist die des Tools (.toml für Gemini CLI, .prompt für Continue, .prompt.md für Kiro und GitHub Copilot), und einige Tools zeigen den Namen mit seiner Erweiterung im Auswahlfeld an. Passen Sie die Verzeichnisstruktur an, nicht die Erweiterung.

Die von OpenSpec generierten Dateien und der „Getting started“-Hinweis, der nach der Einrichtung ausgegeben wird, verwenden bereits die richtige Form für die von Ihnen ausgewählten Tools — die schnellste Antwort ist also, den Hinweis zu lesen.

Tool Directory Reference

Tool (ID)	Skills-Pfad-Muster	Befehlspfadmuster
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	Nicht generiert (kein Command-Adapter; nutzen Sie skill-basierte /openspec-*-Aufrufe)
CodeBuddy (codebuddy)	.codebuddy/skills/openspec-*/SKILL.md	.codebuddy/commands/opsx/<id>.md
Codex (codex)	.agents/skills/openspec-*/SKILL.md	Nicht generiert (nur Skills; nutzen Sie $openspec-*)
Devin Desktop, formerly Windsurf (devin)	.devin/skills/openspec-*/SKILL.md	.devin/workflows/opsx-<id>.md****
ForgeCode (forgecode)	.forge/skills/openspec-*/SKILL.md	Nicht generiert (kein Command-Adapter; nutzen Sie skill-basierte /openspec-*-Aufrufe)
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***	Nicht generiert (kein Command-Adapter; nutzen Sie skill-basierte /openspec-*-Aufrufe)
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	Nicht generiert (kein Command-Adapter; nutzen Sie skill-basierte /skill:openspec-*-Aufrufe)
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	Nicht generiert (kein Command-Adapter; nutzen Sie MiniMax Code Skills)
Mistral Vibe (vibe)	.vibe/skills/openspec-*/SKILL.md	Nicht generiert (kein Command-Adapter; nutzen Sie skill-basierte /openspec-*-Aufrufe)
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 for 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	Nicht generiert. Rovo hat keine Slash-Command-Oberfläche — es erkennt Skills automatisch oder per Prompt (z. B. „use the openspec-propose skill“); /skills verwaltet sie nur. Generierte Inhalte verweisen auf Skills beim Namen, niemals als /openspec-*-Befehle.
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	Nicht generiert (nur Skills; nutzen Sie /openspec-* oder @openspec-*)
ZCode (zcode)	.zcode/skills/openspec-*/SKILL.md	.zcode/commands/opsx/<id>.md
Shared .agents skills (agents)	.agents/skills/openspec-*/SKILL.md	Nicht generiert (kein Command-Adapter; nutzen Sie skill-basierte /openspec-*-Aufrufe)

** GitHub Copilot Prompt-Dateien werden in IDE-Erweiterungen (VS Code, JetBrains, Visual Studio) als benutzerdefinierte Slash-Befehle erkannt. Der Copilot CLI konsumiert .github/prompts/*.prompt.md derzeit nicht direkt. Die Auswahl von github-copilot kann auch den bei GitHub gehosteten Cloud-Coding-Agenten einrichten — siehe GitHub Copilot Cloud Coding Agent unten.

*** Hermes lädt Skills standardmäßig aus ~/.hermes/skills/. Um projektlokale OpenSpec-Skills zu verwenden, fügen Sie das Projektverzeichnis .hermes/skills/ zu skills.external_dirs in ~/.hermes/config.yaml hinzu; Hermes stellt dann Skills mit nutzerseitigen Slash-Aufrufen wie /openspec-propose bereit.

**** Windsurf wurde am 2. Juni 2026 in Devin Desktop umbenannt, und sein Konfigurationsverzeichnis wurde verschoben: .devin/ ist der bevorzugte Lese- und Schreibort, .windsurf/ ein Legacy-Lese-Fallback. OpenSpec folgt der Umbenennung — die Tool-ID ist devin, und --tools windsurf löst sich weiterhin darauf auf, sodass bestehende Setup-Skripte weiterarbeiten. Ein Projekt, das noch OpenSpec-Dateien in .windsurf/ hält, wird beim nächsten openspec update zur Verschiebung aufgefordert; eine Ablehnung lässt sie unverändert, und selbst geschriebene Dateien werden niemals berührt. Workflows werden über den Dateinamen aufgerufen, also ist .devin/workflows/opsx-apply.md gleich /opsx-apply. Der Devin Local Agent unterstützt keine Workflows — nur Skills, und er liest .windsurf/ überhaupt nicht — daher behält OpenSpec beim Schreiben von Devin-Skills deren Körper und den Getting-Started-Hinweis auf /openspec-*-Skill-Aufrufen, die auf beiden Agenten funktionieren. Bei der reinen Befehlsbereitstellung werden keine Skills geschrieben, und beide fallen auf /opsx-* zurück.

Die Unterstützung für den SourceCraft Code Assistant zielt auf seine VS Code-Erweiterung ab. Seine benutzerdefinierten Befehle und Skills sind nur in VS Code verfügbar. Diese Integration konfiguriert weder SourceCraft Web noch JetBrains.

Bei der reinen Skill-Bereitstellung bitten Sie den Code Assistant, den openspec-propose-Skill mit Ihrer Idee zu verwenden. Skills aktivieren sich durch Anforderungsübereinstimmung; OpenSpec generiert keine /openspec-*-Befehle für dieses Tool.

MiniMax Code ist eine globale, nur-Skills-Integration. OpenSpec schreibt nur seine openspec-*-Verzeichnisse unter ~/.minimax/skills/; es erstellt keine repo-lokalen .minimax- oder .mavis-Verzeichnisse. Die reine Befehlsbereitstellung lässt bestehende globale MiniMax Code-Skills unberührt, damit die Bereitstellungs Einstellung eines Projekts keine von einem anderen Projekt genutzten Skills entfernt.

GitHub Copilot Cloud Coding Agent

Googles Copilot Coding Agent läuft auf GitHub in einer GitHub Actions-Umgebung — getrennt von Copilot in Ihrem Editor. OpenSpec kann ihn einrichten, um die OpenSpec CLI zu verwenden, indem es zwei Dateien generiert:

• .github/workflows/copilot-setup-steps.yml — installiert @fission-ai/openspec in der Agenten-Umgebung
• .github/agents/openspec.agent.md — weist den Agenten an, wie er OpenSpec steuern soll

Da dies einen GitHub Actions-Workflow in Ihr Repository schreibt, ist dies opt-in:

Wie	Verhalten
openspec init (interaktiv)	Fragt, ob Cloud-Dateien eingerichtet werden sollen. Standard ist Nein.
openspec init --copilot-cloud	Richtet sie ohne Rückfrage ein (für Skripte/CI).
openspec init --no-copilot-cloud	Überspringt sie ohne Rückfrage und entfernt zuvor generierte.
openspec update	Fragt nie nach. Aktualisiert die Dateien nur, wenn Sie opt-in waren (oder das Projekt sie bereits hat). Wenn Sie opt-out waren, entfernt es OpenSpec-verwaltete Cloud-Dateien.

Ihre Wahl wird in openspec/config.yaml als githubCopilot.cloudAgent: true|false gespeichert, sodass nicht-interaktive Updates diese respektieren. OpenSpec schreibt oder entfernt nur Dateien, deren Inhalt es selbst generiert hat — wenn Sie copilot-setup-steps.yml oder openspec.agent.md anpassen oder bereits eigene haben, bleibt es unberührt (und init/update weisen Sie darauf hin).

Wann man das gemeinsame .agents-Ziel wählt

agents ist die herstellerneutrale Option: Sie schreibt Skills nach .agents/skills/, dem gemeinsamen Stammverzeichnis, das viele Agent-Tools lesen, anstelle eines tool-spezifischen Verzeichnisses.

Situation	Wählen
Ihr Tool hat eine eigene Zeile oben	Seine eigene ID — Sie erhalten die Integration dieses Tools, einschließlich Slash-Befehlen, wo es diese unterstützt
Mehrere Agenten in einem Repo, die alle .agents/skills lesen	agents — ein Skill-Tree statt einer pro Tool
Ihr Tool ist noch nicht aufgelistet, liest aber .agents/skills	agents

Die Auswahl zusammen mit einer tool-spezifischen ID ist in Ordnung; jeder schreibt normalerweise in seinen eigenen Stamm. Codex und Zed Agent sind die Ausnahmen, da sie denselben kanonischen .agents-Stamm verwenden. Wenn Codex zusammen mit Zed oder agents ausgewählt wird, behält OpenSpec einen einzigen, von Codex geführten Tree. Seine Handoffs benennen sowohl $openspec-* für Codex als auch /openspec-* für andere Agenten, sodass --tools all und bestehende Multi-Agent-Setups weiterarbeiten, ohne dass zwei Schreiber dieselben Dateien überschreiben. OpenSpec bietet es auch automatisch an, sobald ein Projekt ein .agents/skills/-Verzeichnis hat — ein bloßes .agents/ reicht nicht aus, da Tools diesen Stamm auch für Regeln und Subagent-Definitionen verwenden. Beachten Sie, dass .agents nicht .agent ist: Das singuläre Verzeichnis gehört zu Antigravity.

Zwei Dinge, die Sie wissen sollten:

• Nur Skills. Es gibt keinen Command-Adapter, daher werden keine opsx-*-Befehlsdateien geschrieben; bei einem befehlssensiblen Bereitstellungsmodus listet openspec init agents unter den Tools auf, die es unter Commands skipped for: … (no adapter) meldet. Rufen Sie die Workflows über den Skill-Namen auf — die meisten Assistenten, die .agents/skills lesen, schreiben das als /openspec-propose, die Form, die der Setup-Hinweis von OpenSpec ausgibt. Das Ziel ist herstellerneutral, also prüfen Sie die Dokumentation Ihres Assistenten, falls er eine andere Form verwendet.
• Es wird keine AGENTS.md erstellt oder bearbeitet. Das Ziel ist das .agents/-Verzeichnis. Falls Ihre Root-AGENTS.md noch OpenSpec-Marker-Blöcke aus einer älteren Version enthält, entfernt openspec update diese — siehe Migration Guide.

Die Zed-Unterstützung hier gilt für den integrierten Zed Agent. Zed External Agents und Terminal Threads verwenden ihre eigenen Integrationen. Agent Skills erfordern Zed v1.4.2 oder neuer. Projektlokale Skills sind in einem nicht vertrauenswürdigen Worktree nicht verfügbar, bis Sie Vertrauen gewähren.

Da .agents/skills/ von Codex, Zed Agent und dem herstellerneutralen Ziel gemeinsam genutzt wird, ist es hilfreich zu wissen, was OpenSpec dort beansprucht: Es schreibt, aktualisiert und entfernt nur die openspec-*-Skill-Verzeichnisse für Ihre ausgewählten Workflows sowie einen .openspec-target-Marker, der aufzeichnet, ob Codex, Zed Agent oder das herstellerneutrale Ziel diesen gemeinsamen Tree gerendert hat. Alles andere in diesem Verzeichnis bleibt unangetastet. Behandeln Sie die openspec-*-Namen und den Marker als Eigentum von OpenSpec — Änderungen darin werden beim nächsten openspec update ersetzt, genau wie bei jedem anderen Tool.

Für Projekte vor dem Marker leitet OpenSpec den Besitz aus verwalteten Skill-Referenzen ab: $openspec-* bedeutet Codex und /openspec-* bedeutet das herstellerneutrale Ziel. Ein generischer kanonischer Tree neben legacy .codex/skills wird als ältere Dual-Target-Installation behandelt und in den kompatiblen gemeinsamen Tree konsolidiert.

openspec update respektiert auch diesen Besitz. Wenn ein Projekt .agents als herstellerneutrales Ziel besitzt und eine verbliebene Codex-Installation nur anhand verstreuter Prompt-Dateien erkannt wird, lässt das Update den etablierten agents-Tree an Ort und Stelle, anstatt ihn mit Codex-Syntax neu zu schreiben, und bewahrt diese Legacy-Prompt-Dateien, anstatt sie zu löschen. Um den gemeinsamen Tree an Codex zu übergeben, führen Sie explizit openspec init --tools codex aus.

Nicht-interaktive Einrichtung

Für CI/CD oder skriptgesteuerte Einrichtung verwenden Sie --tools (und optional --profile):

# Spezifische Tools konfigurieren
openspec init --tools claude,cursor

# Alle unterstützten Tools konfigurieren
openspec init --tools all

# Tool-Konfiguration überspringen
openspec init --tools none

# Profil für diesen Init-Lauf überschreiben
openspec init --profile core

Verfügbare Tool-IDs (--tools) — windsurf wird ebenfalls akzeptiert, als Alias für 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

Workflow-abhängige Installation

OpenSpec installiert Workflow-Artefakte basierend auf den ausgewählten Workflows:

• Core-Profil (Standard): propose, explore, apply, update, sync, archive
• Benutzerdefinierte Auswahl: eine beliebige Teilmenge aller Workflow-IDs: propose, explore, new, continue, apply, update, ff, sync, archive, bulk-archive, verify, onboard

Anders ausgedrückt: Die Anzahl von Skills/Befehlen ist profilabhängig und lieferungsabhängig, nicht festgelegt.

Generierte Skill-Namen

Wenn durch die Profil-/Workflow-Konfiguration ausgewählt, generiert OpenSpec diese Skills:

• openspec-propose
• openspec-explore
• openspec-new-change
• openspec-continue-change
• openspec-apply-change
• openspec-update-change
• openspec-ff-change
• openspec-sync-specs
• openspec-archive-change
• openspec-bulk-archive-change
• openspec-verify-change
• openspec-onboard

Siehe Commands für das Befehlsverhalten und CLI für die init/update-Optionen.

Verwandte Themen

• CLI-Referenz — Terminalbefehle
• Commands — Slash-Befehle und Skills
• Erste Schritte — Ersteinrichtung