エージェントはリポジトリを読み取ります。これで必要な情報の大部分は得られますが、人々の頭の中やWiki、あるいは2年前の会話に残る決定事項までは把握できません。
プロジェクトコンテキストここに残りの情報を記載します。
Coroidが自動的に判断できる内容
リポジトリだけから、エージェントが把握できる情報は以下の通りです：
- 使用されている言語、フレームワーク、ライブラリ
- プロジェクトのビルド、テスト、実行方法
- 既存のパターン — エラー処理方法、モジュール構造、命名規則など
- 依存関係
これらの情報を文書化する必要はありません。繰り返し記述するのは無駄な労力であり、コードの方がより信頼性の高い情報源なので、文書がコードと乖離するリスクもあります。
推測できない事項
コードは何を行ったかは示しますが、理由までは示しません。:
- 明らかな代替案よりも特定のライブラリが選ばれた理由で、その理由が今も有効なケース
- 重複に見えるが意図的な区切りとなっているパターン
- 特定のチームと相談しない限り触ってはいけないモジュール
- 合意済みだがまだ適用されていない規約
- コードベース外の制約 — コンプライアンス、契約、進行中のマイグレーションなど
これらがプロジェクトコンテキストに含まれるべき内容です。判定基準は簡単です：**リポジトリのみを読んだ人がこれを理解できるか？**可能であれば記載不要です。不可能な場合は文書に記録してください。
コンテキストの追加
ドキュメント、ポリシー、参照資料をプロジェクトの「コンテキスト」セクションに添付します。コンテキストアーキテクチャに関する注記、意思決定記録、スタイルガイド、API契約書などが利用できます。
良質なコンテキストは簡潔かつ具体的です。人向けに書かれた40ページのオンボーディングガイドの大半は記述に過ぎませんが、実際の制約を記した3段落が重要なのです。それらを抽出してください。
タスク別コンテキスト
プロジェクトに紐づくコンテキストは全ての作業に適用されます。特定の作業 — チケット、設計文書、顧客報告書 — に関連する情報は、タスクに直接添付してください。
恒久的に正しい情報はプロジェクトコンテキストに保持します。タスク専用の注記がプロジェクトコンテキストに含まれると、今後の全タスクでノイズになってしまいます。
内容を最新の状態に保つ
古くなったコンテキストはコンテキストがない場合よりも悪影響を及ぼします。なぜならエージェントがそれを信頼できる情報と扱うからです。規約が変更された際には、コードの変更と同時にコンテキストも更新してください。
再作業のコメントで同じ内容を繰り返し修正している場合、それはコンテキストに欠落があるか、または誤った情報が含まれているサインです。