Skills and Slash Commands

Plugin operations in v2.1.265–269

--plugin-dir accepts a parent folder, loads children with manifests, and detects additions/removals at runtime. Since v2.1.268, plugin install/uninstall/update/enable/disable support --json for automation. v2.1.269 adds claude plugin eval with JSON/HTML reports; inspect claude plugin eval --help for arguments. /output-style [name] lists/switches styles in Remote Control, cloud, and headless sessions.

official changelog · 2026-09-12 KST

Skills and slash commands turn repeated work into a named workflow. Use them after a pattern is stable enough that humans would otherwise paste the same instructions again and again.

Slash Commands

Slash commands are best for short, direct workflows:

• Run a release checklist.
• Generate a focused review prompt.
• Start a documented debugging routine.
• Prepare a handoff summary.

A command is only recognized at the start of your message; any text after the command name is passed to it as arguments. Type / to see every command available to you, or / plus letters to filter.

Example command body:

Inspect changed files, identify risky behavior changes, run the focused test if available, and
return findings first with file references.

Skills

Skills are better for multi-step workflows with reference material, scripts, or templates. A useful skill explains when to use it, what files to read, and what output to produce. Each skill is a directory whose SKILL.md is the required entrypoint; other files (templates, examples, scripts, reference docs) are optional and load only when referenced.

my-skill/
├── SKILL.md        # Main instructions (required)
├── template.md     # Template for Claude to fill in
├── examples/
│   └── sample.md   # Example output showing expected format
└── scripts/
    └── validate.sh # Script Claude can execute

Unlike CLAUDE.md content, a skill's body loads only when the skill is used, so long reference material costs almost nothing until you need it. Keep the body concise: once a skill loads, its content stays in context across turns, so every line is a recurring token cost.

Good skill contents:

• Trigger conditions.
• Required repository conventions.
• Scripts or templates to reuse.
• Verification requirements.
• Known failure modes.

Where Skills Live

Where you store a skill determines who can use it:

When skills share a name across levels, enterprise overrides personal, and personal overrides project. Plugin skills use a plugin-name:skill-name namespace, so they never conflict. The command you type comes from the skill directory name (.claude/skills/deploy-staging/ → /deploy-staging), or from the file name for a .claude/commands/ file.

Project skills load from .claude/skills/ in your starting directory and every parent directory up to the repository root, and Claude Code discovers nested .claude/skills/ directories on demand when you work with files in subdirectories (useful for monorepos). Claude Code watches these directories for changes during a session; use /reload-skills to force a re-scan after adding or editing skills on disk.

Frontmatter Discipline

If a workflow needs a specific reasoning level or model behavior, encode that in the command or skill frontmatter and keep the body operational:

---
description: Review handbook route changes for locale regressions.
---

Check route helpers, sitemap generation, localized links, and E2E coverage.

All frontmatter fields are optional; only description is recommended so Claude knows when to apply the skill. The most useful fields:

Arguments and Dynamic Context

Arguments passed after the command name are available via $ARGUMENTS (the full string), $ARGUMENTS[N], or the shorthand $N for the Nth (0-based) argument. If a skill does not include $ARGUMENTS, Claude Code appends ARGUMENTS: <your input> to the end so Claude still sees it.

---
description: Fix a GitHub issue
disable-model-invocation: true
---

Fix GitHub issue $ARGUMENTS following our coding standards, then write tests and commit.

A line beginning with !`<command>` runs the shell command before the skill is sent to Claude and replaces the placeholder with its output, so Claude receives real data rather than the command text. Use a fenced ```! block for multi-line commands. This is preprocessing, not something Claude executes.

## Current changes

!`git diff HEAD`

## Instructions

Summarize the changes above and flag any risks.

Current Command Surface

Recent Claude Code releases changed several command responsibilities:

/run, /verify, and /run-skill-generator require Claude Code v2.1.145 or later; /reload-skills requires v2.1.152 or later; the /simplify cleanup-only behavior and the ultra review level landed in v2.1.154. /run and /verify infer the launch from your project type and metadata; /run-skill-generator records a per-project recipe at .claude/skills/run-<name>/ for projects that need more than a standard launch.

For locked-down sessions, --disable-slash-commands disables all skills and commands for that invocation. To hide only bundled Claude Code skills and workflows, set disableBundledSkills: true or CLAUDE_CODE_DISABLE_BUNDLED_SKILLS=1; plugin, project, and user skills remain available, and built-in slash commands like /init remain typable but are hidden from the model.

Governance

Review commands and skills like production code. Remove stale ones, merge duplicates, and keep high-risk automation visible to the team. Treat checked-in project skills as trusted code: an allowed-tools entry can grant broad tool access once the workspace is trusted, so review project .claude/skills/ before trusting a repository.

Sources

• Skills: https://code.claude.com/docs/en/skills
• Commands: https://code.claude.com/docs/en/commands