Harness Skills Capabilities Reference

Source of truth for what each AI coding harness supports in terms of agent skills. Used to inform provider configs in scripts/lib/transformers/providers.js.

Last verified: 2026-03-24

Official Documentation

Harness	Docs URL
Claude Code	https://code.claude.com/docs/en/skills
Cursor	https://cursor.com/docs/context/skills
Gemini CLI	https://geminicli.com/docs/cli/skills/
Codex CLI	https://developers.openai.com/codex/skills
GitHub Copilot (Agents)	https://code.visualstudio.com/docs/copilot/customization/agent-skills
Kiro	https://kiro.dev/docs/skills/
OpenCode	https://opencode.ai/docs/skills/
Pi	https://github.com/badlogic/pi-mono/blob/main/packages/coding-agent/docs/skills.md
Trae	TBD (no official skills docs found yet)
Rovo Dev	https://support.atlassian.com/rovo/docs/extend-rovo-dev-cli-with-agent-skills

Spec Compliance

All harnesses follow the Agent Skills specification to varying degrees. The spec defines these frontmatter fields: name, description, license, compatibility, metadata, allowed-tools.

Provider-specific extensions beyond the spec: user-invocable, argument-hint, disable-model-invocation, allowed-tools (extended syntax), model, effort, context, agent, hooks, subtask, mcp.

Frontmatter Support

Fields marked with * are spec-standard. Others are provider extensions.

Field	Claude Code	Cursor	Gemini	Codex	Copilot	Kiro	OpenCode	Pi	Rovo Dev
`name`*	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
`description`*	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
`license`*	Yes	Yes	Ignored	No	Yes	Yes	Yes	Yes	Yes
`compatibility`*	Yes	Yes	Ignored	No	Yes	Yes	Yes	Yes	Yes
`metadata`*	Yes	Yes	Ignored	No	Yes	Yes	Yes	Yes	Yes
`allowed-tools`*	Yes	No	Ignored	No	No	No	Yes	Yes	Yes
`user-invocable`	Yes	No	No	No	Yes	No	Yes	No	Yes
`argument-hint`	Yes	No	No	No	Yes	No	Yes	No	Yes
`disable-model-invocation`	Yes	Yes	No	No	Yes	No	Yes	Yes	TBD
`model`	Yes	No	No	No	No	No	Yes	No	No
`effort`	Yes	No	No	No	No	No	No	No	No
`context`	Yes	No	No	No	No	No	No	No	No
`agent`	Yes	No	No	No	No	No	Yes	No	No
`hooks`	Yes	No	No	No	No	No	No	No	No

Notes:

Gemini CLI validates only name and description; other spec fields are parsed but ignored.
Codex CLI uses a separate agents/openai.yaml sidecar for extended metadata (icons, branding, MCP tools, invocation control).
Kiro recognizes user-invocable and disable-model-invocation per community reports but does not formally document them.
Unknown fields are silently ignored by all harnesses.

Skill Directory Structure

Harness	Native directory	Also reads
Claude Code	`.claude/skills/`	-
Cursor	`.cursor/skills/`	`.agents/skills/`, `.claude/skills/`, `.codex/skills/`
Gemini CLI	`.gemini/skills/`	`.agents/skills/`
Codex CLI	`.agents/skills/` (primary)	-
GitHub Copilot	`.github/skills/`	`.agents/skills/`, `.claude/skills/`
Kiro	`.kiro/skills/`	-
OpenCode	`.opencode/skills/`	`.agents/skills/`, `.claude/skills/`
Pi	`.pi/skills/`	`.agents/skills/`
Trae China	`.trae-cn/skills/`	TBD
Trae International	`.trae/skills/`	TBD
Rovo Dev	`.rovodev/skills/`	`~/.rovodev/skills/` (user-level)

All harnesses support the {skill-name}/SKILL.md directory structure with optional reference/, scripts/, and assets/ subdirectories.

Placeholder / Variable Substitution

Claude Code supports runtime variable substitution directly in SKILL.md bodies: $ARGUMENTS, $0-$N, ${CLAUDE_SKILL_DIR}, ${CLAUDE_SESSION_ID}. No other harness supports substitution in skills.

Some harnesses have separate "custom commands" systems (distinct from skills) with their own substitution:

Harness	Command system	Substitution syntax
Gemini CLI	`.gemini/commands/` (TOML)	`{{args}}`, `!{shell}`, `@{file}`
Codex CLI	`.codex/prompts/`	`$ARGNAME`
OpenCode	`.opencode/commands/`	`$ARGUMENTS`, `$1`-`$N`, !`shell`

Our build system handles cross-provider placeholders at compile time via replacePlaceholders() for {{model}}, {{config_file}}, {{ask_instruction}}, and {{available_commands}}.