エージェントに有用なリポジトリ情報を渡す

現在のチェックアウトから始める

エージェントは、変更対象のリポジトリとブランチを知る必要があります。作業ディレクトリに無関係な変更があるかも知る必要があります。これらは、安全に編集できる対象と、最終差分の解釈に影響します。

実装前に、プロジェクトの指示とパッケージ設定を調べるよう依頼します。別のリポジトリで覚えたコマンドは、ここでは使えないかもしれません。見慣れたフレームワーク名だけでは、インストール済みのバージョンやプロジェクトの規約は分かりません。

小さな変更では、関連モジュール、呼び出し元、テスト、アーキテクチャ判断を渡します。調査で具体的な必要性が分かったら、情報を追加します。

恒常的なルールはリポジトリに記録する

指示ファイルには、サポートするコマンド、モジュールの境界、レビュー要件、責任者の判断が必要な操作を記述できます。AGENTS.mdという慣例は、コーディングツールがこれらの情報を見つける場所を示します。対応状況や指示の優先順位はツールによって異なるため、実際の動作を確認してください。

恒常的なプロジェクトのルールはリポジトリに置きます。現在のタスクは作業指示書に書きます。指示ファイルを、すべての会話の履歴や一時的な計画の一覧にしないでください。

有用な指示は「ルートの変更でアクセスの動作が変わる場合は、認可の結合テストを実行する」です。曖昧な指示は「常にセキュリティに注意する」です。前者なら、条件と実施すべき操作をレビュー担当者が確認できます。

指示をコードと照合する

コマンド、ディレクトリ、アーキテクチャが変わると、指示が古くなります。ガイドが存在しないスクリプトを示している場合は、パッケージ設定を調べます。文書にサービスが読み取り専用と書かれていても、信頼する前に権限を確認します。

矛盾を記録してください。現在のバージョンについての直接の証拠から、実装の動作を理解します。古いコードがポリシーに違反しているからといって、意図的に定めたポリシーを黙って捨ててはいけません。ポリシーと現在の動作は、異なる問いに答えます。

例えば、ガイドが共有ブランチへの直接書き込みを禁じている一方、古いスクリプトがそれを実行しているかもしれません。正しい対応は、ポリシーを守ってスクリプトを修正することです。既存のコードは、禁止された操作を繰り返す許可にはなりません。

関連性と安全性を保つ

リポジトリ全体には、認証情報、非公開のテストデータ、顧客のエクスポートデータ、古いサポートログが含まれる可能性があります。リポジトリへアクセスできても、すべてのファイルがモデルサービスに渡してよいとは限りません。

承認済みのツールとデータの扱いのルールに従います。コンテキストからシークレットを除外してください。可能なら、顧客の例を架空のデータに置き換えます。アップロードしたファイルに加え、接続されたツールも確認します。検索コネクターは、最初のプロンプトに含まれていない情報を取得することがあります。

「シークレットを読まない」というリポジトリの指示は有用です。ただし、シークレット保管先や機密ディレクトリへのアクセス制限の代わりにはなりません。

次の担当者に役立つ記録を残す

完了時は、変更した動作、検証、未解決の制約をpull requestに記録します。サポートするワークフローが変わったら、継続的に参照するプロジェクト文書を更新します。エージェントとの会話全体をリポジトリへコピーしないでください。

記録は、後の保守担当者が長い会話を再構成せずに作業を再現できるものにします。正式な文書へリンクし、恒常的な各ルールの正式な説明を一つに保ちます。

よいコンテキストは、繰り返しの調査を減らします。期待する動作と使えるコマンドが明確なので、誤りも見つけやすくなります。