Supported tools

Every tool in the matrix runs the same OpenSpec workflows, installed as skills. Earlier versions also wrote command files. Upgrade to 2.0 covers what happens to them.

Where skills goCopy Anchor Link

Every tool's skills are written once, to .agents/skills/. A tool that doesn't read that folder gets one link per skill in its own skills/ folder, pointing back at the shared copy.

A project set up for Claude Code, Cursor, and Codex:

my-project/
├── .agents/skills/
│   ├── .openspec-target           the tools set up here, one per line
│   └── openspec-propose/SKILL.md  the one copy every tool reads
└── .claude/
    └── skills/openspec-propose    link to ../../.agents/skills/openspec-propose

Cursor and Codex read .agents/skills/ themselves, so they need nothing else.

.openspec-target is how openspec update knows what is OpenSpec's. Each line is one of:

• Links: Claude Code, Continue, ForgeCode, Kiro, CodeBuddy, EasyCode, iFlow, CodeArts, Lingma, GigaCode, Veai, Rovo Dev, Code Studio, and Hermes Agent.
• No link: every other tool reads .agents/skills/ directly, so it never loads a skill twice.
• Where a link can't be made: OpenSpec writes a plain copy instead, and refreshes it on openspec update.

To add a tool that isn't listed, see Link another tool.

Support matrixCopy Anchor Link

Invocations are shown for the apply workflow. Every workflow follows the same shape. The id goes to openspec init --tools <id> to skip the picker (CLI).

• Skill invocation: whether a tool registers skills as typed entries is the tool's own behavior. The column shows the spelling OpenSpec uses in generated files and in the hint init prints. Check your tool's docs if typing it does nothing.

Link another toolCopy Anchor Link

A tool that reads .agents/skills/ needs nothing: pick agents at init (Other / Universal). A tool that reads only its own folder can be pointed at the shared copy with one link. In your terminal, from the project root:

mkdir -p .mytool
ln -s ../.agents/skills .mytool/skills

On Windows, in Command Prompt:

mkdir .mytool
mklink /J .mytool\skills .agents\skills

Replace .mytool with your tool's folder. If the tool already has a skills/ folder of its own, link each skill instead: ln -s ../../.agents/skills/openspec-propose .mytool/skills/openspec-propose.

Committing links: Git stores links as links. A teammate on Windows should run git config --global core.symlinks true (or clone with git clone -c core.symlinks=true <url>) and enable Developer Mode so links can be created. Otherwise each link checks out as a small text file, which openspec update replaces with a plain copy of the skill. A junction made with mklink /J is not committed as a link; recreate it on each machine.

Per-tool notesCopy Anchor Link

A tool not listed here behaves exactly as its row reads.

Amazon Q Developer (retired)Copy Anchor Link

OpenSpec 2.0 no longer supports Amazon Q Developer: it can't load skills, and AWS is retiring it in favor of Kiro. openspec init --tools amazon-q stops with that message. In a project set up for it, openspec update removes the prompts and skills OpenSpec wrote in .amazonq/, and keeps and lists any you edited. Set up Kiro instead: openspec init --tools kiro.

AntigravityCopy Anchor Link

• Current folder: Antigravity v1.20.5 and later read workspace skills and workflows from .agents/.
• Legacy folder: after OpenSpec writes replacements, it removes equivalent generated files from .agent/. Custom files and changed generated files stay in .agent/ for you to review.
• Shared skills: Antigravity reads the same .agents/skills/ copy as every other tool. Workflows OpenSpec wrote to .agents/workflows/ before 2.0 are removed on update.

ClineCopy Anchor Link

Skills are the shared copy in .agents/skills/. Workflows OpenSpec wrote to .clinerules/workflows/ before 2.0 are removed on update; your own rules there are left alone.

CodexCopy Anchor Link

• CLI and IDE extension: mention $openspec-propose with your idea, or run /skills to select the skill. Codex does not recognize /openspec-propose (upstream issue).
• Desktop app: open Skills in the sidebar and select openspec-propose. OpenAI's skills documentation describes both interfaces.
• Shared folder: Codex reads the same .agents/skills/ copy as every other tool. Skills name each other by skill name (openspec-apply-change), which Codex invokes as $openspec-apply-change.
• Legacy path: skills installed under .codex/skills/ by older versions are migrated on the next openspec update.

DeepSeek HarnessCopy Anchor Link

• Project root: DSH uses the nearest .git ancestor, or the current directory outside Git. Run openspec init --tools dsh there. For a nested OpenSpec project, add the absolute path to its .agents/skills/ directory to DSH's customSkillDirs. Git-root skills still win if names overlap (upstream discovery rules).
• Old copies: a .dsh/skills/ copy from before 2.0 would take precedence over .agents/skills/. openspec update removes untouched ones and reports any you changed.

Devin Desktop (formerly Windsurf)Copy Anchor Link

• Both agents: Devin Desktop and Devin Local both run the shared skills. Workflows OpenSpec wrote to .devin/workflows/ before 2.0 are removed on update.
• Rename: --tools windsurf still resolves to devin. A project holding OpenSpec files in the legacy .windsurf/ folder is offered the move on the next openspec update.

GitHub CopilotCopy Anchor Link

• Skills: Copilot loads .agents/skills/openspec-*/SKILL.md. Invoke a skill as /openspec-<skill>. In the CLI, if a skill disappears while its file still exists, run /skills reload, then /skills info openspec-propose to confirm discovery. In an IDE, restart it.
• Old prompt files: the .github/prompts/opsx-*.prompt.md files OpenSpec wrote before 2.0 are removed on update.

GSDCopy Anchor Link

• Project skills: GSD reads OpenSpec workflows from .agents/skills/.
• Invocation: ask GSD to use the openspec-<workflow> skill. GSD can also select a matching skill through its skill discovery setting.
• No subagent files: .gsd/agents/ contains GSD subagent definitions. OpenSpec does not write workflow skills there.

Hermes AgentCopy Anchor Link

OpenSpec links each skill into the project's .hermes/skills/ folder. Hermes v2026.6.5 and later load that folder once you trust the repo: run hermes skills trust inside the project. Until then, Hermes shows a notice that it found project skills but did not load them. On older versions, add the project's .hermes/skills/ folder to skills.external_dirs in ~/.hermes/config.yaml instead. Init prints this reminder after install.

MiniMax CodeCopy Anchor Link

• Global only: skills go to ~/.minimax/skills/. Nothing is written inside the repo.

WarpCopy Anchor Link

• What OpenSpec claims: nothing in .warp/. Warp settings and WARP.md are not created or edited.

Other / Universal (shared .agents skills)Copy Anchor Link

• When it fits: any tool that reads the shared .agents/skills/ folder, including tools with no row in the matrix. It is the entry to pick when your assistant is not listed. The init picker's search box finds it by universal, other, generic, custom, proprietary, unlisted, unsupported, vendor-neutral, or agents.md.
• Alongside other tools: every tool reads this one skill tree. .openspec-target lists the tools set up in the project. To remove a tool, delete its folder (or, for a tool with no folder of its own, its line in .openspec-target).
• Your own openspec-* skills: a skill already in .agents/skills/ before OpenSpec used the folder is kept, never written over, and recorded as keep <skill> in .openspec-target. Delete that skill to let OpenSpec write its own.
• What OpenSpec claims: only the openspec-* folders and the .openspec-target list. Anything else under .agents/ is left alone.
• AGENTS.md: not created or edited. The target is the .agents/ folder, not the file.