Claude Code Commands

Slash commands give a short name to a repeatable Claude Code workflow. A command can prepare a code review, create a commit, or guide a plugin creation process. The listed commands come from linked projects, so you can inspect their Markdown or plugin source before installing. A command name is an entry point, not a guarantee that its actions are safe.

Choose a command for an action you want to invoke explicitly, such as reviewing the current diff or preparing release notes. Read its instructions to see what it considers input and whether it changes files. A short slash name can hide a long workflow, so inspect the behavior before using it in a shared repository.

Use the card’s installation command to obtain the component, then use the documented slash name to run the workflow. Installation and invocation are separate steps. For plugin commands, the displayed name may include a plugin namespace; check the menu rather than assuming a generic name is available.

Built-in commands are shipped by Claude Code and manage features such as settings or agents. Custom workflows can be authored as skills and invoked with a slash name; legacy Markdown command files under `.claude/commands/` are also found in many community projects. Check the current Claude Code docs when creating a new workflow, and use the file format supported by your installed version.

Built-in commands operate Claude Code itself, while a custom command usually supplies instructions for a task. A custom review workflow cannot replace the behavior of a built-in settings command just by using a similar label. Give your own commands descriptive names and check for conflicts with installed plugins.

For a new reusable workflow, consider the skill format so instructions and supporting resources stay in one folder. Existing command files remain common in repositories. Preserve the format expected by the project you install, and avoid copying the same workflow into both locations without checking how it appears in the menu.

For an existing plugin command, install the parent plugin using its card and then invoke the named slash command in Claude Code. For a small local workflow, save a Markdown file in `.claude/commands/` for a project or use the newer skill format in `.claude/skills/<name>/SKILL.md`. The template below is intentionally read-only and asks for a report, making it easy to adapt.

The template below can be saved as .claude/commands/review-changes.md. It asks for findings and explicitly excludes edits, commits, and pushes. For a skill-based version, put the instructions in .claude/skills/review-changes/SKILL.md and add the frontmatter supported by that format instead of duplicating both versions.

After saving, check the available slash commands and try the workflow on a small diff. If it needs extra arguments, document a concrete invocation and what each argument means. If it depends on an external CLI, verify that dependency separately so an installation problem is not mistaken for a bad prompt.

A useful command states its input, steps, and expected output. The example template requests a concise review of changed files without committing or pushing. Try it on a small repository, then revise wording as the team’s conventions change. When a command depends on `git`, `gh`, or external services, document those prerequisites alongside the template so someone else can reproduce the result.

The output below is illustrative, not the result of a review of your files. A useful real response should identify the actual path, describe an observable issue, and explain how to verify it. Include a no-issues outcome in your own instructions so the command is not encouraged to manufacture findings.

When adapting the template for a write operation, separate preparation from publication. For example, a release-note command can draft a file for review before a later step publishes it. Keep the expected side effects visible in the instructions and test the command on a branch where changes can be inspected.