このガイドは、プロンプトから始めるやり方は単純な修正にはうまくいくが、作業がより複雑に、あるいはより協働的になるにつれて破綻すると論じ、その代わりとなる 3 部構成のフレームワークを提案する。その中核にある 2 つの概念は、エージェントプリミティブ、すなわち AI エージェントが体系的に作業できるようにする再利用可能で設定可能な構成要素と、コンテキストエンジニアリング である。後者は、エージェントが常に正しい情報に焦点を当てるようにすることと定義されている。掲げられた目標は、独立してコードを書き、しかもそれを信頼性高く、予測可能に、一貫して行う AI システムである。
フレームワークの 3 つの層は、互いの上に積み重なるものとして示されている。第 1 層は、プロンプトエンジニアリングの手段としての Markdown である。その見出し、リスト、リンクがモデルの推論を導き、出力をより予測可能にするとされる。第 2 層は、それらの手法をファイルに変える。.instructions.md、.chatmode.md、.prompt.md、.spec.md、.memory.md、.context.md であり、それぞれが特定の能力やルールを担う。第 3 層はコンテキストエンジニアリングであり、記事が残された失敗モードと位置づけるものに対処する。すなわち、優れたプロンプトやプリミティブであっても、限られたモデルのアテンションを奪い合う無関係なコンテキストに直面すると失敗するという問題である。
記事の後半は、異なる種類の議論を展開する。これらの Markdown ファイルは、コードではなく自然言語で書かれた正真正銘のソフトウェアであり、モジュール化され、再利用可能で、依存関係、進化、配布を持つと主張する。したがって、他のあらゆるソフトウェアエコシステムが発展させてきたのと同じインフラ、すなわちランタイム、パッケージマネージャー、CI/CD によるデプロイを必要とするという。その必要に対する記事の答えが APM（Agent Package Manager） であり、これも著者がメンテナンスしている。
要点
- フレームワークは、Markdown によるプロンプトエンジニアリング + エージェントプリミティブ + コンテキストエンジニアリング = 信頼性、と要約されている。
- 中核となるエージェントプリミティブは、エージェントに特定の能力やルールを提供する、単純で再利用可能なファイルまたはモジュールと定義されている。
- プロンプト内の Markdown リンクは、ファイルや Web サイトから関連情報を取り込むコンテキスト注入ポイントとして位置づけられている。
- チャットモードは、現実世界の資格制度になぞらえた職業上の境界として示されている。記事の捉え方では、職業上の資格があるからこそ建築家は施工をせず、技術者は計画を立てない。その例示として、橋の計画は建築家に任せたいが、建設までは任せたくないだろうと述べる。各モードにはその領域に必要な MCP ツールだけが与えられ、記事はこれを領域をまたぐセキュリティ侵害を防ぐものと位置づけている。
- 記事が挙げるコンテキストエンジニアリングの手法は、セッションの分割（計画、実装、テストに別々のエージェントセッションを使う）、
applyToという YAML フロントマターのパターンでスコープを限定した対象指定の.instructions.mdファイル、.memory.mdによるメモリ駆動開発、コンテキスト補助ファイル、そしてモデルのアテンションを 1 つの領域にとどめるために使うチャットモードである。 - エージェント型ワークフローは、複数のプリミティブを完全なプロセスへと協調させる
.prompt.mdファイルとして定義されており、IDE、ターミナル、CI パイプラインのいずれでも実行できるよう設計されている。 - 記事は、インナーループ（VS Code と GitHub Copilot を使った対話的な開発、テスト、改良）と、再現可能な実行、CI/CD との統合、本番デプロイを担うエージェント CLI ランタイムからなるアウターループとを区別している。アウターループ を参照のこと。この wiki では、同じ用語の対を別の意味で記録している。
- VS Code は
.instructions.md、.prompt.md、.chatmode.mdをネイティブにサポートしている一方、.spec.md、.memory.md、.context.mdはこのフレームワークがその上に追加するパターンだと主張している。 - 記事が予測するエコシステムの進化は 4 段階からなる。エージェントプリミティブのファイルとしての生のコード、エージェント CLI ランタイムとしての実行環境、パッケージ管理、そして共有ライブラリとコミュニティパッケージからなる活発なエコシステムである。これは JavaScript の成長における npm の役割を明示的に手本としている。
- 記事は決まった順序で始めることを推奨している。まず指示、次にチャットモード、次に再利用可能なプロンプト、最後に仕様テンプレートである。
- この実践の成果として掲げられているのは、複利的な知性（compound intelligence）である。実装の失敗を
.memory.mdに、文書化されたパターンを.instructions.mdに、洗練されたワークフローを.prompt.mdに記録し、反復的な改良を通じて向上していく。これは測定された結果ではなく、著者による利点の捉え方であり、記事はフレームワークの評価を報告していない。
背景
この記事は GitHub 自身のブログで公開されており、その具体例は全体を通じて GitHub の製品上で動いている。インナーループには VS Code 上の GitHub Copilot、アウターループのエージェント CLI ランタイムとして推奨される GitHub Copilot CLI、.github フォルダ内の copilot-instructions.md、依存関係として宣言される GitHub MCP サーバー、本番デプロイのための GitHub Actions、そして仕様テンプレートの構築に推奨される GitHub 自身の spec-kit である。例外はパッケージ管理の層であり、議論の後半が軸とするのはまさにこの層である。APM と、記事が全体を通じてリンクしている awesome-ai-native のドキュメントは、GitHub のものではなく著者自身のプロジェクトである。エージェントプリミティブにはパッケージマネージャーが必要だという主張を読む際には、この関係を念頭に置いておくべきである。
記事のファイル規約がベンダー固有である箇所については、記事自身がそう明言している。VS Code がネイティブにサポートする 3 つのファイル種別と、フレームワークが導入する 3 つとを区別しており、GitHub がリポジトリ固有のガイダンスのためにカスタム指示を提供していることにも触れている。エコシステムがこれまでのプログラミングエコシステムと同じ道をたどるという主張は、証拠としてではなく、著者がその歴史から読み取ったパターンとして示されている。