Supported Platforms

Comet installs Skills, Rules, and Hooks in each target platform’s standard directory. You can choose one or more platforms in comet init. Comet currently supports 38 AI coding platforms.

All platforms at a glance

The following table lists every platform, its platform id (for the CLI --platform <id>), its project-level Skill directory, its global Skill directory, and the capabilities it supports.

Full capabilities (Skill + rules + hooks)

Platform	Platform id	Project	Global	Rule format	Hooks	Notes
Claude Code	`claude`	`.claude`	`.claude`	`md`	✅ `claude-code`	Reference platform; supports PreToolUse hooks
Codex	`codex`	`.agents`	`.agents`	`md`	✅ `claude-code`	Skills live in `.agents/skills`; configuration, rules, and hooks stay in `.codex`
Amazon Q Developer	`amazon-q`	`.amazonq`	`.amazonq`	`md`	✅ `claude-code`	Reuses the claude-code hook format
Devin Desktop (formerly Windsurf)	`windsurf`	`.devin`	`.devin`	`md`	✅ `windsurf`	Writes `pre_write_code` hooks; legacy `.windsurf` projects are auto-detected
GitHub Copilot	`github-copilot`	`.github`	`.github`	`copilot`	✅ `copilot`	Uses `.github/instructions/*.instructions.md`
Gemini CLI	`gemini`	`.gemini`	`.gemini`	none (GEMINI.md)	✅ `gemini`	The only platform with no rule directory that still supports hooks
Qwen Code	`qwen`	`.qwen`	`.qwen`	`md`	✅ `qwen`
Qoder	`qoder`	`.qoder`	`.qoder`	`md`	✅ `qoder`	Shares PreToolUse processing with qwen
Kiro	`kiro`	`.kiro`	`.kiro`	`md` (steering)	✅ `kiro`	Rules live in `.kiro/steering/`; the hook is a standalone `.kiro.hook` file
Grok	`grok`	`.grok`	`.grok`	`md`	✅ `claude-code`	Skills in `.grok/skills/`, rules in `.grok/rules/`, hook written to `.grok/hooks/comet.json`; OpenSpec output is generated for Codex and mirrored to `.grok`
Oh My Pi	`oh-my-pi`	`.omp`	`.omp/agent`	`mdc`	✅ `omp`	Skills in `.omp/skills/`, rules use always-apply MDC, hook uses the `.omp/hooks/pre/comet-hook-router.ts` extension module
CodeBuddy	`codebuddy`	`.codebuddy`	`.codebuddy`	`md`	✅ `codebuddy`	Rules written to `.codebuddy/rules/`; the PreToolUse hook merges into `settings.json`, preserving existing user configuration
DeepSeek Harness	`dsh`	`.dsh`	`.dsh`	`dsh`	✅ `dsh`	Uses Claude-compatible OpenSpec integration; rules go into a managed `AGENTS.md` block and hook configuration into `hooks.json`
Trae	`trae`	`.trae`	`.trae`	`md`	✅ `trae`	Hook written to `.trae/hooks.json` using versioned `PreToolUse` groups
Trae CN	`trae-cn`	`.trae-cn`	`.trae-cn`	`md`	✅ `trae`	Skills use `.trae-cn`; project-level hooks go to `.trae/hooks.json`, global hooks to `.trae-cn/hooks.json`
ZCode	`zcode`	`.zcode`	`.zcode`	`md`	✅ `zcode`	Based on OpenCode; since 0.4.2 the hook is written to `.zcode/config.json` as a `PreToolUse` process hook and turns `hooks.enabled` on; global hooks go to `~/.zcode/cli/config.json`

Skill + hooks (no rules)

Platform	Platform id	Project	Global	Hooks	Notes
WorkBuddy	`workbuddy`	`.workbuddy`	`.workbuddy`	✅ `codebuddy`	Merges the PreToolUse hook into `.workbuddy/settings.json`, preserving user configuration

Skill + rules (no hooks)

Platform	Platform id	Project	Global	Rule format	Notes
Cursor	`cursor`	`.cursor`	`.cursor`	`mdc`	The only platform using the Cursor MDC frontmatter format
OpenCode	`opencode`	`.opencode`	`~/.config/opencode`	`md`	OpenCode-style slash commands; the global directory differs from the project one
Cline	`cline`	`.cline`	`.cline`	`md`	Rules live in `.clinerules/` at the project root, not inside `.cline/`
RooCode	`roocode`	`.roo`	`.roo`	`md`
Continue	`continue`	`.continue`	`.continue`	`md`
Kilo Code	`kilocode`	`.kilocode`	`.kilocode`	`md`
Auggie	`auggie`	`.augment`	`.augment`	`md`	Augment CLI
Lingma	`lingma`	`.lingma`	`.lingma`	`md`
MimoCode	`mimocode`	`.mimocode`	`~/.config/mimocode`	`md`	Based on OpenCode; OpenCode-style slash commands plus mirrored OpenSpec output

Skill only (no rules, no hooks)

Platform	Platform id	Project	Global	Notes
Kimi Code	`kimicode`	`.kimi-code`	`.kimi-code`	OpenSpec tool id is `kimi`
Junie	`junie`	`.junie`	No global directory
CoStrict	`costrict`	`.cospec`	No global directory	Directory name differs from the id
Crush	`crush`	`.crush`	No global directory
Factory Droid	`factory`	`.factory`	No global directory
iFlow	`iflow`	`.iflow`	No global directory
Prime Agent	`prime-agent`	`.prime/agent`	`~/.prime/agent`	Skills use the `skills/` subdirectory; no rules or Hook enforcement.
Pi	`pi`	`.pi`	`~/.pi/agent`	The global directory is a subdirectory
Antigravity	`antigravity`	`.agents`	`~/.gemini/antigravity`	Project and global directories are completely different; supports CodeGraph
Antigravity 2.0	`antigravity2`	`.agents`	`~/.gemini/config`	Shares project-level `.agents/` with Antigravity; global goes through `~/.gemini/config`
Bob Shell	`bob`	`.bob`	No global directory
ForgeCode	`forgecode`	`.forge`	No global directory	Directory name differs from the id

Xiaoyu places platform cards such as Claude Code, Codex, Cursor, Devin Desktop, Gemini CLI, GitHub Copilot, and OpenCode into the capability-layer handbook

Platform support builds up layer by layer: Skill, rules, then hooks

Capability summary

Rule formats

Comet supports four rule formats:

Format	Platforms
`md`	Most platforms that support rules
`mdc`	Cursor and Oh My Pi; Oh My Pi uses always-apply MDC
`copilot`	GitHub Copilot only
`dsh`	DeepSeek Harness only; written into a managed `AGENTS.md` block

Hook formats

The 17 hook platforms in the current list use 12 hook formats:

Hook format	File written	Platforms
`claude-code`	`settings.local.json`	Claude Code, Codex, Amazon Q, Grok
`qwen`	`settings.json`	Qwen Code
`qoder`	`settings.json`	Qoder
`codebuddy`	`settings.json`	CodeBuddy, WorkBuddy
`gemini`	`settings.json`	Gemini CLI
`windsurf`	`hooks.json`	Devin Desktop (formerly Windsurf)
`copilot`	`hooks/<id>.json`	GitHub Copilot
`kiro`	`hooks/<id>.kiro.hook`	Kiro
`omp`	`hooks/pre/comet-hook-router.ts`	Oh My Pi
`dsh`	`hooks.json`	DeepSeek Harness
`trae`	`hooks.json`	Trae, Trae CN
`zcode`	`config.json`	ZCode

Activate DeepSeek Harness Hooks

DSH workflow protection requires the official Hook bridge to load Comet’s configuration. After a project-level installation or update, start DSH with the project patch:

dsh --patch .dsh/cordis.patch.yml

Global installation configures the bridge in existing profiles; restart DSH to activate it. After adding a profile, run comet update --scope global again. Updates migrate Comet-managed legacy patches and preserve other configuration. Run comet doctor to check bridge configuration and activation guidance. Configuration files alone do not establish that the running host has loaded the Hook. Once activated, workflow protection checks write and edit operations and preserves denial decisions through Windows PowerShell.

OpenCode-based platforms

OpenCode, ZCode, and MimoCode all run on the OpenCode runtime and support OpenCode-style slash commands and mirrored OpenSpec output:

Platform	Mirroring behavior
OpenCode	Native support
ZCode	Migrates and mirrors `.opencode/{skills,commands}` output to `.zcode/`
MimoCode	Mirrors OpenSpec output to `.mimocode/`

Special installation paths

The following platforms use a global installation directory that differs from their project-level directory:

Platform	Project directory	Global directory
Codex Skill	`.agents`	`~/.agents`
OpenCode	`.opencode`	`~/.config/opencode`
MimoCode	`.mimocode`	`~/.config/mimocode`
Antigravity	`.agents`	`~/.gemini/antigravity`
Antigravity 2.0	`.agents`	`~/.gemini/config`
Pi	`.pi`	`~/.pi/agent`

All other platforms install globally into a directory with the same name (for example, Claude Code globally at ~/.claude, CodeBuddy at ~/.codebuddy, WorkBuddy at ~/.workbuddy). Junie, CoStrict, Crush, Factory Droid, iFlow, Bob Shell, and ForgeCode do not support global installation.

WorkBuddy project-level Skills live in .workbuddy/skills/, and user-level Skills in ~/.workbuddy/skills/. The blocking hook is written only to the project-level .workbuddy/settings.json; a global installation does not add a global blocking hook, so no hook configuration outside the project is needed.

Codex’s Skill discovery root differs from its configuration root: project and global Skills use .agents/skills, while Codex-specific configuration, rules, hooks, and the plugin cache stay in .codex. The 0.4.0-beta.4 update/uninstall migrates Comet-managed legacy .codex/skills installations and preserves other Skills and shared directories. Since 0.4.0-beta.5, Codex’s phase-guard hook is written to the supported .codex/hooks.json. Grok also uses the claude-code hook format, but writes to .grok/hooks/comet.json and additionally matches Grok’s native write/search_replace tools.

Antigravity and Antigravity 2.0 share the project-level .agents/ Skill directory, so comet init selects both during auto-detection. To install for only one of them, uncheck the other in the interactive install flow (without —yes).

comet init automatically detects platform configuration directories that already exist in the project and pre-selects them. You can also pass --yes to skip the prompts and install to every detected platform automatically.

Choosing project-level or global

Scope	Best for	Characteristics
project	Team projects, repository conventions, committed configuration	Configuration is written into the current project for collaboration
global	A personal default environment shared across projects	Configuration is written to the user directory; switching projects is easier

If you are not sure, start with a project-level installation. It is the easiest way for team members to see the same Comet behavior.

Installation mode: copy vs symlink

After you select platforms, comet init and comet update ask for the install mode. Since 0.4.0-beta.1 a symlink mode is available:

Mode	Behavior	Best for
Copy (default)	Copies each platform’s Skills, rules, and scripts as an independent copy into the target directory	The traditional approach; platform isolation; cross-device sync via the repository
Symlink	Links Comet-managed Skills inside each platform’s existing `skills/` directory, sharing the central `.comet/skills/` store	Multi-platform development, saving disk space, updating every platform at once

How symlink mode works

With Symlink selected, Comet no longer copies a per-platform set of Comet Skills. Instead, it creates symbolic links in each platform’s existing skills/ directory that point to the project’s central .comet/skills/:

.comet/skills/          ← central store (the only copy)
├── comet-open/
├── comet-design/
└── ...
.claude/skills/comet-*  →  .comet/skills/comet-*   (symbolic links created by Comet)
.cursor/skills/comet-*  →  .comet/skills/comet-*   (symbolic links created by Comet)
.agents/skills/comet-*  →  .comet/skills/comet-*   (symbolic links created by Comet)

Running comet update refreshes only the central store and takes effect on every platform immediately. The terminal summary shows symlink created or symlink creation failed.

Symbolic links depend on filesystem support. Some Windows setups or sync tools (such as certain cloud drives) may not handle symbolic links correctly. If you run into problems, switch back to Copy mode.

If the target platform already has its own skills/ directory, Comet keeps the directory and any local or third-party Skills inside it, creating or refreshing only the Comet-managed links.

The mode you choose does not change Comet’s behavior, only how files land on disk. When committed to a repository, Copy mode produces real files; Symlink mode produces symbolic links (team members usually run comet init themselves).

Generic skills registry platforms

Some AI coding platforms manage Skills through the generic skills CLI registry. For these platforms (including OpenClaw, Hermes, and others), install the Comet skill package with the generic command:

npx skills add rpamis/comet

This command pulls the Comet skill package from the generic skills registry and installs it where the platform expects it, without a global Comet installation. It coexists with comet init without conflict.

Hooks and enforcement

Some platforms support hooks. Comet merges the hook configuration it manages non-destructively and keeps your existing configuration. If the file already contains plugins, hooks, or other user settings, Comet preserves them. If the JSON cannot be parsed, the installation fails with an explicit error and leaves the original file unchanged.

Post-install verification (optional)

comet doctor

If a platform directory, Skill file, script, or hook is missing, doctor reports the diagnosis. To refresh, run:

comet update

Get started

Understand Comet Native

Advanced

Practical scenarios

All platforms at a glance

Full capabilities (Skill + rules + hooks)

Skill + hooks (no rules)

Skill + rules (no hooks)

Skill only (no rules, no hooks)

Capability summary

Rule formats

Hook formats

Activate DeepSeek Harness Hooks

OpenCode-based platforms

Special installation paths

Choosing project-level or global

Installation mode: copy vs symlink

How symlink mode works

Generic skills registry platforms

Hooks and enforcement

Post-install verification (optional)

​All platforms at a glance

​Full capabilities (Skill + rules + hooks)

​Skill + hooks (no rules)

​Skill + rules (no hooks)

​Skill only (no rules, no hooks)

​Capability summary

​Rule formats

​Hook formats

​Activate DeepSeek Harness Hooks

​OpenCode-based platforms

​Special installation paths

​Choosing project-level or global

​Installation mode: copy vs symlink

​How symlink mode works

​Generic skills registry platforms

​Hooks and enforcement

​Post-install verification (optional)

All platforms at a glance

Full capabilities (Skill + rules + hooks)

Skill + hooks (no rules)

Skill + rules (no hooks)

Skill only (no rules, no hooks)

Capability summary

Rule formats

Hook formats

Activate DeepSeek Harness Hooks

OpenCode-based platforms

Special installation paths

Choosing project-level or global

Installation mode: copy vs symlink

How symlink mode works

Generic skills registry platforms

Hooks and enforcement

Post-install verification (optional)