カスタムスラッシュコマンドを 5 個作る

コース構成

このコースで学ぶこと

1. 01

   Slash command と Skill の違い

   両方 `/<name>` で呼べる。Skill は『Claude が読んで判断して実行する手順書』、コマンドは『固定の引数で起動する近道』。

   `.claude/commands/<name>.md` に書くのが純コマンド、`.claude/skills/<name>/SKILL.md` に書くのが Skill。

   純コマンドは固定の引数（`$ARGUMENTS`）を取り、テンプレを展開して実行するだけ。Skill は description マッチで自動発動もする。

   結論：シンプルな『プロンプトの近道』はコマンド、判断や手順を持つものは Skill。

   • 🟦 Slash command — 固定テンプレ展開のショートカット
   • 🟩 Skill — 自動発動・判断・手順を含む拡張
   • 両方とも `/<name>` で起動

   理解度チェック

   1. Q1.Skill と Slash command の本質的な違いは？

      ASkill は固定の引数を取るだけ、Slash command は自動発動するBSkill は description マッチで自動発動・判断を含む、Slash command は固定テンプレ展開のショートカットC両者は完全に同じDSlash command は Claude Code でしか使えず、Skill は SDK でしか使えない
   Pattern 1：/morning-standup
2. 02

   Pattern 1：/morning-standup

   毎朝の standup を Claude が書いてくれるコマンド。git log と Slack の自分の投稿を読んで整形。

   markdown

   ---
   name: morning-standup
   description: |
     昨日の自分の commit と Slack 投稿から standup を起こす
   ---
   
   以下を実行して、本日の standup（昨日やった・今日やる・ブロッカー）を生成してください:
   
   1. `git log --author='$USER' --since='1 day ago' --oneline` で昨日の commit
   2. ~/.claude/notes/yesterday-blockers.md があれば読む
   3. 形式:
      ```
      ## Yesterday
      - ...
      ## Today
      - ...
      ## Blockers
      - ...
      ```

   理解度チェック

   1. Q1.毎朝の standup を `/morning-standup` で自動生成するコマンドにすると得られる主な効果は？

      ASlack の有料プランに自動アップグレードされるBClaude が出社時間を管理してくれるC「昨日 / 今日 / ブロッカー」の形式が毎日揃い、しかも作成時間が数分→数十秒に縮むDgit log が見やすくなる
   Slash command と Skill の違いPattern 2：/explain-this
3. 03

   Pattern 2：/explain-this

   現在開いているコード or 渡したファイルを丁寧に解説する。新人オンボーディングや読書会用。

   markdown

   ---
   name: explain-this
   description: 渡されたファイルを 3 段階の深さで解説する
   ---
   
   対象: $ARGUMENTS
   
   ## 出力
   ### 1. 一行サマリー
   このファイルは何をするものか（70 字以内）
   
   ### 2. 3 つのポイント
   初見の人が押さえるべきポイント 3 つ
   
   ### 3. コード散歩
   上から下に流れを追って、各ブロックを 2-3 行ずつコメント。

   理解度チェック

   1. Q1.Slash command の `$ARGUMENTS` は何を意味する？

      A起動時に Claude が考えた“今日の引数”Bコマンド呼出時にユーザーが渡した引数文字列の placeholderCAnthropic 側で予約されているシステム変数D.env から読まれる秘密情報
   Pattern 1：/morning-standupPattern 3：/blame-fix
4. 04

   Pattern 3：/blame-fix

   壊れたテスト・エラーログを渡すと、git blame で犯人を特定 → 修正案を提示。

   markdown

   ---
   name: blame-fix
   description: テスト失敗 or エラーログから原因と修正案を出す
   ---
   
   エラー内容: $ARGUMENTS
   
   ## 手順
   1. エラーから関連ファイルとライン番号を抽出
   2. git blame でそのラインを最後に変更した commit を取得
   3. その commit の diff を読む
   4. エラーとの因果を仮説立て
   5. 修正案を 2 つ提示（最小修正版 / 根本対応版）

   理解度チェック

   1. Q1.`/blame-fix` が修正案を「最小修正 / 根本対応」の 2 つで返すように設計する意図は？

      AClaude が常に 2 案出すよう Anthropic 側で定義されているためB緊急性と恒久対応のトレードオフをユーザーが選びやすくするためCコマンドの行数を稼ぐためDテストが 2 倍走るため
   Pattern 2：/explain-thisPattern 4：/changelog-entry
5. 05

   Pattern 4：/changelog-entry

   今いるブランチの変更を、ユーザー向け changelog の 1 行に整形する。リリース時の定型。

   markdown

   ---
   name: changelog-entry
   description: 現ブランチの変更を CHANGELOG の 1 エントリに
   ---
   
   ## 手順
   1. `git diff main...HEAD --stat` で変更概要
   2. `git log main..HEAD --oneline` で commit リスト
   3. ユーザー目線で 1〜3 行の changelog エントリを起草
   4. カテゴリ判定: Added / Changed / Fixed / Removed
   
   ## フォーマット
   ```
   ### <Category>
   - <ユーザー目線の説明> (#<PR番号>)
   ```

   理解度チェック

   1. Q1.Changelog の本文を“ユーザー目線で書け”と指示する理由は？

      AClaude が技術用語を理解できないためB実装詳細ではなく、利用者にとってのメリット・変化を伝える方が CHANGELOG の役割に合うCGitHub の API 制限を回避するためDリリースノートの行数を増やすため
   Pattern 3：/blame-fixPattern 5：/refactor-suggest
6. 06

   Pattern 5：/refactor-suggest

   ファイルを渡すと『リファクタ案 3 つ』を比較表で出す。Plan 寄りの読み取り専用コマンド。

   markdown

   ---
   name: refactor-suggest
   description: ファイルを読みリファクタ案を比較する（編集はしない）
   ---
   
   対象: $ARGUMENTS
   
   このファイルを Plan モード相当で読み、リファクタ案を 3 つ:
   
   各案について比較表で:
   | 観点 | 案 A | 案 B | 案 C |
   |---|---|---|---|
   | 変更範囲 | | | |
   | テスト追加コスト | | | |
   | リスク | | | |
   | 推奨度 | | | |

   理解度チェック

   1. Q1.`/refactor-suggest` を“読み取りだけ・編集なし”と明示する設計の狙いは？

      Aリファクタ案を比較検討する段階で勝手に編集されないようにするBRead tool を高速化するCClaude が眠くならないようにするDBash 系コマンドを完全に禁止する
   Pattern 4：/changelog-entry配布と Skill への昇格判断
7. 07

   配布と Skill への昇格判断

   コマンドを書いたら git で共有。複雑になったら Skill に昇格させる。

   • `.claude/commands/` を git にコミット → チーム全員に展開
   • 個人用は `~/.claude/commands/` 配下
   • 「judgment が必要 / 自動発動させたい / tools を絞りたい」が出てきたら Skill に書き直す

   手を動かす

   0 / 3

   • 上の 5 パターンから 2 つ自分用に作る
   • 1 週間使って、毎日叩くものを特定
   • 毎日叩いているコマンドが 3 個になったら、それらの設計を Skill に昇格させる

   Lv.6 — 拡張機能

   理解度チェック

   1. Q1.自作 slash command を Skill に昇格させるべきタイミングは？

      Aコマンドが 1 行で済むくらい簡単になったときB他人にも共有したいだけのとき（git に置けば済む）Cjudgment が必要 / 自動発動させたい / 使うツールを絞りたい、のいずれかが出てきたときDコマンド数が 10 を超えたとき
   Pattern 5：/refactor-suggest