Skill invocation

Yes. The model sees the skill list and is told to use a skill whenever the task clearly matches its description, or when you name the skill. The description is all it has to match on, so put the trigger words first. Set policy.allow_implicit_invocation: false in agents/openai.yaml to stop a skill being picked automatically.

Yes. Claude reads the listed description and when_to_use text and calls the Skill tool when your request matches, so put the key use case and trigger phrases first. A skill with paths globs is only picked automatically while Claude works with matching files, and disable-model-invocation: true stops automatic use entirely.

Yes. Skills are applied automatically by default: the agent sees each skill's description and decides from context when one is relevant. paths globs and nested skill folders restrict this to work on matching files, and disable-model-invocation: true turns it off for a skill. Some built-in skills are also used automatically when a request clearly matches them.

Yes. The instructions tell the model to call the skill tool with an exact ID when a task matches a listed description. Before loading, the selected agent's skill permission is checked (allow, ask or deny).

Yes. The model chooses a skill by matching the task against the listed description, then reads that skill's SKILL.md itself. The description is the only routing signal, so it should say both what the skill does and when to use it. The model can still miss a relevant skill; use /skill:name to force one.

Type $ in the CLI or IDE composer to pick a skill, or type $skill-name in your prompt (for example $skill-creator). This also works in codex exec prompts. /skills opens a menu that lists skills and lets you enable or disable them. Plugin skills are invoked as $plugin:skill.

Common environment variable names such as $PATH and $HOME are not treated as skill mentions.

There is no CLI flag to preload a skill.

Type /skill-name at the start of a message (plugin skills as /plugin-name:skill-name, or the bare name when nothing else uses it). Typing /name later in a message doesn't run it directly but gives Claude permission to invoke it. You can stack up to six skills at the start, as in /write-tests /fix-issue 123.

Non-interactive runs work the same way: claude -p "/skill-name args".

Type / and pick the skill, or type /skill-name in your message; Enter attaches it to that one message, and Option+Enter (Alt+Enter) starts it as a Custom Mode that stays on until you exit it. /skill-name also works in -p print mode, /skills opens a browser of discovered skills, and the help center notes you can @-mention a skill to attach it as context.

There is no CLI flag to preload a skill; put /skill-name in the prompt instead.

Mention @skill-id in your prompt; the TUI autocompletes skill IDs after @. /skills opens a picker that inserts the mention. The skill's content is attached to your message as a <skill_content> block, and this works for skills hidden with opencode/autoinvoke: false. There are no per-skill /name commands in V2.

Type /skill:name as your message in the interactive UI, in print mode or through the RPC prompt command. Skills appear in / autocomplete unless enableSkillCommands is false, and typing the command still works in that case. If no skill has that name, the text is sent to the model unchanged.

--skill <path> loads an extra skill for one run but does not invoke it.

Partly

There is no argument syntax and no placeholder such as $ARGUMENTS. Anything else you write in the same message, like $my-skill fix the login test, is simply part of the prompt the model reads alongside the skill. The optional interface.default_prompt in agents/openai.yaml sets the prompt text used when a skill is chosen in the app UI.

Yes. Text after the skill name replaces $ARGUMENTS in the body, with $ARGUMENTS[N] or $N for positional arguments (shell-style quoting) and $name for names declared in the arguments frontmatter. If no placeholder receives the input, Claude Code appends ARGUMENTS: <value>; argument-hint shows a hint in autocomplete.

Since 2.1.301, named-argument substitution fills at most 64 declared names and limits each name to 64 characters. This is an invocation limit, not a skill-description or body limit.

Partly

Anything you type after /skill-name is sent as the rest of that message, with the skill attached, so the skill's instructions can refer to it. There are no documented $ARGUMENTS or $1 placeholders for skills; in CLI 2026.10.12 those are substituted only in custom .cursor/commands/*.md slash commands, not in SKILL.md.

Partly

There are no argument placeholders such as $ARGUMENTS. When you @-mention a skill, the rest of your message goes with it as normal text, and the model uses that as input. The skill tool accepts only id.

Yes. Any text after /skill:name is added after the skill's instructions as your request, for example /skill:pdf-tools extract report.pdf. There are no placeholders such as $ARGUMENTS; the text is appended as-is.

When you invoke a skill with $, Codex injects the full SKILL.md (frontmatter and body) into the conversation inside a <skill> block that includes the skill's name and path. When the model picks a skill itself, it is told to open and read the whole SKILL.md, then open only the references/ files it needs, and to run or patch the scripts in scripts/ instead of retyping them. Scripts run through the normal shell tool and its approvals.

The listing budget doesn't apply to the loaded SKILL.md. Some plugin-provided skills are capped at 8,000 bytes when injected, with a warning if cut.

On invocation the rendered SKILL.md body enters the conversation as one message and stays there for later turns. Before that, !command lines and ! blocks run and their output is inlined, and $ARGUMENTS and ${CLAUDE_SKILL_DIR} are substituted. Supporting files such as reference.md are read by Claude only when needed, and bundled scripts are executed rather than loaded.

After auto-compaction, Claude Code re-attaches each invoked skill's most recent content, keeping its first 5,000 tokens within a 25,000-token total.

disableSkillShellExecution: true replaces injected commands with a placeholder for user, project, plugin, and added-directory skills.

Using a skill puts its SKILL.md instructions in context; files in references/ and assets/ are read only when needed, and scripts in scripts/ are run by the agent with its normal shell tool (subject to the usual approvals) when the instructions say so. A skill used as a Custom Mode stays in context for the whole session instead of one message.

OpenCode adds the Markdown body without frontmatter, wrapped in <skill_content>, plus the skill's base directory. For folder-based SKILL.md skills it also adds up to 10 other file paths from that folder, sorted; flat .md skills get no file list. Reference files and scripts are never read or run automatically; the agent reads or runs them only when the skill tells it to.

With /skill:name, Pi puts the SKILL.md body, without frontmatter, into your message inside a <skill name=... location=...> block that notes the skill directory for relative paths. When the model picks a skill itself, it reads SKILL.md with its read or bash tool. Reference files and scripts are never preloaded: the model reads or runs them with its normal tools when the instructions call for it.

Not supported

No. Codex reads only name, description and metadata.short-description from SKILL.md. An allowed-tools field is ignored, and a skill can't change the model or approval settings. agents/openai.yaml can declare MCP servers the skill needs under dependencies.tools, but that doesn't grant or pre-approve tools.

The bundled skill-creator validator accepts allowed-tools in frontmatter, but the runtime doesn't act on it.

Yes. allowed-tools pre-approves the listed tools (for example Bash(git commit *)) for the turn that invokes the skill, and disallowed-tools removes tools while it is active; both clear when you send your next message. model and effort switch the model or effort level for the rest of that turn.

allowed-tools grants access but doesn't restrict it: other tools stay callable under your normal permission rules.

Workspace trust doesn't gate allowed-tools in repository skills; managed allowManagedPermissionRulesOnly makes Claude Code ignore it.

Since 2.1.304, plugin-only hook policy also withholds allowed-tools from a main-conversation skill whose hooks are excluded.

Not supported

No. Cursor's SKILL.md frontmatter has no allowed-tools, model or similar field; supported fields are name, description, paths, disable-model-invocation, icon, color and metadata (plus user-invocable). Tool approvals come from your normal CLI settings, though with Auto-review enabled the classifier can read an invoked skill's files before deciding whether a tool call needs approval.

Not supported

No. OpenCode reads only name, description, metadata and disable-model-invocation from the frontmatter, so allowed-tools and model are ignored. Tool access and model come from the agent. Your skill permission rules govern only whether the model may load a skill.

Not supported

No. The docs list allowed-tools as an experimental Agent Skills field, but the loader ignores it. Pi uses only name, description and disable-model-invocation. A skill cannot restrict tools, pre-approve tools or change the model.

Not supported

No. A skill always runs in the current conversation; there is no frontmatter option to fork it into a subagent. The model is told to read skill instructions itself rather than hand them to a subagent, though subagents can still do task work if the skill says to.

Yes. Set context: fork and the skill body becomes the prompt for a new subagent of the type named in agent (Explore, Plan, general-purpose by default, or a custom agent from .claude/agents/), which doesn't see your conversation history. It runs in the background by default; set background: false to wait for the result in the same turn.

With context: fork, the model field sets the forked subagent's model.

Background forks run with the narrower background-subagent tool set, and their edits aren't covered by /rewind checkpoints.

Not supported

No. A skill runs in the current conversation, either for one message or as a sticky Custom Mode; there is no frontmatter option to run it in a forked context or subagent. For isolated work, define a subagent (the built-in /create-subagent skill helps) and have the skill tell the agent to delegate to it.

Not supported

No. Whether the skill tool or an @ mention loads it, the skill's content lands in the current conversation. No frontmatter field runs a skill in a subagent or forked context.

Not supported

No. A skill always runs in the current conversation, either as instructions the model reads or as text added to your message. There is no frontmatter field for running it in a subagent or a forked context.