はじめに
Hello, GitHub Copilot ラバーなみなさん。これから GitHub Copilot ラバーになるみなさん。
もう最近の開発は AI を使用して実行しますよね。
弊社では GitHub Copilot Enterprise を導入していまして、よくエージェントモードと取っ組み合いをしています。
扱い方が慣れてきた頃にどんどん効率化を考えていきたくなりますよね。
その中でも、よく GitHub Copilot と比較される Claude Code にはあるカスタムスラッシュコマンドを GitHub Copilot でも使えないかと調査をしてみました。
この記事は VS Code & GitHub Copilot Chat の Prompt File（.prompt.md） を使って、よくやる作業を / で即呼び出せるようにする記事です。
それでは早速見ていきましょう！
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
2025/10 時点では Public Preview の状態なので、将来仕様が変わる可能性があります。
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Prompt File とは？
「チャットで毎回書いてる長めの指示」をファイルにして /コマンド化する仕組みです。
YAML と Markdown を組み合わせて記述し、1行でプロンプトを実行できるようになります。
Claude Code のカスタムスラッシュコマンドに近い体験を、VS Code & GitHub Copilot でも実現できるわけですね。
- チャットの定型プロンプトをファイル化したもの（拡張子
.prompt.md）。 - ファイル名＝/コマンド名。例:
review-changes.prompt.md→/review-changes。 - 置き場所:
<workspace>/.github/prompts/（プロジェクト共有） /$HOME/.copilot/prompts/（個人）。 - 先頭の Front‑matter（YAML） で
mode/model/tools/descriptionを指定し、下の本文が 実際に LLM へ送る指示。 modelは 表示名をクオート（例:'Gemini 2.5 Pro'）、toolsは 配列＋クオートで列挙するのが安全。
公式リファレンス:
先に結論：Prompt File でできること/できないこと
できる
/コマンド化（ファイル名がコマンド名になる）mode・model・toolsを固定し、実行権限を最小化できる- 本文に Markdown で 手順・チェック項目・出力フォーマット を書ける
できない/制限
temperatureなど細かい LLM パラメータは原則不可（挙動は本文で記述）- 未対応の Front‑matter キーを増やしても無視される
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
セットアップ（置き場所・命名・最小テンプレ）
- 置き場所
- リポジトリ限定:
<workspace>/.github/prompts/*.prompt.md - ユーザー全体:
$HOME/.copilot/prompts/*.prompt.md（または VS Code の Profile 配下）
- リポジトリ限定:
- コマンド名:
file-name.prompt.md→/file-name
最小テンプレ
---
mode: "agent"
model: "GPT-4o"
tools: ["read_file"]
description: "とりあえず動く最小サンプル"
---
# ゴール
この下は LLM へ渡る本文。やりたいこと・手順・出力形式を Markdown で書く。– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Prompt File の基本構造
Front‑matter の 4 キー
先頭の
---〜---が YAML Front‑matter。ここで実行モード・モデル・ツール権限を決めます。
キー 意味 よく書く値 コツ modeチャットの動作モード 'ask'/'edit'/'agent'コメントを同じ行に書くなら クオート推奨 model使う LLM を固定 'Gemini 2.5 Pro','GPT-4o'表示名をそのままクオート。未表示のモデル名は無視されることがある toolsAgent が使えるツール ID 配列 ['read_file', 'run_in_terminal']配列＋クオートが安全。省略すると既定セット（広め）が使われる description/補完に出る説明文'変更ファイルのコードレビュー'実行挙動には影響しない（UI 用メタ）
本文（プロンプト本文）
- ここが 実際に LLM に渡るプロンプト。
- 普通の Markdown。見出し、チェックリスト、表、コードブロックなんでも可。
- 書き方のコツは「ゴール → 手順 → 出力フォーマット」の順で明示。
よく使うツール ID 一覧
すべて クオートした文字列で列挙するのが無難。
VSCodeのチャットモードで「
list your tools」と質問すると現在使えるコマンドを教えてくれます。
ツール ID 何をするか 典型ユースケース 'read_file'ファイル本文を読む レビュー・要約 'insert_edit_into_file'パッチ適用（追記/置換） 修正案の提示、雛形生成 'run_in_terminal'ターミナル実行 git diff,npm test,pytest'grep_search'文字列/正規表現検索 TODO/FIXME 棚卸し 'get_changed_files'変更ファイル一覧を取得 差分レビュー起点 'get_last_commit_diff'直近コミット差分（プレビュー） 直前コミットの確認 'list_code_usages'シンボル参照箇所を列挙 呼び出し元調査 'get_errors'/'problems'Linter/型エラー収集 ESLint/TS の問題拾い
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
実践 1：変更ファイルのコードレビュー /review-changes
変更ファイルだけを対象に、ポリシー（
copilot-instructions.md）準拠でレビュー。差分ゼロ時の扱いも明記しておくと親切。
---
mode: "agent"
model: "Gemini 2.5 Pro"
tools:
[
"get_changed_files",
"read_file",
"semantic_search",
"run_in_terminal",
"insert_edit_into_file",
]
description: "変更ファイルのコードレビュー"
---
# ゴール
現在 Git に含まれる 変更ファイル を `copilot-instructions.md` の規約に沿ってレビューしてください。
- バグ/設計/セキュリティ/テスト/可読性を網羅
- 重大度を ❌Critical / ⚠️Major / 💡Minor で分類
- 必要に応じて 修正パッチ案 を提示（自動コミットはしない）
- 変更が 0 件なら「変更が見つかりませんでした」と報告して終了
## 手順
1. `get_changed_files` で対象取得
2. `read_file` / `semantic_search` で文脈を把握
3. 差分が必要なら `run_in_terminal: git diff --unified=0 <file>`
4. 問題があれば `insert_edit_into_file` でパッチ案を提示
5. 最後に Summary / File-by-file comments / Recommended next steps を Markdown で出力– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
実践 2：テスト自動生成 /generate-tests
---
mode: "agent"
model: "Gemini 2.5 Pro"
tools: ["get_changed_files", "read_file", "insert_edit_into_file", "run_in_terminal"]
description: "変更ファイルのテスト自動生成"
---
# ゴール
変更ファイルごとに 単体テスト or スナップショットテスト を生成してください。
- 既存プロジェクトのテストフレームワーク（Jest / PyTest / Go test など）に揃える
- 成功するまで `run_in_terminal` でテスト実行＆修正
## 手順
1. `get_changed_files` で差分一覧
2. `read_file` で公開 API と挙動を抽出
3. テスト戦略（正常/異常/境界）を決め、`insert_edit_into_file` で配置
4. `run_in_terminal` でテスト実行 → 緑になるまで修正
5. 生成ファイル一覧・カバレッジ・TODO をレポート– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
実践 3：TODO 棚卸し /todo-audit
---
mode: "agent"
model: "GPT-4o"
tools: ["grep_search", "read_file"]
description: "TODO / FIXME コメント棚卸し"
---
# ゴール
コードベースから `TODO:` / `FIXME:` / `XXX:` を抽出し、以下の表でレポートしてください。
| File | Line | Tag | Summary (≤20 words) | Suggested owner | Priority |
| ---- | ---- | --- | ------------------- | --------------- | -------- |
## 手順
1. `grep_search` で 3 キーワードを大文字小文字無視で検索
2. ヒット行の前後 5 行を `read_file` で取得し要約
3. `@username` が近くにあれば Owner、それ以外は `UNASSIGNED`
4. Priority は ❗High / ⚠️Medium / ➖Low
5. 改善提案を 3 点以上まとめる– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
変数の意味
${workspaceFolder}: ワークスペースの絶対パス${selection}: エディタの選択テキスト${input:branch:main}: 実行時に入力ダイアログ（mainをデフォルト値に）- ルールや仕様書（例：
copilot-instructions.md）への Markdown リンク を本文に入れると、モデルは内容を踏まえて応答してくれます。
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
運用コツ
toolsは必要なものだけ列挙（省略すると広い権限）- 自動コミットは避け、
insert_edit_into_fileでパッチ提案 → 人間が確認 - コマンド名・見出し・出力フォーマットをチーム内で統一
.github/prompts/にコミットしてチームで使い回し'Gemini 2.5 Pro'のように 表示名をそのまま 書く
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
まとめ
Prompt File は「定型タスクを /コマンド化」するシンプルな仕組みです。
Front‑matter に mode / model / tools / description を書き、本文で ゴール → 手順 → 出力を明示するだけで、レビューやテスト生成を“いつもの流れ”に載せられます。まずは 1 本、あなたの現場で一番よくやる作業をファイル化してみましょう！ウキウキが止まらんぜ！
まぁ、テンプレ書きましたが、YouはLLMに作成お願いしちゃいなよ！
それでは良きエンジニアライフを！！
