GitHub Copilot におけるコンテキストエンジニアリング入門

Last updated at 2026-02-24Posted at 2026-02-24

はじめに

コンテキストエンジニアリングという言葉が出てくるぐらい¹、AI Agent を用いたコーディングが盛んになり、そのAgent に対して、どのようにして知識や手順(=コンテキスト)を与えてあげるのかが非常に重要になってきました。今回は、GitHub Copilot において、どのような形でコンテキストが定義されていて、どうやって利用するのかまとめたいと思います。

本記事は、GitHub Copilot を業務で使い始めた方、またはこれから導入しようとしている開発者を対象としています。

そもそもコンテキスト is 何？

コーディングエージェントという視点で考えると、コンテキストとは、コーディングエージェントがLLMとやり取りをして、コード提案、分析等のタスクを実施するために必要な「すべての情報」のことです。あなたがチャットに入力した質問はもちろん、開いているファイルの内容、プロジェクトの設定ファイル、これまでの会話履歴、さらにはエージェントがツールを使って取得した検索結果まで、すべてがコンテキストに含まれます。

つまり、コンテキストとは「コーディングエージェントが今この瞬間に見えている世界そのもの」であり、あなたのプロジェクトの全体像を正しく伝えるための手段だと考えてください。具体的にどのような情報がどの順序で渡されるかは、後述の「コンテキストスタック」で詳しく説明します。

コンテキストはなぜ重要なの？

あなたが与えるコンテキストの質に、コーディングエージェントの出力の質が左右されるからです。ここでいう質は内容が十分備わっているということだけではなく、内容が簡潔に記載されている必要があります。というのも現代のLLMの特性として巨大なコンテキストだと中間の指示内容を欠落して作業をしてしまうという特性(Lost-in-the-middle)²があるからです。

具体的に言えば、コンテキストの質は以下の3つの軸で評価できます。

十分性: タスクを遂行するために必要な情報が揃っているか。例えば、型定義がないままコードを生成させると、推測に頼った不正確なコードが出力されます。
簡潔性: 不要な情報でコンテキストが膨れていないか。関係のないファイルを大量に開いていたり、冗長な指示を書いていたりすると、肝心の情報がノイズに埋もれてしまいます。
構造性: 情報が整理されて渡されているか。箇条書きやセクション分けで構造化された指示は、自然文の羅列よりもLLMに正確に伝わります。

つまり、「必要な情報を、過不足なく、整理された形で渡す」ことがコンテキストエンジニアリングの核心です。コーディングエージェントは与えられた情報の中でしか判断ができないため、良質なコンテキストを設計することは、良質な出力を得るための最も確実な手段になります。

コンテキストウィンドウとコンテキストスタック

まず、コンテキストウィンドウサイズと呼ばれる、一度に取り扱えるコンテキストの最大量がコーディングエージェント並びにLLMに対して設定されています。一般的にコンテキストウィンドウサイズはLLM > コーディングエージェントとなっており、コーディングエージェントが作業を行うのに適切なサイズで設定されています。これを超えたコンテキストが与えられた場合、多くのコーディングエージェントはコンテキストの情報を圧縮して自身が扱えるようなコンテキストのサイズにしてから作業を行います。

コンテキストスタック

コーディングエージェントがLLMにリクエストを送る際、コンテキストは以下のような階層構造（スタック）で積み上げられて渡されます。上から順にプロンプトに配置され、上位ほど安定的に（毎回ほぼ同じ内容で）存在し、下位ほど動的に変わります。

システムプロンプト: コーディングエージェントの基本的な振る舞いを規定する指示です。「あなたはプログラミングの専門家です」のようなペルソナ設定や、ツールの使い方に関するルールが含まれます。ユーザからは直接見えない部分であり、コーディングエージェントの提供元（GitHub Copilot 等）が設定しています。
プロジェクトのメタデータ: copilot-instructions.md やカスタムインストラクション、カスタムエージェントの定義など、プロジェクト固有の指示やルールがここに含まれます。使用言語やフレームワーク、コーディング規約といった情報もこの層に該当します。
取得されたコンテキスト (RAG等): エージェントがファイル検索やセマンティック検索などを実行して動的に取得した情報です。コードベースが巨大な場合、すべてを渡すのではなく、質問に関連する部分だけを取得して渡す仕組み（Retrieval-Augmented Generation）³が使われます。
現在開いている/編集中のファイル: アクティブなタブのファイル内容や、隣接タブから抽出された関数シグネチャ・型定義などが含まれます。カーソル周辺のコードが最も優先度高く渡されます。
会話の履歴: これまでのやり取りの内容です。直前のやり取りが最も重要ですが、セッション内の過去の会話もコンテキストに含まれます。コンテキストウィンドウの上限に近づくと自動的に圧縮（コンパクション）されます。
ユーザプロンプト: あなたが今まさに入力した質問や指示です。スタックの最下部に配置されるため、LLMにとって最も「直近の情報」として強く認識されます。

このスタック構造を理解しておくと、「どの層にどんな情報を置くべきか」が見えてきます。例えば、毎回同じ指示を繰り返す必要があるなら、それはユーザプロンプト（6層目）ではなく、copilot-instructions.md（2層目）に書くべきです。逆に、一度きりの具体的な作業指示はユーザプロンプトで渡すのが適切です。

GitHub Copilot におけるコンテキストについて

GitHub Copilot におけるコンテキストには、(1)多くのケースで利用されるものと(2)特定の指示、状況でのみ利用されるもの　が存在します。まずは、前者から説明したいと思います。また、今後 GitHub Copilot を利用するツールとして、VS Code を想定して説明します。

(1)多くのケースで利用されるもの

copilot-instructions.md
チャット履歴
タブの情報(VS Code, VS のchat利用時)

これらはGitHub Copilot の Chat や Agent Mode 利用時に、多くのケースでロードされます（ただし、利用機能・環境・設定によって取り扱いは変わります。インライン補完時には隣接タブ中心の参照になります）。

1. copilot-instructions.md

このファイル⁴はあるプロジェクトにおける金科玉条のようなファイルで、多くのリクエストで参照されやすいため、以下のような情報をまとめておくほうがよいでしょう。

*copilot-instructions.md と .instructions.md の違い
copilot-instructions.md はリポジトリ全体に適用される「グローバルな指示」です。一方、後述する *.instructions.md はフロントマターの applyTo で指定されたファイルを扱う際に適用される「条件付きの指示」です。共通ルールは copilot-instructions.md に、ファイル種別固有のルールは *.instructions.md に書く、と使い分けてください。

リポジトリの説明
プロジェクトの目的
作業手順(具体的な手順はエージェントに任せるため概略のみ)
ドキュメントの参照先

GitHub Copilot を使いこなすには、まず copilot-instructions.md に必要な情報をすべて書いてしまってから、必要に応じてカスタムエージェントにコンテキストを分割していくのがおすすめです。

2. チャット履歴

VS Code では、チャットの履歴は、グローバルに一括管理されるのではなく、ワークスペース単位で隔離されて保存されています。保存形式は、JSONで、VS Code のコマンドでエクスポートすることも可能です。

[保存場所]

項目	Windows	macOS	Linux
ベースパス	%APPDATA%\Code\User\workspaceStorage\chat_id(hash)\chatSessions\	~/Library/Application Support/Code/User/workspaceStorage/chat_id(hash)/chatSessions/	~/.config/Code/User/workspaceStorage/chat_id(hash)/chatSessions/

また、チャット履歴はコンテキストウィンドウの上限に近づくと自動でコンパクション（圧縮）されることがあります⁵。この操作は /compact コマンドで手動トリガーできる環境もあります。コンテキストウィンドウの状態は、 /context コマンドでシステムプロンプト、履歴、ファイル内容を視覚的に把握できます。

Claude Code や GitHub Copilot では、このコンパクションの詳細動作が十分に公開されておらず、どの情報が残るかを厳密に断定することは困難です。以下は Codex⁶ や Gemini CLI⁷ 等のオープンソース実装からの推測として、優先されやすい情報の例です。

TODO
実行した内容、ファイルログ
重要だと判断した内容
直前の内容

上記の内容から、主に切り捨てられるのは、途中の試行錯誤した内容や、コーディングエージェントの動作ログ、コーディングエージェントによって重要ではないと判断された内容　となるため、やり取りが続くと途中のやり取りは忘れられる可能性が非常に高いということを覚えておいてください。

[注意]
Claude Code では、hooks のイベントに、PreCompact があるため、圧縮される前に特定の情報を逃がすなどの動作を規定可能です⁸。一方、GitHub Copilot では現時点で同等機能を公式ドキュメントで確認できません。

3. タブの情報

GitHub Copilot では、LLMに送るプロンプトを作成する際、現在開いているファイルの情報だけではなく、エディタで開かれている他のタブ（隣接タブ）からの情報を抽出して渡す仕組みが備わっています。隣接タブの情報はすべて渡されるわけではなく、関数のシグネチャ、データ構造等を渡しています。
隣接タブについて、以下は公開情報と観測結果に基づく参考情報です。⁹

直近の参照度：最後に編集したものほど優先
トークン制限：数KBほど
スキャン対象：ファイル名から役割を推測

この隣接タブの機能を最大限に活かすためには、「関連する型定義ファイルや、参考にする類似機能のファイルを、別タブで開いておき、なおかつ直前に一度開いておく」のが効果的だと思われます。さらに、「不要なタブを削除する」ことも非常に大事な作業になります。

(2)特定の指示、状況でのみ利用されるもの

.
├── .github/
│   ├── agents/                   # [Custom Agent] 実行主体（Persona）の定義
│   │   ├── code-reviewer.agent.md
│   │   └── debugger.agent.md
│   ├── instructions/             # [Instructions] コンテキスト別の指示書
│   │   ├── frontend.instructions.md   # UI/UX、React/Vue等の規約
│   │   ├── backend.instructions.md    # API、DB、ビジネスロジックの規約
│   │   └── testing.instructions.md   # テストコードの書き方やカバレッジ方針
│   ├── skills/                   # [Skills] AIが実行可能なツールの定義
│   │   └── api-client/
│   │       └── SKILLS.md
│   ├── hooks/                    # ワークフロー自動化スクリプト
│   │   └── pre-commit-check.sh
│   └── copilot-instructions.md    # 標準ファイル
├── .vscode/
│   └── settings.json
├── src/
└── README.md

まず、先ほど説明した、copilot-instructions.md を含めた .github 配下のフォルダ構造を共有します。
このなかで、instructions, agents, skills についてそれぞれ説明します。

1. *.instructions.md について

これは特定のファイル種別に対する指示セットを規定するファイル¹⁰になります。
コードスタイルルール等を指定することが多いです。
awesome-copilot のREADME.instructions.mdにサンプルが入っているので、こちらを参考にして構築してみてください。
適用範囲を絞るフロントマターの部分が非常に重要なので、注意してください。

applyTo

* : 現在のディレクトリのすべてのファイル
** or **/*: すべてのディレクトリのすべてのファイル
*.py : 現在のディレクトリのすべてのpython ファイル
src/*.py : srcディレクトリ配下の python ファイル
src/**/*.py : srcディレクトリ配下のすべての python ファイル（ディレクトリも含めて）

また、excludeAgent を設定して、特定のエージェントの時だけ適用させないようにすることが可能です。

[例]

---
applyTo: '**/*.razor, **/*.razor.cs, **/*.razor.css'
excludeAgent: 'code-review'
---

## Blazor Code Style and Structure

- Write idiomatic and efficient Blazor and C# code.
- Follow .NET and Blazor conventions.
- Use Razor Components appropriately for component-based UI development.
- Prefer inline functions for smaller components but separate complex logic into code-behind or service classes.
- Async/await should be used where applicable to ensure non-blocking UI operations.

2. *.agent.md について

カスタムエージェント¹¹は、特定の役割や専門知識を持った「ペルソナ」を定義するものです。例えば、コードレビュー専門のエージェントや、デバッグに特化したエージェントを作成できます。チャットで @エージェント名 と指定することで、そのエージェントに定義された役割・指示に基づいた応答が得られます。

フロントマターには以下の項目を設定します。

---
name: エージェントの名前（チャットで @name として呼び出す際に使用）
description: エージェントの役割の説明（GitHub Copilot がどのエージェントを使うか判断する際に参照されます）
---

本文には、そのエージェントが従うべき指示やルールを記載します。ポイントは、「役割」「観点やルール」「出力フォーマット」の3つを明確に分けて書くことです。以下のサンプルを見てみましょう。

[例]

---
name: code-reviewer
description: コードレビューを行い、品質・可読性・セキュリティの観点からフィードバックするエージェント
---

## 役割
あなたはシニアエンジニアとして、提出されたコードをレビューします。

## レビュー観点
- コードの可読性と命名規則の一貫性
- エラーハンドリングの網羅性
- セキュリティリスク（SQLインジェクション、XSS等）の有無
- パフォーマンス上の問題
- テストカバレッジの妥当性

## 出力フォーマット
- 問題の重大度を [Critical] [Warning] [Info] で分類
- 修正案を具体的なコード例とともに提示

このサンプルでは、name でチャットからの呼び出し名を定義し、description でエージェントの用途を明記しています。本文では「役割」でペルソナを設定し、「レビュー観点」で具体的な判断基準を、「出力フォーマット」で応答の形式を規定しています。このように構造化しておくと、エージェントの出力が安定しやすくなります。

なお、カスタムエージェントは copilot-instructions.md の指示を継承しつつ、さらに専門的な指示を上乗せする形になります。そのため、共通のルールは copilot-instructions.md に書き、特化した指示のみをエージェントに記載するのが効果的です。

3. *.skills.md について

スキル¹²は、エージェントが実行可能な「手順書」を定義するものです。エージェントが「何者か」を定義するのに対して、スキルは「何ができるか」を定義します。例えば、「APIクライアントを生成する」「テストを自動生成する」「ドキュメントをHTMLに変換する」といった具体的なタスクの手順をスキルとして切り出せます。

スキルファイルは .github/skills/<スキル名>/ ディレクトリ配下に SKILLS.md として配置します。

フロントマターには以下の項目を設定します。

name: スキルの名前
description: スキルの説明。ここが最も重要です。 エージェントはこの description を読んで、どのスキルを使うか判断します。曖昧な記述だと適切なタイミングでスキルが呼び出されないため、「いつ」「何のために」使うスキルなのかを明確に記載してください。

本文には、スキルが実行する具体的な手順を記載します。

[例]

---
name: md2html
description: Markdownファイルを校正し、HTML形式に変換してoutputフォルダに出力するスキル。ユーザがMarkdownファイルをHTMLに変換したいとき、または記事を公開用に整形したいときに使用する。
---

## 手順
1. 対象のMarkdownファイルを読み込む
2. 文章の校正を行う（誤字脱字、表記ゆれのチェック）
3. Markdownをhtml に変換する
4. output/ ディレクトリに出力する

Claude Code と GitHub Copilot のスキル実装の違い

GitHub Copilot と Claude Code は、どちらも Agent Skills¹³ というオープン標準に準拠しています。Agent Skills は、Anthropic が開発し OSS として公開した仕様で、SKILL.md（YAML フロントマター + Markdown 本文）でエージェントの手順やナレッジを定義するフォーマットです。GitHub Copilot、Claude Code のほか、Gemini CLI や Goose 等にも採用されています。

ただし、両者の実装にはいくつかの違いがあります。

項目	GitHub Copilot¹²	Claude Code¹⁴
定義場所	`.github/skills/<スキル名>/SKILLS.md`	`.claude/skills/<スキル名>/SKILL.md`
フロントマター	`name`, `description`	`name`, `description`, `context`, `allowed-tools`, `disable-model-invocation` 等
エージェントによる自動選択	description を参照し暗黙的に選択	description を参照し暗黙的に選択（`disable-model-invocation: true` で無効化可能）
ユーザによる呼び出し	手動呼び出しの仕組みなし	`/スキル名` で明示的に呼び出し可能（`user-invocable: false` で非表示化可能）
引数の受け渡し	フロントマターで定義したパラメータをエージェントが自動補完	`$ARGUMENTS` プレースホルダーで受け渡し
サブエージェント実行	未対応	`context: fork` で隔離実行が可能
動的コンテキスト注入	未対応	!`command` 構文でシェルコマンドの結果を注入可能

共通しているのは「description の質がスキルの活用精度を左右する」という点です。どちらのツールでも、description に具体的なユースケースやトリガー条件を書いておくことが重要です。Claude Code はスキルの呼び出し制御（自動／手動の切り替え）やサブエージェント連携など、より多くの拡張機能を備えています。

4. hooks について

hooks¹⁵ は、エージェントのワークフローの特定のタイミングで自動実行されるスクリプトを定義する仕組みです。instructions や agents がエージェントの「判断」に影響を与えるのに対して、hooks は「判断を介さず確実に実行される処理」を担います。

例えば、以下のようなユースケースがあります。

コード保存時にリンターやフォーマッタを自動実行する
コミット前にテストを走らせる
特定のファイル変更時にビルドを自動実行する

hooks はコンテキストエンジニアリングの本題からは外れますが、「エージェントに任せるべき処理」と「決定論的に実行すべき処理」を分離する上で重要な概念です。詳細は GitHub の公式ドキュメント¹⁵を参照してください。

コンテキストキャッシュとメモリーについて

ここまでは、Agent を使うクライアント側のコンテキストについて説明しました。ここからは視点を切り替え、サーバ側の最適化・保持機構としてのコンテキストキャッシュ(Context Caching)とメモリー(Memory System)について説明します。

コンテキストキャッシュについて

これは、主にLLMの推論の最適化技術です。¹⁶¹⁷

仕組み: 巨大なコードベースをプロンプトに含める際、一度計算したトークンの状態をサーバ側で保持します。それを次回以降のアクセス時にプロンプトを比較して、キャッシュにあれば再利用する形になります。一般的な実装では前方一致ベースの検索が使われることが多く、ツール定義やプロンプトの変更が少ないほどキャッシュヒットしやすくなります。
メリット: 次の質問で同じコードを参照した際、ゼロから計算しなおさなくて済むため、レスポンスが速くなり、入力トークン数を削減できます。
デメリット: あくまでも一時的な記憶

補足: GitHub Copilot が内部でコンテキストキャッシュをどのように活用しているかは公開されていません。上記は Google Gemini や Anthropic Claude が公開しているコンテキストキャッシュの一般的な仕組みの説明です。ただし、GitHub Copilot のバックエンドでもこれらのLLMが利用されているため、同様の最適化が行われていると推測されます。

コンテキストキャッシュ活用の一般論として、以下の方法が有効です。

キャッシュ検索が前方一致のため、プロンプトの冒頭にテンプレのファイル等を置き、キャッシュ検索に引っかかるようにする
ファイルを変更するたびにプロンプトを投げない
ツール定義も変更しない

メモリーについて

GitHub Copilot Memory¹⁸ は、セッションやプロジェクトを跨いで永続的に記憶を保持する仕組みです。コンテキストキャッシュが一時的な最適化であるのに対し、メモリーは「あなたの好みや習慣」を長期的に学習するものと考えてください。

仕組み: チャットでのやり取りの中で、GitHub Copilot が「記憶すべき」と判断した情報（コーディングスタイルの好み、よく使うフレームワーク、プロジェクト固有のルールなど）を自動的に保存します。また、ユーザが明示的に「これを覚えておいて」と指示することもできます。
メリット: 毎回同じ指示を繰り返す必要がなくなります。例えば「TypeScript では関数型スタイルで書いてほしい」という好みを一度伝えれば、以降のセッションでもその好みが反映されます。
管理方法: 保存されたメモリーは GitHub の設定画面（github.com > Settings > Copilot > Memory）から確認・削除が可能です。意図しない情報が保存されていないか、定期的に確認することをおすすめします。

注意点として、メモリーはあくまで個人の好みやスタイルに関する情報の保持が主な用途です。プロジェクト固有のルールやコーディング規約は、copilot-instructions.md やカスタムインストラクションに記載するほうが、チーム全体で共有でき、バージョン管理もできるため適切です。メモリーと instructions を適切に使い分けることで、個人の生産性向上とチーム全体のコード品質の両立が可能になります。

コンテキストエンジニアリングのためにGitHub Copilotで今からはじめること

copilot-instructions.md を作成する: 作業において必要な共通知識は、まず .github/copilot-instructions.md に集約します。最初から完璧を目指す必要はなく、「このリポジトリは何か」「使用技術スタック」「守ってほしいルール」の3点から始めるのがおすすめです。例えば、「社内向け在庫管理システムのバックエンドAPI / Python 3.12・FastAPI・PostgreSQL / 関数にはdocstringを必ず書く」といった粒度で十分です。
必要なタブだけ開く: 作業に関係ないファイルを閉じるだけで、隣接タブのノイズが減り、コード補完の精度が向上します。VS Code のショートカット Ctrl+K, Ctrl+W（すべてのタブを閉じる）を活用して、作業開始時にタブをリセットし、必要なファイルだけを開き直すのが効果的です。
必要な会話履歴のみ残す: 試行錯誤でやり取りが長くなると、途中の文脈が失われやすくなります（前述の Lost-in-the-middle 現象）。一つの実装が完了したら新しいチャットセッションを開始し、必要な背景情報だけを改めて伝える方が精度が上がります。実装→質問→修正のような流れなら、質問のチャットを実装時点まで戻すことも有効です。
段階的開示でコンテキストを構造化する: 繰り返し伝えている指示（「テストは pytest で書いて」「コミットメッセージは Conventional Commits で」等）があれば、それは .github/instructions/ にカスタムインストラクションとして切り出すべきサインです。さらに、特定の役割が必要ならカスタムエージェントに分割し、「APIエンドポイントを追加する際は、ルーティング → サービス → テストの順で作成する」のような決まった手順は .github/skills/ にスキルとして定義します。必要になった段階でコンテキストが取得される仕組みを整えることが重要です。
決定論的なタスクはフックで実装する: エージェントの判断に委ねるべきでない定型処理（リント実行、フォーマッタの適用等）は、フックとして切り出します。
これらの改善は、Eval（評価）を実施したうえで繰り返し行う: コンテキストの整備は一度で完成するものではありません。Eval とは、同じプロンプトや同じタスクに対するエージェントの出力を体系的に評価する手法です¹⁹。例えば、instructions を変更する前後で同じコード生成タスクを実行し、出力の品質を比較することで、変更が改善につながったかを判断できます。エージェントの出力を評価し、不足している情報があれば追加し、冗長な部分があれば削る、という改善サイクルを回すことが大切です。

小さく始めて段階的にコンテキストを整備していくのがポイントです。一度にすべてを整備しようとすると挫折しやすいので、まずは 1 と 2 から試してみてください。

今は、複数のAgent による並列、協調作業等の記事が注目されることが多いですが、まずは、コンテキストエンジニアリングを駆使して作業の精度を高めた上で作業自体の生産性を上げる方が後々効いてくるかと思います。

参考リンク

Context Engineering (Latent Space): https://www.latent.space/p/context-engineering ↩
Lost in the Middle (arXiv): https://arxiv.org/abs/2307.03172 ↩
What is Retrieval-Augmented Generation? (GitHub Blog): https://github.blog/ai-and-ml/generative-ai/what-is-retrieval-augmented-generation-and-what-does-it-do-for-generative-ai/ ↩
Adding repository custom instructions for GitHub Copilot: https://docs.github.com/en/copilot/customizing-copilot/adding-repository-custom-instructions-for-github-copilot ↩
Copilot Chat in VS Code: https://code.visualstudio.com/docs/copilot/copilot-chat ↩
OpenAI Codex (GitHub): https://github.com/openai/codex ↩
Gemini CLI (GitHub): https://github.com/google-gemini/gemini-cli ↩
Claude Code Hooks: https://docs.anthropic.com/en/docs/claude-code/hooks ↩
GitHub Copilot Log Analysis (Zenn): https://zenn.dev/longbow/articles/20260114_github_copilot_log_analysis ↩
Adding custom instructions for GitHub Copilot: https://docs.github.com/en/copilot/customizing-copilot/adding-custom-instructions-for-github-copilot ↩
Copilot extensibility in VS Code: https://docs.github.com/en/copilot/customizing-copilot/extending-copilot-chat-in-vs-code/copilot-extensibility-in-vs-code ↩
awesome-copilot (GitHub): https://github.com/github/awesome-copilot ↩ ↩²
Agent Skills: https://agentskills.io/ ↩
Claude Code Skills: https://code.claude.com/docs/en/skills ↩
Using Copilot Hooks in VS Code: https://docs.github.com/en/copilot/customizing-copilot/extending-copilot-chat-in-vs-code/using-copilot-hooks ↩ ↩²
Gemini API Prompt Caching: https://ai.google.dev/gemini-api/docs/caching ↩
Claude Prompt Caching: https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching ↩
Copilot Memory Public Preview (GitHub Changelog): https://github.blog/changelog/2025-04-21-copilot-memory-public-preview/ ↩
Testing AI-generated code (GitHub Docs): https://docs.github.com/en/copilot/testing-copilot/testing-ai-generated-code ↩

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up