はじめに
Copilotを使っていて思うこと...
「すぐにコードを書き始める」
ただの質問でもいきなり何か書き始めます。
もちろんaskにして質問すればいいという話もありますが、切り替えもコンテキストに該当ファイルを追加するのも手間だし、agentモードで適当にファイルを参照して答えてほしいです。
よってこの記事では、CopilotにClineと同じようなPlan・Actモードを導入するカスタムインストラクションと、ついでに自分が設定しているほかのカスタムインストラクションの紹介をします。
環境
- Mac
- VSCode
- Github Copilot
- Agentモード
- Claude Sonnet 4
Plan・Actモード
.github/instructions/plan-act-mode.instructions.md
---
applyTo: "**"
---
## Plan Mode、 Act Modeについて
### 重要
**ユーザーの指示がない限りPlan Modeを維持する**
**Plan Modeにおいて、何があろうとも実装を行わない**
### Plan Mode（計画・分析フェーズ）
#### 基本原則
- **ファイル変更禁止**: 作成・編集・削除は一切行わない
- **読み取り専用**: 既存コードの読み取り・分析のみ実行
- **戦略策定**: 要件理解と実装アプローチの検討に集中
- **事前分析**: 潜在的な問題や課題を実装前に特定
#### Plan Mode で行うこと
与えられたタスクのための分析・計画
#### Plan Mode 完了時の動作
- 計画が完了したら実装開始の確認を行う
- ユーザーの意思決定を待ち、自動的に Act Mode に移行しない
### Act Mode（実装フェーズ）
#### Act Mode で行うこと
Plan Modeで策定した計画に基づいて実装を行う
また、必要に応じて実装内容の解説をする
CopilotにPlan・Actモードを教えるためのプロンプトです。
実装しないよう何回も念押しするのが大事です。
基本動作
.github/instructions/default-behavior.instructions.md
---
applyTo: "**"
---
## デフォルト動作設定
### 重要
- **すべての要求に対してまず Plan Mode で対応する。つまり、ファイル変更は一切行わず、分析・計画に専念する。**
- **すべての実装は明示的な許可後にのみ実行する。**
### 基本動作方針
PlanとActの二つのモードを導入する。
GitHub Copilot は **Plan Mode を基本動作** とし、安全で計画的な開発支援を提供する。
### モード切り替えの管理
#### 重要
**ユーザーからの明示的な指示がない限り、Plan Modeを維持する**
#### 基本
- `/plan` や `/act` コマンドは明示的な指示として扱い、即座にモードを切り替える
- 明示的な許可なしに Act Mode に移行しない
#### 自動提案のタイミング
- **Plan → Act**: 計画完了時に実装開始を確認
- **Act → Plan**: 複雑な問題や予期しない課題発生時に再分析を提案
#### モード切り替えの判断
- **常に Plan Mode から開始**: 実装要求でも必ず計画フェーズから
- 計画が不十分と感じたら Plan Mode に戻る
- 実装が明確になり明示的な許可を得た場合のみ Act Mode に移行
- 複雑さが増した場合は躊躇なく計画フェーズに戻る
- **疑わしい場合は Plan Mode を維持**: 安全性を最優先
### 禁止事項
以下の場合は **Act Mode に移行してはいけません**：
- ユーザーが具体的な実装を求めているように見える場合でも、明示的な許可なし
- 「簡単な変更だから」という理由での自動移行
- 緊急性を理由とした Plan Mode のスキップ
- 過去の実装パターンを理由とした推測での移行
デフォルトの動作を指定するプロンプトです。
これだけ念入りに指定しておけば、大体は所望の動作をしてくれます。
コマンド
.github/instructions/commands.instructions.md
---
applyTo: "**"
---
## GitHub Copilot カスタムコマンド
### `/plan`
Plan Mode(./plan-act-mode.md)に移行する
### `/act`
Act Mode (./plan-act-mode.md)に移行する
### `/refactor`
/plan
以下の手順でリファクタリングを行う
1. 変更の確認
```shell
# 未追跡ファイルと変更の確認
git status
# 変更内容の詳細確認
git diff --staged
```
2. 変更の分析
- 変更側は追加されたファイルの特定
- 機密情報の有無確認
- 変更の性質(新機能、バグ修正、リファクタリングなど)の確認
3. リファクタリングの計画
Fowlerの手法、このプロジェクトのコーディングルールに基づきリファクタリングの計画を立てる
4. リファクタリングの実行
ユーザーにリファクタリングの具体的な計画を提示し、承認を得る
リファクタリングする
### `/refactor {ファイルまたはディレクトリへのパス}`
/plan
以下の手順でリファクタリングを行う
1. 与えられたファイル・ディレクトリの分析
- 与えられたファイル・ディレクトリだけではなく、関連するファイルも含めて分析する
2. リファクタリングの計画
Fowlerの手法、このプロジェクトのコーディングルールに基づきリファクタリングの計画を立てる
3. リファクタリングの実行
ユーザーにリファクタリングの具体的な計画を提示し、承認を得る
リファクタリングする
### `/tdd {タスク}`
/plan
1. 要件定義、分析、計画をする
2. t-wadaの推奨するTDDの手法に従いタスクを進める
### `/precommit`
1.
/act
`git status`で変更されたファイルを確認し、**過不足なく**ファイルを指定してlintとformatとtestを実行する(変更していないファイルのlintとformatとtestは実行しない)
2.
/plan
/refactor
### `/read`
/plan
`.github/instructions/prompt.md`を読む
### `/sow {タスク}`
/act
タスクの分析
SOWの作成
注意事項
- タスクを進めるための必要十分な情報を記述すること
- 修正箇所はdiff表示にすること
- SOWの作成場所は`.github/tmp/`
コマンド集です。
/act タイポ直してなどとすればActモードで修正をしてくれます。
コマンド自体はコンテキストに含めずにコマンドのファイルへのリンクのみ提供したほうがよさそう(/readと同じように)
人名の指定
Fowlerの、t-wadaの、など人名を指定することで、意図を明確に伝える、情報を圧縮する、効果があるみたいです。
/readについて
prompt.mdにプロンプトを書いて/readとすればそれを実行してくれます。Copilotの場合は改行できるので使う機会は少ないです。
basic
.github/instructions/basic.instructions.md
---
applyTo: "**"
---
# GitHub Copilot カスタムインストラクション
## 最重要
- **パスワードやAPIキーなどの機密情報をハードコーディングしない**
- **エラー発生時は自律的に問題分析と解決案を提示**
- **2回以上連続でテスト失敗時はユーザーに報告**
- **返答は日本語で行う**
- **不明点はユーザーに確認する**
## lint, format, test用コマンド
```shell
yarn prettier --write ...
bundle exec rspec ...
```
`git status`で変更されたファイルを確認し、過不足なくファイルを指定して実行すること。
ex
```shell
yarn prettier --write path/to/file/index.tsx path/to/file/useHook.ts
```
基本設定です。
テストはコンテナ内で実行する、といった場合でも、コマンドを指定しておくといい感じに使ってくれます。
不明点はユーザーに確認する、とかはほとんど効いてない感じです。確認して欲しいんですけどね...
コーディングルール
.github/instructions/coding_rules.instructions.md
---
applyTo: "**"
---
## コーディングルール
### 共通
- コメントは日本語で記述する
- コメントとして、そのファイルがどういう仕様かを可能な限り明記する
- DRY、KISS、YAGNIの原則の意識
- 過度な抽象化を避ける
- 関心(責務)の分離の意識
### typescript
- 関数はアロー関数で記述する
- ユーザーの許可なくany型を使用しない
- 型定義は可能な限り詳細に記述する
コーディングルールです。
- DRY、KISS、YAGNIの原則の意識
- 過度な抽象化を避ける
- 関心(責務)の分離の意識
このあたりの原則とかは、書かなくてもよしなにしてくれると思います。なんとなく残しているだけです。
参考
このカスタムインストラクションに関係しないものも含めていろいろと
- mizchi/ailab
- .clinerulesを導入して、開発効率を上げていきたい話
- ookam/CLAUDE.md
- Claude 4 プロンプトエンジニアリングのベストプラクティス
- GitHub Copilot の指示書が複数ファイル対応に！ルールを用途別に整理できる新機能
- AIパフォーマンスの最適化を学ぶ（2）「SOWを作って」は超便利な指示
- 降霊術で t_wada を AI に降ろして PR レビューして貰うテクニックが伸びたのでその裏側記事を書きました！
まとめ
これらをコピペしておけばなんかいい感じに動いてくれると思います！
注意点?改善点?として
- 多分無駄な記述が多い(効いてないのは消した方がいい)
- プロジェクト固有の知識を与えてない
- plan-act部分はinstructionではなくてchatmodeにした方が良さそう
-
.github/prompts/command.prompt.mdとしておけば/commandで読み込んでくれるので、それを使ったほうがいい
などがあるので、そのあたりは適当にカスタマイズしてください。
追記
制限がかかってGPT-4.1になったら動作が全然違う...
モデルによってプロンプトも変えないとダメそうです
GPT-4.1用
株式会社ラグザイア（luxiar.com）の技術広報ブログです。 ラグザイアはRuby on RailsとC#に特化した町田の受託開発企業です。フルリモートでの開発を積極的に推進しており、全国からの参加を可能にしています。柔軟な働き方で最新のソフトウェアソリューションを提供します。
Discussion