Supported Tools

OpenSpec works with many AI coding assistants. When you run openspec init, OpenSpec configures selected tools using your active profile/workflow selection and delivery mode.

How It Works

For each selected tool, OpenSpec can install:

1. Skills (if delivery includes skills): .../skills/openspec-*/SKILL.md
2. Commands (if delivery includes commands): tool-specific opsx-* command files

Codex is skills-only: OpenSpec installs .agents/skills/openspec-*/SKILL.md for Codex even when delivery is set to commands, and it does not generate Codex custom prompt files. Existing OpenSpec-managed skills under the legacy .codex/skills path are reconciled after their replacements are written; custom and divergent files are preserved.

By default, OpenSpec uses the core profile, which includes:

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

You can enable expanded workflows (new, continue, ff, verify, bulk-archive, onboard) via openspec config profile, then run openspec update.

How To Invoke

These docs use /opsx:propose as the canonical name, but each tool spells it the way it loads the file OpenSpec wrote. Find your tool's command path in the Tool Directory Reference below, then match its shape here.

So /opsx:propose is /opsx-propose in Cursor, @opsx-propose in Amazon Q, and $openspec-propose in Codex.

Two things vary independently, which is why the rows do not collapse:

• The name. Rows 1–2 differ only in how the file names the command, and the opsx-<id> / opsx:<id> stem is the same for every tool with generated command files.
• The wrapper. Amazon Q loads its files into a prompt library invoked with @. Skills-only tools generate no command files at all, so their last three rows use skill names — listed under Generated Skill Names — which do not map one-to-one onto command ids (/opsx:apply is the openspec-apply-change skill).

The command path patterns above are extension-neutral (.*) on purpose: the extension is the tool's (.toml for Gemini CLI, .prompt for Continue, .prompt.md for Kiro and GitHub Copilot), and a few tools show the name with its extension in the picker. Match the directory shape, not the extension.

The files OpenSpec generates, and the "Getting started" hint printed after setup, already use the right form for the tools you selected — so the fastest answer is to read the hint.

Tool Directory Reference

** GitHub Copilot prompt files are recognized as custom slash commands in IDE extensions (VS Code, JetBrains, Visual Studio). Copilot CLI does not currently consume .github/prompts/*.prompt.md directly. Selecting github-copilot can also set up the GitHub-hosted cloud coding agent — see GitHub Copilot cloud coding agent below.

*** Hermes loads skills from ~/.hermes/skills/ by default. To use project-local OpenSpec skills, add the project .hermes/skills/ directory to skills.external_dirs in ~/.hermes/config.yaml; Hermes then exposes skills with user-facing slash invocations such as /openspec-propose.

**** Windsurf was rebranded to Devin Desktop on June 2, 2026, and its config directory moved: .devin/ is the preferred read + write location, .windsurf/ a legacy read-only fallback. OpenSpec follows the rename — the tool id is devin, and --tools windsurf still resolves to it so existing setup scripts keep working. A project still holding OpenSpec files in .windsurf/ is offered the move on the next openspec update; declining leaves them in place, and files you wrote yourself are never touched. Workflows are invoked by filename, so .devin/workflows/opsx-apply.md is /opsx-apply. The Devin Local agent does not support workflows — only skills, and it does not read .windsurf/ at all — so whenever OpenSpec writes Devin skills it keeps their bodies, and the getting-started hint, on /openspec-* skill invocations, which work on both agents. Under commands-only delivery no skills are written and both fall back to /opsx-*.

MiniMax Code is a global skills-only integration. OpenSpec writes only its openspec-* directories under ~/.minimax/skills/; it does not create repo-local .minimax or .mavis directories. Commands-only delivery leaves existing global MiniMax Code skills untouched so one project's delivery setting cannot remove skills used by another project.

GitHub Copilot cloud coding agent

GitHub's Copilot coding agent runs on GitHub in a GitHub Actions environment — separate from Copilot in your editor. OpenSpec can set it up to use the OpenSpec CLI by generating two files:

• .github/workflows/copilot-setup-steps.yml — installs @fission-ai/openspec in the agent's environment
• .github/agents/openspec.agent.md — tells the agent how to drive OpenSpec

Because this writes a GitHub Actions workflow into your repository, it is opt-in:

Your choice is saved in openspec/config.yaml as githubCopilot.cloudAgent: true|false, so non-interactive updates honor it. OpenSpec only ever writes or removes files whose content it generated — if you customize copilot-setup-steps.yml or openspec.agent.md, or already have your own, it is left untouched (and init/update tell you so).

When to pick the shared .agents target

agents is the vendor-neutral option: it writes skills to .agents/skills/, the shared root many agent tools read, instead of a tool-specific directory.

Selecting it alongside a tool-specific ID is fine; each normally writes to its own root. Codex is the exception because it uses the same canonical .agents root. If both codex and agents are selected, OpenSpec keeps one Codex-led tree. Its handoffs name both $openspec-* for Codex and /openspec-* for other agents, so --tools all and existing multi-agent setups keep working without two writers overwriting the same files. OpenSpec also offers it automatically once a project has a .agents/skills/ directory — a bare .agents/ is not enough, since tools use that root for rules and subagent definitions too. Note .agents is not .agent: the singular directory belongs to Antigravity.

Two things to know:

• Skills only. No command adapter exists, so no opsx-* command files are written; with a commands-inclusive delivery mode openspec init lists agents among the tools it reports under Commands skipped for: … (no adapter). Invoke the workflows by skill name — most assistants that read .agents/skills spell that /openspec-propose, the form OpenSpec's setup hint prints. The target is vendor-neutral, so check your assistant's own docs if it uses another form.
• No AGENTS.md is created or edited. The target is the .agents/ directory. If your root AGENTS.md still carries OpenSpec marker blocks from an older version, openspec update strips them — see the Migration Guide.

Because .agents/skills/ is shared, it is worth knowing what OpenSpec claims there: it writes, refreshes, and removes only the openspec-* skill directories for your selected workflows, plus an .openspec-target marker that records whether Codex or the vendor-neutral target rendered that shared tree. Anything else in that directory is left alone. Treat the openspec-* names and marker as OpenSpec's — edits inside them are replaced on the next openspec update, the same as for every other tool.

For pre-marker projects, OpenSpec infers ownership from managed skill references: $openspec-* means Codex and /openspec-* means the vendor-neutral target. A generic canonical tree alongside legacy .codex/skills is treated as an older dual-target install and consolidated into the compatible shared tree.

Non-Interactive Setup

For CI/CD or scripted setup, use --tools (and optionally --profile):

# Configure specific tools
openspec init --tools claude,cursor

# Configure all supported tools
openspec init --tools all

# Skip tool configuration
openspec init --tools none

# Override profile for this init run
openspec init --profile core

Available tool IDs (--tools) — windsurf is also accepted, as an alias for devin: amazon-q, antigravity, auggie, bob, claude, cline, 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, trae, zcode, agents

Workflow-Dependent Installation

OpenSpec installs workflow artifacts based on selected workflows:

• Core profile (default): propose, explore, apply, update, sync, archive
• Custom selection: any subset of all workflow IDs: propose, explore, new, continue, apply, update, ff, sync, archive, bulk-archive, verify, onboard

In other words, skill/command counts are profile-dependent and delivery-dependent, not fixed.

Generated Skill Names

When selected by profile/workflow config, OpenSpec generates these 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

See Commands for command behavior and CLI for init/update options.

Related

• CLI Reference — Terminal commands
• Commands — Slash commands and skills
• Getting Started — First-time setup