Claude Code Custom Slash Commands: Make /review, /handoff, and /release Team Patterns

You paste the same review checklist again. You reconstruct the release steps from memory. At the end of a long Claude Code session, you still have to write the handoff note by hand. The better you get at using an AI coding agent, the more these small repeated prompts start to matter.

Custom slash commands turn those repeated prompts into short team-owned names. A command such as /review, /handoff, or /release is not only a shortcut. Used well, it becomes a shared operating pattern for how your team reviews code, transfers context, and decides whether something is ready to ship.

This article follows the current Claude Code Skills documentation and Commands reference, checked on June 3, 2026. The important update is that custom commands have been merged into Skills. Existing .claude/commands/*.md files still work, but new team workflows are usually better designed as .claude/skills/<name>/SKILL.md.

Start Here: A Command Is a Reusable Work Procedure

In Claude Code, commands are messages that start with / inside a session. The official command reference says the command is recognized at the start of your message, and text after the command name is passed as arguments. That means /release 1.8.0 can pass 1.8.0 into the workflow, while /handoff frontend reviewer can tell the handoff command who the note is for.

A Skill is a reusable instruction package that Claude Code can load. In plain terms, it is a small playbook for Claude: when to use it, what steps to follow, which inputs matter, and what output shape you expect. Older custom command files under .claude/commands/ are still supported, but Skills add a directory structure, frontmatter, supporting files, named arguments, and better reviewability.

There is one practical naming trap. Current Claude Code installations may already include built-in or bundled commands such as /review, /code-review, and /security-review. Before you create a custom /review, type / in Claude Code and check the menu. If the name already exists, use /team-review, /review-note, or another team-specific name. The idea in this article is the review pattern; the exact command name should avoid conflicts in your environment.

File Layout: Prefer Skills, Keep Commands for Compatibility

For team workflows, put the files in the project rather than only in your home directory. Project-level Skills can be committed, reviewed, and changed through pull requests. Personal Skills are still useful, but they should not hold the rules everyone depends on.

Location	Example	Best use
Project Skill	.claude/skills/team-review/SKILL.md	Shared review, release, investigation, onboarding routines
Project Command	.claude/commands/handoff.md	Existing lightweight commands or compatibility during migration
Personal Skill	~/.claude/skills/my-note/SKILL.md	Personal notes and daily private workflows
Personal Command	~/.claude/commands/my-command.md	Temporary personal shortcuts

A clean repository layout looks like this:

.claude/
├── commands/
│   └── handoff.md
└── skills/
    ├── team-review/
    │   ├── SKILL.md
    │   └── checklists/
    │       └── review.md
    └── release-prep/
        ├── SKILL.md
        └── scripts/
            └── collect-release-notes.sh

The mental model is simple: the repository stores the team procedure, the slash menu exposes it as a command, the user passes arguments, and Claude Code combines the procedure with the current task context.

flowchart LR
  A[".claude/skills or .claude/commands"] --> B["Command such as /team-review"]
  B --> C["Arguments: $ARGUMENTS or $version"]
  C --> D["Claude Code loads the instructions"]
  D --> E["Review, handoff, or release preparation"]
  E --> F["A human reviews and decides whether to merge or ship"]

After adding or editing a Skill, check whether it appears in the / menu. If the current session does not pick it up, use /reload-skills or start a fresh Claude Code session. Also check the description text: it is part of how people discover the workflow.

Copy-Paste Starter Template

Start small. The following example creates /team-review, which avoids a likely conflict with built-in /review.

mkdir -p .claude/skills/team-review
cat > .claude/skills/team-review/SKILL.md <<'EOF'
---
description: Review the current change with the team's checklist before a pull request or merge.
argument-hint: [target-branch-or-path]
disable-model-invocation: true
---

You are performing a read-only team review.

Target: $ARGUMENTS

If the target is empty, ask which diff, branch, or path to review before scanning broadly.
Do not edit files.
Do not run destructive commands.

Review from these perspectives:
1. Correctness bugs and edge cases
2. Security and privacy risks
3. Test coverage and missing verification
4. Consistency with existing code patterns
5. Documentation, migration notes, and user-facing copy

Output:
- Findings first, ordered by severity
- File path and line number when available
- One short suggestion for each issue
- "No blocking findings" only if you found none
EOF

Open Claude Code and call it with /team-review main, /team-review src/auth, or another focused target. disable-model-invocation: true prevents Claude from choosing this Skill automatically. That is useful for review and release workflows because they should normally run only when a person asks for them.

Use Case 1: Turn /review into a Team Checklist

The value of a review command is consistency. Without a shared checklist, one reviewer may focus on naming, another on security, and a third on tests. The command should define severity, scope, and output format so both Claude and humans review with the same expectations.

If your environment already has /review, use team-review.md or a team-review Skill. If it does not, .claude/commands/review.md can still create a /review command.

---
description: Team review checklist for the current branch or specified path.
argument-hint: [branch-or-path]
disable-model-invocation: true
---

Review target: $ARGUMENTS

Read the diff or files related to the target and report only review findings.
Do not rewrite code unless the user asks for fixes after the review.

Severity:
- P0: data loss, auth bypass, secret leak, production outage
- P1: correctness bug, missing validation, broken user flow
- P2: maintainability, unclear naming, duplicated logic
- P3: optional cleanup

Required checks:
1. Is the change scoped to the request?
2. Are tests or manual verification enough for the risk?
3. Are error paths and empty states handled?
4. Does the code follow existing local patterns?
5. Could the change break monetization links, analytics, or release notes?

Return a short summary after the findings.

The important line is “Do not rewrite code.” A review workflow that silently edits files becomes an implementation workflow. Keep the first pass read-only, then run a separate fix task after the findings are accepted.

Use Case 2: Use /handoff for the Next Human or Agent

Long sessions lose value when the ending is unclear. A handoff command turns the end of a task into a structured note for tomorrow’s you, a teammate, or another agent that will continue the work.

---
description: Create a concise handoff note for the current task.
argument-hint: [next-owner-or-audience]
disable-model-invocation: true
---

Create a handoff note for: $ARGUMENTS

Include these sections:
1. Goal: what the task was trying to achieve
2. Changed files: important files and why they changed
3. Decisions: tradeoffs or assumptions made during the work
4. Verification: commands run, screenshots checked, or checks not run
5. Risks: unresolved issues, fragile areas, or things needing human review
6. Next steps: the smallest useful next action

Keep it factual. Do not hide failed attempts. If something was not verified, say so clearly.

This is especially useful on monetized content sites and production applications. Internal links, CTAs, tracking events, screenshots, and manual checks are easy to forget when the work spans several files. A handoff command keeps those details visible.

Use Case 3: Use /release for Release Preparation, Not Publishing

Release commands deserve conservative design. The goal is not to let Claude publish for you. The goal is to collect context, draft notes, list blockers, and leave the final release decision with a human.

This template uses named arguments. The current docs describe arguments as names mapped to positional inputs, so the first argument becomes $version.

---
description: Prepare a release checklist and changelog draft without publishing.
argument-hint: [version]
arguments: [version]
disable-model-invocation: true
---

Prepare release $version.

Allowed work:
1. Inspect the current diff, package metadata, and changelog
2. Draft a changelog section for $version
3. Suggest verification commands
4. List release blockers and rollback notes
5. Propose a commit message

Safety rules:
- Do not run git push
- Do not publish packages
- Do not deploy to production
- Do not delete files
- Ask before changing version files

Output:
- Release summary
- Checklist
- Blockers
- Commands the user should run manually

This is a release-prep command, not a release button. If your team eventually automates publishing, keep that in CI/CD where approvals, logs, and rollback rules are explicit.

Arguments: Start with $ARGUMENTS

For most custom commands, $ARGUMENTS is enough. /handoff backend reviewer places backend reviewer into $ARGUMENTS. The current docs also support $ARGUMENTS[0], $0, and named arguments such as $issue or $branch when you declare them in frontmatter.

---
description: Prepare an issue-specific work plan.
argument-hint: [issue] [branch]
arguments: [issue, branch]
disable-model-invocation: true
---

Issue: $issue
Branch: $branch
All arguments: $ARGUMENTS

Create a plan that:
1. Restates the issue in plain language
2. Lists files to inspect first
3. Identifies likely tests
4. Names one thing that should not be changed

Quote multi-word arguments when you want them to stay together: /plan-issue "login redirect bug" fix-login. Be careful with older snippets that assume $1 is the first argument. The current documentation describes $0 as the shorthand for the first positional argument.

Version and Review Workflow

Treat project Skills and Commands like code. They influence what gets reviewed, what gets missed, and what the team considers “done.” A change to .claude/skills/release-prep/SKILL.md should be visible in a pull request, not hidden inside an unrelated feature branch.

Rule	Why it matters
Commit .claude/skills/ to Git	You can see who changed the workflow and when
Allow command-only pull requests	Procedure changes do not disappear inside app diffs
List commands in README or CLAUDE.md	New team members can discover them
Ban destructive actions in the prompt	Prevent accidental push, publish, deploy, or deletion
Review the command set monthly	Remove stale commands before they confuse people

Pair this article with the Claude Code getting started guide, CLAUDE.md best practices, and Claude Code hooks guide when you design a team rollout.

Pitfalls and Security Notes

The biggest mistake is treating a custom command as inherently safe because it is short. It is still a powerful prompt. If you use dynamic context injection with ! backticks, Claude Code runs the shell command and inserts the output before Claude reads the Skill. That is useful, but it deserves a strict read-only rule.

---
description: Collect read-only git context for release notes.
disable-model-invocation: true
---

Current status:
!`git status --short`

Recent commits:
!`git log --oneline -20`

Summarize the release notes from the information above.
Do not run write operations.

Keep dynamic commands to safe inspection commands such as git status and git log. Do not include rm, git clean, git push, npm publish, curl ... | sh, or production-impacting scripts. Be equally careful with allowed-tools: granting broad Bash access can reduce confirmation prompts in a way that surprises the team. Start with read-only tools, then add permissions only when the workflow genuinely needs them.

Concrete failure cases are easy to reproduce. A custom /review conflicts with a built-in command. A command lives only in one developer’s home directory. A Skill body grows so long that it wastes context every time it loads. An empty argument makes Claude scan the whole repository. A release command includes publishing. Each problem comes from trying to be helpful too quickly. Start read-only, keep the target small, and make human confirmation part of the design.

CTA: Turn the Templates into Your Operating System

These templates are valuable only after they match your repository. Solo builders can start with the free Claude Code cheatsheet and keep the safe command patterns nearby. If you want reusable review, release, and handoff templates, browse the ClaudeCodeLab products. If your team needs permissions, CLAUDE.md, Skill review, CI boundaries, and onboarding designed together, use the Claude Code training and consultation page.

What I found after trying this in Masa’s workflow was simple: three commands were enough. /team-review, /handoff, and /release-prep covered most repeated work without turning Claude Code into an unsafe deploy tool. The biggest improvement came from defining /release as a command that gathers evidence for a human decision, not as a command that publishes. Custom slash commands work best when they help a team stop, check, and hand off with the same standard.