Claude Codeのスラッシュコマンド7個でPR準備を15分短縮した話

Claude Cowork を社内AXに使っている私の実践ログです。社内固有名・個人名は伏せています。

PRを出すたびに、同じ内容を毎回書いている気がして——ある日、本気でキレた。

「変更点まとめ」「動作確認手順」「ロールバック手順」「影響範囲」。毎回手で書く。テンプレを Notion に置いてもコピペが面倒。先輩のレビュー前に「これ書いた?」と聞かれて差し戻されるのは、もう何回目か分からない。

結局、Claude Code のカスタムスラッシュコマンドに全部寄せた。7個作った。PR準備が15分縮んだ。15分は、コーヒーを淹れて1ページ仕様書を読む時間。地味に効く。

今日は私が実際に常用している7個を全部置いていく。コピペで動く。

なぜ Skill ではなくスラッシュコマンドにしたのか

これ、最初は全部 Skill にしようとしてやめた。

Skill は「自動的に呼ばれてほしい」処理に向いている。一方、PR準備みたいに「私が今これをやりたい」と能動的に呼ぶ処理は、スラッシュコマンドの方が圧倒的に速い。タイプして即発火。LLM が文脈を見て呼んでくれるのを待たなくていい。

私の判断: 「私が能動的に呼ぶ作業」はスラッシュコマンド、「LLMに気付いてほしい作業」は Skill。賛否あると思うが、両方触った私の結論はこれ。

私が常用している7個(コピペで動く)

.claude/commands/ に Markdown を置くだけ。ファイル名がコマンド名になる。

1. /pr-summary(変更点を3行で要約)

---
description: 直近のステージング差分を3行で要約してPR本文の冒頭に貼る形にする
---

git diff --staged を見て、以下のフォーマットで返してください。

- 1行目: 何を変えたか(動詞始まり、30字以内)
- 2行目: なぜ変えたか(背景、40字以内)
- 3行目: 影響範囲(対象ファイル/モジュール名)

絵文字や前置きは不要。3行だけ。

2. /pr-checklist(レビュー前チェックリスト生成)

---
description: 変更内容を見て、PR本文に貼る "確認済み" チェックリストを生成
---

差分を見て、PRに貼るチェックリストを Markdown のチェックボックス形式で出してください。観点は以下:

- ユニットテストを追加/更新したか
- ロールバック手順が明確か
- 環境変数や設定の変更が必要か
- 影響を受けるエンドポイント/画面
- ログ/メトリクスへの影響

該当ないものは含めず、関係ある項目だけ出す。

3. /explain-this(差分の意図を新人向けに3段落で書く)

---
description: 変更点を「初めてリポジトリを見る人」向けに3段落で説明する
---

git diff --staged の変更を、3段落で説明してください。

- 段落1: この変更の一言要約
- 段落2: なぜこの実装を選んだか(他の選択肢との対比含む)
- 段落3: 触るときの注意点

専門用語は避ける。新しくチームに来た人が読む前提。

残り4個は /release-note /risk /rollback /sql-review。形式は同じ。リポジトリにコミットしておけば、チーム全員に配布される。

ハマったところ(全部、私の失敗)

ここが本題。テンプレより詰まりポイントの方が役に立つ。

1. description を書き忘れて補完に出てこない: フロントマターは必須。書かないと一覧から消える。気付くまで30分溶かした。
2. git diff を渡す前提なのに、ステージングしてないファイルで実行: 「差分が空ですが」と返ってきて沈黙。/pr-summary の冒頭に「ステージングが空なら "git add してください" と言うだけ」を足した。
3. 長すぎる差分でコンテキストを食い切る: モノレポで 5,000 行差分を渡したら詰まった。git diff --stat で先に俯瞰してから本体を渡す形に変えた。
4. 「3行で」と言ったのに5行で返ってくる: 「3行のみ。前置き禁止」を強めに書く必要があった。やわらかく書くと負ける。
5. コマンドをグローバルに置きすぎて、リポジトリ固有の事情に合わない: プロジェクトごとに .claude/commands/ を分けた方がいい。これは早めに気付いた。
6. チームに配布するときに「これ何?」と言われる: README に「7個まとめて1分デモ」を gif で貼ったら、翌週には半数が使い始めた。配布より見せる方が大事。
7. /sql-review で本番DBの値を貼ってしまいそうになる: 守秘の話。テンプレ側に「貼る前にPII/本番値が混ざっていないか確認」と注意書きを埋めた。

7個全部、私が踏んだ落とし穴。同じ穴を踏まなくて済むなら、この記事の元は取れている。

真似できる「最小1個」テンプレ

時間がない人向けに、まずこれだけ作って明日試す形にした。

mkdir -p .claude/commands
cat > .claude/commands/pr-summary.md <<'EOF'
---
description: 差分を3行で要約してPR冒頭に貼る形で返す
---
git diff --staged を見て、以下で返してください。
- 1行目: 何を変えたか(動詞始まり、30字以内)
- 2行目: なぜ変えたか(40字以内)
- 3行目: 影響範囲
3行のみ。前置き禁止。
EOF

これを作って git add した状態で /pr-summary を叩く。それだけ。

まとめ

• PR準備みたいな「私が能動的に呼ぶ作業」はスラッシュコマンドが速い
• Skill とは住み分ける。賛否あるが、私はこの線引きで困っていない
• フロントマターの description は必須、サボると消える
• 長い差分は --stat で俯瞰してから渡す
• チーム配布は README より gif デモが効く
• まず1個、/pr-summary から作る。15分で組める

みなさんはスラッシュコマンドと Skill、どう住み分けていますか? 「これは Skill にした方が楽だった」みたいな経験談があればコメントで教えてください。

---

Claude Cowork を社内AXの相棒として毎日使っているエンジニアの実践ログです。
シリーズ: Claude Cowork で社内AXを回す
����������������