copilot-instructionsがより細かく制御可能になったので試す

概要

こちらの記事にある通り、copilot-instructions.mdのカスタムがより柔軟になったようで、パスごとに適用するカスタム命令ファイルを変更できるようになったみたいです。そのMDファイルの作り方、配置方法、できる範囲などをまとめてみました。

前提

今回はVSCode上でカスタム命令を扱う場合を想定しています。
こちらのページにある通り、残念ながらGithubコードレビュー上ではまだこの機能に対応していないみたいです。ここに関しては既存のcopilot-instructions.mdを引き続きご利用ください。

試すアプリケーション

めっちゃ適当なSpringBoot+Thymeleafのアプリケーションを作ってもらい、それをもとに試していく形とします。
全体はこちらのリポジトリにて

カスタム命令ファイルを作る

ディレクトリ構成

簡易的ですが以下のような構成です。
ポイントは.github/instructionsというディレクトリを作り、その中に*.instructions.mdという命名でファイルを作ることです。

root/
├── .github/instructions/           # カスタム命令ファイル用のディレクトリ
│   ├── backend.instructions.md     # バックエンド開発ガイド
│   └── frontend.instructions.md    # フロントエンド開発ガイド
├── src/main/
│   ├── java/.../
│   │   ├── controller/             # コントローラー層
│   │   ├── service/                # サービス層 
│   │   └── exception/              # 例外処理
│   └── resources/
│       └── templates/              # Thymeleafテンプレート
└── src/test/                       # テスト

カスタム命令ファイルの種類

今回は簡単にですが、バックエンドとフロントエンド用に分けてカスタム命令ファイルを作成しました。
バックエンド用のカスタム命令ファイルはこんな感じ。
こちらもポイントとしては、applyTo:というセクションで適用させたいディレクトリを明示すること。これでそのパスに対してだけ適用したいカスタム命令ファイルとして定義できるようになります。

backend.instructions.md

applyTo:
  - src/main/java/**
  - src/test/java/**
  - build.gradle
  - settings.gradle
---

# バックエンド開発用カスタム命令

## コーディング規約
- Javaのコーディング規約に従い、適切な命名規則を使用する
- Spring Bootのベストプラクティスに準拠する
- Lombokアノテーションを積極的に活用する（@Data, @NoArgsConstructor, @AllArgsConstructor等）
- Springアノテーションを適切に使用する（@Service, @Controller, @Repository等）

## アーキテクチャ
- MVC パターンを維持する（Controller - Service - Repository）
- DIを適切に使用し、@Autowiredよりもコンストラクタインジェクションを推奨
- RESTful APIの設計原則に従う
- 1コントローラー1エンドポイントを基本とする

## コード品質
- メソッドは単一責任の原則に従い、簡潔に保つ
- 適切な例外処理を実装する
- ログ出力を適切に配置する（SLF4Jを使用）

## テスト
- 単体テストの作成を推奨
- @SpringBootTestを使用した統合テストを適切に実装
- テストメソッド名は日本語でも可（テストの意図が明確になる場合）

## 依存関係
- 新しい依存関係を追加する際は、必要性を検討し、最小限に留める
- Spring Boot Starterを優先的に使用する

chatで試してみる

バックエンド部分でカスタム命令に従っていない部分がある状態で、ちょっとリファクタをお願いしてみます。

どうもちゃんとbackend.instructions.mdのほうを読み取り、それに伴ってリファクタを進めてくれているようです。カスタム命令に記述したうち、インジェクション方法/ログ出力/テストあたりなどちゃんと読んでリファクタリングしてくれていそうな感じでした。

感想

instructionsファイルを分けることによるメリットは、再利用が簡単になることだと思います。
別のプロジェクトでフロントエンドが別物でもバックエンドが同じならのbackend.instructions.md'ファイルは同じものを使えたり、公式にもありましたがセキュリティ用のsecurity.instructions.md`を作ってどのプロジェクトにも適用できるようにしたりなど...

このあたりの管理も含めて考えていき、コーディングエージェントを使う際の共通ルールとして周知していくのがよさそうですね。実際プロジェクトごとでばらばらに用意している状態なことも多そうなので、それを統一するための助けになるかも？と思いました。