github-copilot-custom-instructions

KO | EN

gitlite — search

#javascript #ai #llm #golang #android #rust #linux #macos #awesome #cli #awesome-list #security #ios #openai

github-copilot-custom-instructions

(★ 16)

GitHub Copilot 指示書

github-copilot-custom-instructions 최신버젼 다운로드

최종 버전 다운로드 (.zip)

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# 利用方法

VS Codeワークスペースを利用して
コードのリポジトリ
設定書のリポジトリ、またはフォルダ(_design/)
指示書のリポジトリ(このリポジトリ)
を用意して、コードのリポジトリは指示書のリポジトリを参照するように設定してください。

そして、実際に指示する前に、GitHub Copilotに
どの指示書のファイルを読み込んでいるか？
そして、ルールをどの用に認識しているか？
の確認をします。

# Webアプリと設計書とGitHub Copilotの指示書の各リポジトリを１つのように扱う

## 選択肢

条件:
WebアプリはGitのpublicで管理
設計書、GitHub Copilotの指示書はGitのprivateで管理

1. サブモジュール - 独立して開発される2つのプロジェクトを一緒に使用したい場合
2. サブツリー - リポジトリの履歴を統合したいが、別々のリポジトリも維持したい場合
3. モノレポ - 完全に統合された単一リポジトリが望ましい場合
4. ワークスペース - 開発時のみ統合された環境が必要な場合

この中から4を選びます。

# VS Codeワークスペースでの管理方法: それぞれ独立させ管理する

## VS Codeワークスペースの構成

my-project-a.code-workspace
├── code_repo_A/ (Webアプリのコード)
├── design (設計書) もしくは _design/
└── github-copilot-custom-instructions/ (指示書)

この構成では、
* 生成されたコードのリポジトリ
* 設計書のリポジトリ または フォルダ
* 指示書のリポジトリを
の3つで管理しています。

VS Codeのワークスペース機能を使用すると、これらの複数のリポジトリを1つのVS Codeウィンドウで効率的に管理できます。

## VS Codeのワークスペースの作成手順

1. VS Codeを起動します。
2. 「ファイル」メニューから「ワークスペースをフォルダーに追加...」を選択します。
3. 指示書リポジトリのフォルダーを選択し、「追加」をクリックします。
4. 必要に応じて、コードリポジトリのフォルダー（例：`code_repo_A`）を上記の手順で追加します。
5. 「ファイル」メニューから「ワークスペースを名前を付けて保存...」を選択し、ワークスペースファイルに名前を付けて保存します（例：`my-project-a.code-workspace`）。
6. ワークスペースファイル (`.code-workspace`) を開いて、プロジェクトを開きます。 VS Codeは、指示書リポジトリとコードリポジトリを1つのウィンドウに表示します。
7. GitHub Copilotに指示書を読んで、コードのリポジトリに生成するように指示します。

---

# Copilot の長所と短所

## Copilot が最適な場合

* テストと繰り返しコードの記述
* デバッグと構文の修正
* コードの説明とコメント
* 正規表現の生成

## Copilot が適してない場合

* コーディングとテクノロジに関係のないプロンプトに対応する
* 専門知識やスキルを更新する。 自分自身が責任者であって、Copilot はサービスの強力なツールであることを忘れないでください。

# Copilot コード補完と Copilot Chat の使い分け

## Copilot コード補完

* コード スニペット、変数名、および関数を記述する際の補完
* 繰り返しコードの生成
* 自然言語のインライン コメントからのコード生成
* テスト生成

## Copilot Chat

* コードに関する質問への自然言語での回答
* コードの大きなセクションを生成し、そのコードを反復処理してニーズを満たす
* キーワードとスキルを使用して特定のタスクを実行する。
Copilot Chat には、プロンプトの重要なコンテキストを提供し、一般的なタスクをすばやく実行するように設計されたキーワードとスキルが組み込まれています。
* 特定のペルソナとしてタスクを完了する。
たとえば、Copilot Chat に、コードの品質、読みやすさ、効率性について非常に気をつかう TypeScriptのシニア開発者として振舞うように伝え、コードをレビューするように依頼できます。

# 思慮深いプロンプトを作成する

Copilot が簡単に理解して対応できるように、指示書を構造化(Markdown形式)する。

* 複雑なタスクを分割する。
* 要件について具体化する。
* 入力データ、出力、実装などの例を提供する。
* 適切なコーディング プラクティスに従う。

# Copilot の機能をチェックする

* 実装する前に、提案されたコードを理解します。
* Copilot の提案を慎重にレビューします。
提案されたコードの機能とセキュリティだけでなく、あとでコードを読むときの、読みやすさと保守も考えます

# Copilot を役立つ出力に導く

関連ファイルを開いておく、(ドラッグアンドドロップで)登録しておく。
1タスク単位で会話をする。次のタスクに移る時は、新しく会話を始める。
提案に満足できない場合は、新しく指示書やプロンプトファイルを書き直す。
Copilotを最新の状態に保つ、拡張機能の更新を行う。
非常に大きなファイルや多数のファイルがコンテキストとして使用される場合、応答の品質が低下します。

# Tips

* 範囲選択 先頭の行番号をクリックして、Shiftキーを押したまま、最後の行の行番号をクリックします。

---

# Webアプリ開発での、指示書を利用する基本方針

## 4種類の指示書を使い分ける

* VSCodeへの設定
* GitHub Copilotの全体
* GitHub Copilotの個別
* プロンプトファイル(＝実装書)

設計書を作り、タスク分解をしてそれぞれタスクリストに登録。
タスクリストから1つタスクを取り出し、GitHub Copilotと相談してプロンプトファイル(＝実装書)を作り上げて、コードの生成をしてもらう。

## それぞれの指示書の役割

* GitHub Copilotに対する指示書
VSCodeに設定するのは、どんなときでも常に適用するルール
* copilot-instructions.md GitHub Copilotがプロジェクト単位で適用する全体のルール。
* .github/.copilot-*****-instructions.md GitHub Copilotの全体ルールに入らないその他、細かいルール
* .github/prompts/[日付]-[タスクid]-[タスク名]-[タスクの種類].prompt.md
プロンプトファイル(拡張子が.prompt.md)

---

# 指示書（プロンプト）とメタプロンプト

## 指示書（プロンプト）とは

GitHub Copilot（または他の大規模言語モデル）に対して、特定のタスクを実行させるための命令や質問です。

例：「特定の機能のコードを生成してください」「このコードを修正してください」など。

## メタプロンプトとは

指示書（プロンプト）自体を生成したり、指示書（プロンプト）の形式や内容を制御したりするためのプロンプトです。「AIにどのように指示すべきか」を指示するためのプロンプトと言えます。

例：「あなたは経験豊富なプログラマーです。与えられた仕様に基づいて、TypeScriptの関数を生成してください。指示書は箇条書きで記述し、具体的な例を含めてください。」

GitHub Copilotに渡すプロンプトを作成するために、メタプロンプトで詳細な指示を記述します。

## メタプロンプトの具体的な指示例

以下に、メタプロンプトに詳細な指示を記述する例をいくつか示します。

* 役割の定義
    * 「あなたは高度な問題解決能力を持つAIアシスタントです。以下の指示に従って、効率的かつ正確にタスクを遂行してください。」

* 出力形式の指定
    * 「生成するコードには、適切なコメントとドキュメンテーションを含めてください。関数やクラスには、その目的と使い方を説明するdocstringを記述してください。」
    * 「コードはコーディング規約に従ってください。」

* 制約条件の指定
    * 「生成するコードは、指定されたライブラリのみを使用してください。外部ライブラリを使用する場合は、事前に承認を得てください。」
    * 「コードの実行速度は、〇〇ミリ秒以内に収まるようにしてください。」

* テストコードの生成
    * 「生成するコードには、単体テストコードを自動的に生成してください。テストコードは、Jestフレームワークを使用してください。」

* `.github/copilot-instructions.md` の活用
    * プロジェクト全体で適用させたいルールは、こちらに記述します。
    * 「このリポジトリで生成されるコードは、常に〇〇のコーディング標準に従ってください。」
    * 「セキュリティ上の脆弱性を避けるため、〇〇のライブラリの使用は避けてください。」

## プロンプトファイルの活用

* 目的や機能ごとにプロンプトファイルを作成し、GitHub Copilotに読み込ませることで、より柔軟なコーディングが可能になります。

メタプロンプトに詳細な指示を記述することで、GitHub Copilotの能力を最大限に引き出し、より効率的かつ高品質なコーディングを実現できます。

# プロンプトファイル

## プロンプトファイルとは

プロンプトファイルは、実装書と同義であり、具体的な実装内容を記述するファイルです。

* `.github/prompts/` ディレクトリ内に、拡張子 `***.prompt.md` のファイルを作成します。
* 実装時には、設計書をタスク分解した全タスクをタスクリストに登録します。そのタスクリストからタスクを一つ取り出し、プロンプトファイルを作成します。
* プロンプトファイルを使用して、GitHub Copilotに具体的な実装方法を指示します。詳細な部分まで記述します。

## プロンプトファイルの記述例

プロンプトファイルには、以下の内容を記述します。

* 必要な指示書
* 実現したい機能や目的
* 使用するツール、プログラミング言語、フレームワーク、ライブラリ
* 参考コード、参考資料
* 入力、出力、処理内容、表示内容
* エラー処理や例外処理に関する要件
* パフォーマンスやセキュリティに関する要件

## プロンプトファイル作成例

以下は、ユーザー認証機能のプロンプトファイル作成例です。

```auth.prompt.md
#   機能：ユーザー認証機能

##  説明

ユーザー名とパスワードを使用してユーザー認証を行う機能を作成してください。

##  要件

* ユーザー名とパスワードはデータベースに保存されていること。
* 認証に成功した場合、ユーザーIDを返すこと。
* 認証に失敗した場合、エラーメッセージを表示すること。

##  コード構造

* ユーザー認証を行う`authenticateUser`関数を作成してください。
* データベースへのアクセスは`Database`クラスを使用してください。

##  テスト

* 正しいユーザー名とパスワードで認証できること。
* 誤ったユーザー名またはパスワードで認証できないこと。

##  コーディング規約

* 関数名、変数名はわかりやすく命名すること。
* エラー処理を適切に行うこと。

```

# プロンプトファイル作成後の流れ

1.  プロンプトファイルの充実度が十分になったら、そのファイルを使用してコードを生成します。
2.  生成されたコードをテストします。
3.  GitHub Copilotによるレビューを行います。
4.  レビュー方針に従って、必要に応じてコードを微調整します。
5.  GitHubにコミットする際に、Biomeなどのツールでソースコードを整形します。
6.  GitHubにpushする前に、ビルドの動作確認を行います。
7.  GitHubにpushし、サーバーにデプロイします。

---

# レビュー方針

コードレビューでは、以下の点に注目します。

#### 基本的なコード品質

* 可読性
* 保守性
* 効率性

#### 技術的負債

* 将来的な問題の可能性
* 命名の不統一
* 非推奨の機能やライブラリの使用
* 未解決の課題やTODOコメント

#### セキュリティ

* 入力の検証
* エラーハンドリング
* 権限管理

#### テスト

* テストの網羅性
* テストの品質
* テスト容易性
* テストされていない箇所

#### その他

* 設計の妥当性
* 規約との適合
* 依存関係

---

# 確認、チェック、範囲

指示書を効果的に管理するために、以下の点に留意してください。

## 確認

### 指示書ファイルの存在確認

GitHub Copilotがどの指示書を読み込むように設定されているかを確認します。`.github/copilot-instructions.md`ファイルや、VSCodeの設定（settings.json）内の関連設定を確認し、有効になっている指示書をリストアップします。

例：「現在、`.github/copilot-instructions.md`に記述された指示書と、VSCodeのワークスペース設定で指定された指示書が有効になっています。」

## チェック

### 重複チェック

指示書内で同じ指示が重複していないかを確認します。重複している指示がある場合は、一方を削除するか、より具体的な指示に統合します。

### 無効チェック

指示書内に古い情報や、現在のプロジェクトの状況に合わなくなった指示がないかを確認します。無効な指示は削除するか、最新の情報に更新します。

## 範囲

指示書が長くなりすぎないように、範囲を適切に設定します。

* 指示書が肥大化している場合は、以下の点を考慮して分割を検討します。
    * 機能やモジュールごとに分割する
    * や担当者ごとに分割する
    * 指示の種類（コーディング規約、テスト方針など）ごとに分割する
* 分割した指示書をどのように参照させるかを明確にします（例：プロンプトファイルで必要な指示書を明示的に指定する）。
* 指示書の適切な長さの目安としては、200〜300語程度が考えられます。ただし、指示の内容や複雑さによって変動するため、一概には言えません。

# コーディングルール

プロジェクト全体で一貫したスタイルを維持するために、コーディングルールを適用します。

* VSCodeの`settings.json`に記述するコーディングルールは、プロジェクト全体で一貫したスタイルを維持するために重要です。
* `settings.json`の調整が難しい場合は、以下の方法も検討できます。
    * EditorConfigファイル（`.editorconfig`）を使用する：多くのエディタでサポートされており、プロジェクト固有のコーディングスタイルを定義できます。
    * コードフォーマッター（Prettierなど）を導入する：コードを自動的に整形し、スタイルの一貫性を保ちます。
    * Linter（ESLintなど）を導入する：コードの問題点を検出するだけでなく、スタイル違反も検出できます。
* 指示書に記述するコーディングルールは、毎回AIに調整を依頼します。VSCodeの`settings.json`に記述する指示の調整は難しいため、他の指示書で微調整を行います。

# repomix

repomixは、現在のリポジトリのファイルを1つのテキストファイルに変換するツールです。GitHub Copilotやその他のLLMにリポジトリ全体の文脈を把握させ、より適切な提案や修正を得るために使用します。

例えば、コード実装後に毎回実行して、コードレビューを依頼する、といった使い方が可能です。

リポジトリの直下で`npx repomix`を実行すると、`repomix-output.txt`というファイルが生成されます。repomixの更新は、自動化または手動で行います。

* 自動化する場合、Gitのフック（pre-commitなど）を設定することで、コミット前に自動的に`repomix`が実行されるようにできます。
* 手動で更新する場合、機能実装やリファクタリングが完了し、コードレビューを依頼する前などに`repomix`を実行し、最新の`repomix-output.txt`を生成することを推奨します。

## AIへの指示の具体例

`repomix-output.txt`を読み込ませた上で、以下のような指示をAIに与えます。

* 「このコードの可読性を向上させるための提案をしてください。特に変数名や関数名で改善点があれば教えてください。」
* 「このコードには技術的負債となりうる箇所はありますか？もしあれば、具体的な場所と理由を教えてください。」
* 「セキュリティ上の懸念点があれば指摘してください。特に外部からの入力処理について注意深く見てください。」
* 「このコードに対して、どのようなテストを追加すべきでしょうか？テストケースのアイデアをいくつか提案してください。」
* 「このコードの設計について、改善点やより良いアプローチがあれば教えてください。」
* 「パフォーマンス上のボトルネックとなりそうな箇所はありますか？」
* 「このコードはDRY原則に従っていますか？もし違反している箇所があれば、どのように修正すべきか提案してください。」

# メモリーバンク

メモリーバンクを使用する場合、Clineの利用を推奨します。GitHub Copilot Agent modeには、Clineのような自動承認モードがないため、メモリーバンクのような機能を使用する場合も、ファイルの読み書き、安全なコマンドの実行、ブラウザの使用、MCPサーバーの使用などの許可を、ユーザー自身が指示し承認する必要があります。

このリポジトリで提供するGitHub Copilot用のメモリーバンクは、自然言語による指示を通じて、ソフトウェア的に関連するファイルを考慮するように設計されています。

便利さを取るか、安全を取るかの判断となります。

* メモリーバンクの利用は、プロジェクトのコンテキストを維持し、一貫したコード生成を行う上で役立ちます。
* GitHub Copilot Agent modeでは、ユーザー自身がファイルの読み書きなどを承認する必要があるため、セキュリティに配慮した運用が求められます。
* Clineのような自動承認モードを持つツールと比較して、利便性と安全性のバランスを考慮する必要があります。
* このリポジトリで提供するメモリーバンクの設計について、もう少し詳細な説明があると、ユーザーがどのように活用できるかのイメージが湧きやすくなるかもしれません。
    * 例：メモリーバンクに保存する情報の種類（ファイルの場所、APIエンドポイント、データモデルなど）や、情報の更新方法、参照方法など。

# GitHub Copilot Agent mode、Cline、Cursor、Windsurf

中規模・大規模プロジェクトでは、GitHub Copilot Agent modeは関連性の低いファイルまで考慮してしまうのに対し、Clineは物理的に関連するソースコードのみを読み込むように設計されています。

また、ClineはAST（抽象構文木）を使用することで、コードの文法的な構造を容易に理解し、プログラムで処理できます。

さらに、Clineは必要最小限の情報のみを逐次取得するアーキテクチャを採用しています。

これらのツールの間には、プロジェクトの規模が大きくなるほど顕著な差が現れます。

repomix、uithubなどのツールを使用すると、利便性が向上します。

AIエディタであるCursorやWindsurfは、継続的にコード全体を認識し、インデックス化します。

## 各ツールの違い

AIが読み込む情報に対して、各ツールは以下のような違いがあります。

* ソースコード全体をインデックス化しているツール：Cursor、Windsurf
* 必要なソースコードをASTで解析するツール：Cline
* ソースコード全体に自然言語で指示するツール：GitHub Copilot Agent mode

いずれのツールを使用する場合でも、現在のAIの能力では、詳細な設計を行い、タスクを小さな単位に分割し、それらをAIに読み込ませて、コンポーネント単位でコードを作成していくのが最適解です。

* このセクションでは、GitHub Copilot Agent mode、Cline、Cursor、Windsurfという4つのツールを比較し、それぞれの特徴と使い分けについて説明しています。
* 中〜大規模プロジェクトにおける各ツールの強みと弱みを明確にすることで、読者が自身のプロジェクトに最適なツールを選択できるよう支援しています。
* 「詳細な設計を行い、タスクを小さな単位に分割し、それらをAIに読み込ませて、コンポーネント単位でコードを作成していくのが最適解です。」という結論は、AIを活用した効率的な開発プロセスを示唆しており、読者にとって有益な情報です。
* 各ツールの説明において、具体的なコード例やスクリーンショットなどを交えると、より理解しやすくなるかもしれません。

# 用語集

* AST（抽象構文木）：コードの文法的な構造を木構造で表現したもの。プログラムがコードを理解し、処理するために使用されます。
* 計画的かつ反復的な開発プロセス：事前に計画を立て、小さなサイクルを繰り返しながら開発を進めるアプローチ。アジャイル開発などが該当します。
* 設計書：Webアプリケーションの全体像や各機能の詳細を記述したドキュメント。要件定義、画面設計、データベース設計などが含まれます。
* タスク分解：設計書に基づいて、開発に必要な作業をより小さな単位に分割すること。
* タスクリストファイル (task-list.md)：分解されたタスクの一覧を記録したファイル。各タスクの進捗状況などを管理します。
* 全体の指示書 (copilot-instructions.md)：プロジェクト全体に共通するルール、技術スタック、アーキテクチャなどを定義するファイル。
* 個別の指示書：特定の作業フェーズ（コード生成、コミットメッセージ、レビュー、テストなど）に関する詳細なルールを定めるファイル。
* プロンプトファイル：1つのタスク（1機能）の実装に関する具体的な詳細情報を記述したファイル。
* メモリーバンク：GitHub Copilotがセッション間でプロジェクトのコンテキストを維持するための仕組み。複数のマークダウンファイルでプロジェクト情報を記録し、AIが参照できるようにします。
* 技術スタック：プロジェクトで使用する技術の組み合わせ（プログラミング言語、フレームワーク、ライブラリなど）。
* コーディング規約：プロジェクト全体で一貫したコード品質を保つためのルール（命名規則、コメントの書き方、推奨されるプログラミングパターンなど）。
* コロケーション: 関連するファイルを近くに配置する開発手法。ここでは、コンポーネントのテストコードを同じフォルダに配置することを指します。
* ユニットテスト：個々のコンポーネントや関数が意図した通りに動作するかを検証するテスト。
* 統合テスト：複数のコンポーネントやシステムが連携して正しく動作するかを検証するテスト。
* 技術的負債：将来的に追加の作業が必要になる、現在の不完全な設計や実装。コードの重複、複雑すぎるコードなどが該当します。
* コードレビュー：他の開発者が作成したコードをチェックし、品質や潜在的な問題を評価するプロセス。
* MCP (Model Context Protocol)：GitHub Copilot Agent modeで外部サービスと連携するための設定プロトコル。
* GitHub Copilot Agent mode：GitHub Copilotの機能の一つで、外部ツールやサービスと連携してより高度な支援を行うモード。

# 参考資料

* Cline / Roo-Codeにおけるコード理解と新規・保守タスクの現状 [https//zenn.dev/tesla/articles/33d196d17bf3bb](https//zenn.dev/tesla/articles/33d196d17bf3bb)

github-copilot-custom-instructions

github-copilot-custom-instructions 최신버젼 다운로드

오늘의 추천 프로젝트

Was this content helpful?

Recent Feedback

github-copilot-custom-instructions

github-copilot-custom-instructions 최신버젼 다운로드

오늘의 추천 프로젝트

Was this content helpful?

Recent Feedback

Download README