Claude Code Slash Commands

A useful team command contains the inputs, the evidence to inspect and the shape of the answer. Think of it as a work order stored beside the code. Typing its name fills out that work order for the current task.

Start with /plan, /diff, /context and /compact. Then add /team-pr-check from the templates below. Review is a strong first use case because the same questions about permissions, data and tests come up on every change.

The Built-in Commands Worth Knowing

Enter these at the start of a message inside Claude Code. Square brackets mean optional arguments; angle brackets mean required arguments. This selection preserves the command syntax in Anthropic's current commands reference, checked October 13, 2026. Availability varies by platform, plan and environment.

Use /compact when continuing the same job and /clear when changing jobs. For an ongoing feature, a useful instruction is /compact keep the acceptance criteria, unresolved risks, and exact test commands.

/release-notes opens Claude Code's changelog. It does not draft your application's release notes. The custom command below deliberately uses a different name.

For the habits around these controls, use Claude Code best practices.

Bundled Skills Also Appear in the Command Menu

Some slash entries hand Claude a procedure to follow. They are bundled skills, distinct from the CLI's fixed controls:

• /code-review reviews a diff or another supported target. /review is its alias. Adding --fix requests edits; adding --comment requests posted review comments.
• /simplify reviews changed code for cleanup and applies fixes.
• /verify builds and runs the application to check behavior.
• /doctor diagnoses setup problems and proposes fixes.

Choose a plain review when you want findings before changes. These commands' full signatures, prerequisites and availability are in the bundled entries in the commands reference.

Custom Commands Are Skills Now

For new work, save a Markdown instruction file at .claude/skills/<name>/SKILL.md in the repository. Commit it so teammates receive the same procedure. Put personal procedures in ~/.claude/skills/<name>/SKILL.md.

The older .claude/commands/<name>.md format still works. Both forms create /<name> commands. A skill directory can also hold templates, reference documents and scripts. Prefer that format as the procedure grows. Anthropic's skills guide

Where Plugin and MCP Commands Come From

Plugins package capabilities for reuse. Their skills/<name>/SKILL.md folders create namespaced commands such as /plugin-name:skill-name. Older plugin commands live in commands/. Those folders belong at the plugin root, alongside the .claude-plugin/ directory containing the manifest, not inside it. Use /plugin to manage plugins and /reload-plugins after changes. Plugin components

Start with project skills while the process belongs to one codebase. Consider a plugin when you need to maintain and distribute the same process across repositories. The best Claude Code plugins guide covers existing packages worth evaluating before building another.

MCP prompts come from connected servers. MCP, the Model Context Protocol, connects Claude Code to outside tools and data. A server can also publish reusable prompts. The menu displays them as /servername:promptname (MCP); /mcp__servername__promptname also invokes them. They appear only when the connected server exposes those prompts. An integration offering tools does not automatically provide every prompt you might want. MCP prompt documentation

MCP prompt arguments are split on whitespace and follow the server's declared parameters. The prompt's result enters the conversation. Do not assume a server prompt has the same argument handling as a local skill.

Write the File, Then Pass the Job's Inputs

Frontmatter is the small YAML settings block before the Markdown instructions. Its opening --- must be the file's first line. The fields below cover these templates:

allowed-tools is a permission grant, not a restriction to only those tools. All frontmatter fields are optional; description is recommended. Legacy command files accept the same fields except name and paths. Frontmatter reference

Arguments: $ARGUMENTS inserts the full input string. $0 or $ARGUMENTS[0] means the first argument; $1 means the second. Named arguments map to positions in order. Quote a multiword positional value. argument-hint documents inputs; the procedure still needs to check them. Argument substitution

The templates omit name, so the folder supplies it. Their frontmatter also works in the legacy command-file format. Keep lasting repository facts in CLAUDE.md team memory, and keep the steps for a specific job in its skill.

Five Custom Commands Your Team Can Paste In

Create each folder shown below and paste its block into SKILL.md. Run /reload-skills to rescan the new files. These are original templates for you to adapt, not bundled Anthropic commands or claimed test results.

The order below prioritizes repeatable engineering checks, then communication. The templates use local repository evidence wherever possible. They do not require a connected issue tracker or PR service to produce a useful result.

A PR Review Checklist for Changes Near Customer Data

A small SaaS team could use this before requesting human review. It asks the same questions about tenant isolation, authorization and test coverage even when the author is in a hurry. Its value is a more consistent handoff, with each finding tied to a location and failure case.

Save as .claude/skills/team-pr-check/SKILL.md. Invoke with /team-pr-check main to review the current branch against its merge base with main.

---
description: Review a branch against the team's business-risk checklist
argument-hint: "[base-ref]"
disable-model-invocation: true
---

Review the current branch against this base ref: $ARGUMENTS
If no base is supplied, ask for it. Confirm it exists locally.
Read CLAUDE.md and any repository review guidance first.
Inspect the diff from the merge base to HEAD. Report uncommitted
changes separately; do not silently mix them into the branch review.

Check:
- Authorization and tenant boundaries on every changed data path.
- Validation, failure handling, retries and duplicate side effects.
- Schema compatibility, rollout assumptions and rollback options.
- Regression coverage for the changed behavior.
- Secrets, sensitive logs and changes to public contracts.

For each finding: severity, file and line, triggering scenario,
user impact and a concrete repair or test. Separate verified findings
from questions. Mark checks you could not assess as unknown.
Return findings first, then the checklist with pass/fail/unknown
and supporting evidence. If none are found, say so and name gaps.
Review only. Do not edit files, post comments, approve or merge.

A checklist earns its place when it encodes your actual failure modes. Replace generic checks with the boundaries that matter in your product, such as account ownership, billing state or permissions inherited through teams.

A Test-first Fix for a Repeatable Bug

A founder maintaining a live product could use this when a bug report has a concrete reproduction. It makes the failing behavior and the regression check part of the work order, so a plausible patch does not become the whole deliverable.

Save as .claude/skills/team-test-first-fix/SKILL.md. Invoke with /team-test-first-fix duplicate webhook events create duplicate invoices.

---
description: Reproduce a bug with a failing test before fixing it
argument-hint: "[bug description or local issue file]"
disable-model-invocation: true
---

Bug: $ARGUMENTS
If the expected behavior is unclear, ask before changing code.
Read CLAUDE.md, inspect the working tree and preserve unrelated edits.
Find the relevant code and the repository's existing test runner.
Use local fixtures or mocks; do not call production services.

Add the smallest regression test that demonstrates the reported bug.
Run it before changing implementation. Confirm that it fails for
this bug, not because the environment or test setup is broken.
If you cannot demonstrate that failure, explain the blocker and stop.

Make the smallest implementation change that fixes the behavior.
Rerun the regression test and relevant nearby tests. Do not weaken
assertions to obtain a pass or expand into unrelated refactoring.

Report the cause, changed files, failing-before evidence,
passing-after evidence and any tests you could not run.
Do not commit, push or deploy.

This is a fit for reproducible defects. For an intermittent production incident with missing evidence, start by investigating rather than forcing the command to invent a failing test.

A Migration Plan Before Touching a Shared System

A team changing a database schema or replacing an API could use this to expose sequencing and compatibility questions before implementation. The useful output is a plan someone can challenge, especially around mixed old and new versions running together.

Save as .claude/skills/team-migration-plan/SKILL.md. Invoke with /team-migration-plan "billing storage" "new invoice schema".

---
description: Plan a migration with compatibility checks and rollback gates
argument-hint: "[scope] [target-state]"
arguments: [scope, target]
disable-model-invocation: true
---

Plan a migration of $scope to $target.
If either input is missing or ambiguous, ask for clarification.
Read CLAUDE.md and inspect the current implementation and consumers.
Do not edit files, execute migrations or connect to production.

Describe the current state with file references. List affected data,
APIs, background jobs, integrations and deployment dependencies.
Separate verified facts from assumptions that need an owner.

Propose small phases with dependencies, acceptance checks and a
stop/go decision for each. Include compatibility between old and new
versions, backfill validation, retries and observability.
For each phase, describe rollback or recovery. Flag irreversible
steps and data that a code rollback cannot restore.

Return a reviewable plan, open questions and the smallest safe pilot.
Do not invent a duration, data volume or owner.

The instruction to plan does not change Claude Code's permission mode. If you want the session in Plan Mode as well, enter /plan before invoking this skill. Treat the written procedure and the session's tool permissions as separate controls. Plan Mode

Release Notes for Your Product

A developer handling releases could use this to turn a defined change range into a customer-facing draft. It reduces the work of translating commits into user impact while requiring evidence for each claim.

Save as .claude/skills/team-release-notes/SKILL.md. Invoke with /team-release-notes previous-release HEAD, replacing previous-release with an existing tag or commit.

---
description: Draft product release notes from a verified Git range
argument-hint: "[base-ref] [head-ref]"
arguments: [base, head]
disable-model-invocation: true
---

Draft release notes for $base..$head.
If either ref is missing, ask. Confirm both resolve locally.
Read CLAUDE.md and the project's existing release-note format.
Inspect commits in the range and compare the endpoint trees.
Use the changed code and tests to verify what each change does.

Group the draft into Added, Changed, Fixed and Breaking Changes.
Omit empty sections. Describe user impact without exposing internal
secrets or vulnerability details that need coordinated disclosure.
Attach a commit or file reference to each item for the reviewer.
Do not claim a change is deployed, enabled for every customer or
faster by a measured amount without evidence of that fact.

Finish with upgrade actions, unresolved questions and any changes
excluded because their impact could not be established.
Return a draft in chat. Do not edit the changelog, tag a release,
publish, send messages or deploy.

A code range proves what changed in the repository. It does not prove which customers received the change. Confirm rollout status before publishing the draft.

A Weekly Changelog for the Team

An engineering lead could use this for a weekly update to product and support. It separates merged work from verified releases, so the update does not accidentally announce something still behind a flag.

Save as .claude/skills/team-weekly-changelog/SKILL.md. Invoke with /team-weekly-changelog START_DATE END_DATE main, replacing the dates with ISO timestamps that include their timezone. The window includes the start and excludes the end.

---
description: Draft a weekly engineering changelog from branch history
argument-hint: "[since] [until] [branch]"
arguments: [since, until, branch]
disable-model-invocation: true
---

Prepare a weekly changelog for $branch from $since inclusive to
$until exclusive. If an input is missing, ask. Confirm the timezone
and that the branch exists locally. State whether its checkout may
be stale; do not fetch or assume it matches the remote.

Read CLAUDE.md and the team's update format. Inspect commits reachable
from the branch, filtering by committer timestamp in this window.
Explain that commit timestamps do not prove merge or release dates.
Read diffs for claimed outcomes. Group related changes into themes
and avoid counting a merge and its constituent commits as separate
outcomes. Separate product changes, fixes and maintenance.

For each item, give its impact and a commit or file reference.
Label release status unknown unless deployment evidence is available.
Do not infer blockers, revenue, adoption or completion percentages
from commit messages. List evidence gaps at the end.
Return a concise draft in chat. Do not write files or send the update.

Keep release notes and weekly updates separate. A release has a defined code boundary and a customer audience. A weekly update has a reporting window and may include useful work that has not shipped.

What Makes a Command Worth Keeping?

Measure the repeated work around the model, not how impressive its first answer looks.

Your weekly value calculation is: runs × (old preparation and correction time − new preparation and correction time) × your team's hourly cost − additional model spend − maintenance time valued at that hourly cost. Fill it with your own measurements. A longer prompt that produces more review work can lose money even if it feels more automated.

The budget line most likely to change is senior developer time spent explaining the same process and repairing incomplete handoffs. The procedure still needs maintenance when your architecture or release process changes.

A saved command also still consumes model usage when Claude follows it. /usage reports token-cost estimates and plan usage information; a displayed API cost estimate is not a subscription invoice. Anthropic's cost documentation

Two Things Worth Building Around These Commands

The templates are useful internal tools. Turning them into a product requires a harder advantage than storing a prompt.

Strongest Opportunity: Repository-specific Review Checks

A small software team could pay for a maintained review package that understands its own high-risk boundaries: which tables belong to an account, which actions affect billing and which tests must accompany a change.

DataForSEO's Google US English keyword overview returned 1,300 estimated monthly searches for “ai code review” on October 13, 2026. That indicates interest in the job, not demand for a particular Claude Code plugin. DataForSEO Keyword Overview

The smallest sellable version could combine a project checklist, supporting architecture notes and an evaluation set of past bugs. Have it produce evidence-backed findings against those examples before distributing it as a plugin.

The catch is strong competition: Claude Code already includes review capabilities, and CodeRabbit sells code review tools. A generic review prompt is weak differentiation. I would choose this opportunity only with access to a specific team's failure history and someone responsible for keeping the checks accurate.

Smaller Opportunity: Release Communication With Evidence

A product team could use a maintained workflow that maps repository changes to customer-facing release notes and an internal support brief, with source references and an explicit rollout-status check.

The same keyword overview returned 70 estimated monthly searches for “release notes generator.” That is a modest search signal, so I would start with a service or an internal workflow before building standalone software. DataForSEO Keyword Overview

The smallest version could produce drafts from a chosen Git range in the team's established format. The difficult part is connecting changes to flags, deployments and actual customer availability. The command can organize evidence; it cannot manufacture evidence the team does not record.

The Limits That Matter in a Business Codebase

A command standardizes instructions. Your tests, review and release controls still decide whether the result is acceptable. Treat the five templates as starting procedures and review changes to them alongside application code.

A skill's full content loads when it is used, so keep the procedure concise and put detailed references in supporting files. Personal skills can take precedence over project skills with the same name; skills can also shadow built-ins in local terminal sessions. Use distinctive names and inspect the source when teammates get different behavior. Skill loading and precedence

For permissions, configure the actual tool rules separately. A sentence saying “review only” tells Claude what you intend; it is not an operating-system restriction. Claude Code permissions

Your Monday Move

Commit /team-pr-check first. Replace its generic bullets with the checks your last troublesome change should have passed. Run it on a completed change whose outcome you understand, compare the findings with the real issue, and revise the procedure before making it a team habit. Add the release and weekly-update commands when their output formats are agreed.

If you want these workflows connected to your business systems, I build AI automations around the checks your team actually needs.