7 個值得提交至程式碼庫的 Claude Code 斜線命令，附各自的 Markdown 檔案

Book: Ship It — the pragmatic startup tech stack
Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go
My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
Me: xgabriel.com | GitHub

Review my branch against main. List bugs and missing tests with file and line. Don't edit anything.

If your team works with a coding agent, some version of that prompt gets retyped over and over, worded a little differently each time and by a different person.

Put it in a Markdown file, commit it, and it becomes /review-branch for anyone who opens the repo in Claude Code. Below are seven of those files, complete, ready for .claude/commands/. Each has a description line, and each one that takes input reads it from $ARGUMENTS.

Where command files live in October 2026

Claude Code and Codex give different answers, and one of them changed recently.

Claude Code. A file at .claude/commands/review-branch.md creates /review-branch. The skills docs say "Custom commands have been merged into skills": a command file and a skill at .claude/skills/<name>/SKILL.md create the same slash command and behave the same way. Command files keep working and accept the same frontmatter as skills, except name and paths. The docs recommend a skill for new work, because a skill folder can also hold supporting files. If a skill and a command share a name, the skill runs.

Every file below works either way. To turn one into a skill, move it to .claude/skills/<name>/SKILL.md. The folder name becomes the command.

Codex. OpenAI's custom prompts page now marks custom prompts as deprecated and points you to skills instead. Those prompts lived in ~/.codex/prompts, in your local Codex home, and the same page notes they are not shared through your repository. The shared route is a Codex skill in .agents/skills/<name>/SKILL.md, which must have a name and a description. In the Codex CLI you run /skills or type $ to mention one.

---
name: review-branch
description: Review this branch against main. Report only.
---

Review the work on this branch against `main`.
List bugs and missing tests with file:line.
Do not edit any file.

Codex can also pick a skill on its own when your task matches its description. To keep one manual, add agents/openai.yaml inside the skill folder:

policy:
  allow_implicit_invocation: false

The Codex skills page doesn't document an argument placeholder, so write the details in the same message as the mention.

One trap when you port files between the two. In Claude Code, $0 is the first argument (shorthand for $ARGUMENTS[0], counted from zero). In Codex's deprecated prompts, $1 was the first. $ARGUMENTS means all of them in both, which is why every file below uses only $ARGUMENTS.

Two frontmatter fields do most of the work. With disable-model-invocation: true, Claude can't load the command on its own, and its description stays out of context until you call it. I set that on the four commands that write or delete. allowed-tools pre-approves tools for the turn that runs the command, and the commands that inject git output with a ! line need it: per the docs, outside auto mode, an injected command that your permission rules don't allow aborts the whole invocation.

Three commands that only read

1. .claude/commands/review-branch.md

---
description: Review this branch against a base branch
argument-hint: "[base branch, default main]"
allowed-tools:
  - Bash(git status *)
  - Bash(git log *)
  - Bash(git diff *)
---

Review the work on this branch.
Base branch: $ARGUMENTS (use `main` if this is empty)

Current state:
!`git status --short --branch`

1. Run `git log --oneline <base>..HEAD` and
   `git diff <base>...HEAD`.
2. List bugs, missing tests and risky changes,
   most serious first, each with file:line.
3. Say which findings you are unsure about.
4. Do not edit any file. Report only.

The ! line runs before Claude sees the prompt, and its output replaces it. Keep $ARGUMENTS out of that line: arguments are untrusted text, and you don't want them inside a shell command. So the base branch goes into the instructions, and Claude runs the diff itself. The three dots in <base>...HEAD show only what this branch changed since it split off.

2. .claude/commands/explain-diff.md

---
description: Explain a diff in plain words, file by file
argument-hint: "[commit or range, default uncommitted]"
allowed-tools:
  - Bash(git diff *)
  - Bash(git show *)
---

Explain these changes: $ARGUMENTS

- Empty: use `git diff HEAD` (staged and unstaged).
- One commit: use `git show <commit>`.
- A range like `main..HEAD`: use `git diff <range>`.

For each file: what changed, the likely reason,
and anything that looks unintended. Finish with
a short paragraph a reviewer could paste into a
PR comment. Do not edit anything.

3. .claude/commands/pr-body.md

---
description: Draft a pull request description for this branch
argument-hint: "[base branch, default main]"
allowed-tools:
  - Bash(git log *)
  - Bash(git diff *)
---

Base branch: $ARGUMENTS (use `main` if empty)

1. Read `git log <base>..HEAD` and
   `git diff --stat <base>...HEAD`.
2. If `.github/pull_request_template.md` exists,
   fill in that template. Otherwise use these
   headings: What changed, Why, How to test,
   Risks.
3. Print the body in one markdown block.
4. Do not push and do not run `gh pr create`.

These three leave disable-model-invocation off on purpose. They change nothing, so it's fine if Claude reaches for /explain-diff when you ask "what did this commit do?"

Two commands that make the agent prove it first

4. .claude/commands/test-first.md

---
description: Write a failing test first, then make it pass
argument-hint: "<behaviour to add>"
disable-model-invocation: true
---

Behaviour to add: $ARGUMENTS

1. Find the test runner and test layout this repo
   already uses. Do not add a new framework.
2. Write one test for the behaviour. Run it and
   show that it fails, and why it fails.
3. Stop. Wait for me to reply "go".
4. Write the smallest change that makes the test
   pass. Run the full suite and report the result.

Step 3 is the point. A test that has never failed in front of you might not test anything.

5. .claude/commands/repro-bug.md

---
description: Reproduce a bug before anyone tries to fix it
argument-hint: "<issue number or bug description>"
allowed-tools:
  - Bash(gh issue view *)
disable-model-invocation: true
---

Bug: $ARGUMENTS
If that is an issue number, read it first with
`gh issue view <number> --comments`.

1. Write the smallest test or script that shows
   the bug. Run it and paste the failure.
2. If it does not reproduce, stop and list what
   you tried. Do not guess at a fix.
3. With a reproduction in place, propose a fix
   and wait for my OK before you change code.

gh issue view takes a number or a URL, and --comments pulls in the thread, which is often where the real repro steps are.

Two commands for the boring end of a branch

6. .claude/commands/changelog-entry.md

---
description: Add an entry under Unreleased in CHANGELOG.md
argument-hint: "[Added|Changed|Fixed|Removed|Security]"
allowed-tools:
  - Bash(git log *)
disable-model-invocation: true
---

Section: $ARGUMENTS (choose from the commits if
this is empty)

1. Read `git log --oneline main..HEAD`.
2. Add one entry under the Unreleased heading in
   CHANGELOG.md, in that section. Create the
   section if it is missing.
3. Write for users of the project: what they
   will notice, not how it was done.
4. Change no other file.

The section names come from Keep a Changelog, which also suggests an Unreleased section at the top for changes that haven't shipped yet.

7. .claude/commands/cleanup-worktree.md

---
description: Remove a merged worktree and its branch
argument-hint: "<worktree path>"
allowed-tools:
  - Bash(git worktree list *)
  - Bash(git branch --merged *)
disable-model-invocation: true
---

Worktree to remove: $ARGUMENTS

All worktrees:
!`git worktree list --porcelain`

1. Find the record for that path above and its
   `branch` line (drop the `refs/heads/` part).
   If there is none, stop.
2. Run `git -C <path> status --porcelain`. If it
   prints anything, stop and show me.
3. Run `git branch --merged main`. If the branch
   is not listed, stop and tell me.
4. Run `git worktree remove <path>`, then
   `git branch -d <branch>`. Never add --force
   and never use -D.
5. Show `git worktree list` at the end.

This one has three layers of brakes. The two commands that delete aren't in allowed-tools, so they go through your normal permission rules, and in Manual mode Claude Code asks before any Bash command outside its read-only set. Git refuses too: git worktree remove won't remove a worktree with modified or untracked files unless you pass --force, and git branch -d needs the branch fully merged into its upstream, or into HEAD if it has none. The file forbids both escape hatches.

Commit the folder like any other code:

git add .claude/commands
git commit -m "Add shared agent commands"

Finding them again in Hermes IDE

I build Hermes IDE, so weigh this section with that in mind. Hermes runs each agent's own interface in a real terminal, so typing /review-branch into a Claude Code session there works the way it does anywhere else.

What version 2.3.4 adds is a Commands list above the session. The release notes (October 15) say it "includes your own commands and skills, each with a short description, and your recent ones." The bar it sits in now works the same way for every agent: Model, Plan and Review stay in the same place, and you can pin the ones you use. Clicking a command never touches what you were typing, and it only runs when the agent is waiting.

Seven commands is past the point where most people remember the names. A list with descriptions and your recent ones is the answer to "was it /pr-body or /pr-description?"

Hermes 2.3.4: the bar above a Claude Code session (Prompts, Context, Model, Plan, Review, Commands) with the Commands list open, showing pinned Context, Model, Plan and Review, then built-in commands such as Compact, Usage and Diff.

Hermes is free to download, source-available under BSL 1.1 on GitHub, and runs on macOS, Windows and Linux. It isn't affiliated with Nous Research, Anthropic or OpenAI.

Which prompt do you retype most often? If it isn't on this list, tell me in the comments.

If this was useful

/pr-body and /changelog-entry sit at the shipping end of the work, in the same repo as your CI config. Ship It covers the rest of that road for a small team: everything between localhost and production, from hosting and payments to auth, CI/CD and monitoring. If you'd like these commands one click away above Claude Code, Codex and the other agents, Hermes IDE is free.