address-feedback

フィードバックへの対応

レビューのフィードバックを、検証済みの結果に基づく、対応状況が明確な判断、承認済みの変更、および返信にまとめます。

フィードバックのソースには、次の2種類があります。

• 追跡可能なソースには、対応可能なコメントと返信先があります。プルリクエストまたはマージリクエスト、イシュー、チケット、共有ドキュメントへのコメントなどです。
• 追跡できないソースは、エージェントが書き込める返信先がないプレーンテキストです。会話に貼り付けられたメモ、ファイル、メールやチャットのメッセージ、会議の議事録、レビュアーによる口頭での要約などです。

対象とは、フィードバックが関係するものです。コード、ドキュメント、設計、仕様、設定などが該当します。手順2から4はどちらの種類のソースでも同じですが、手順1、5、6は種類によって異なります。

AGENTS.md からタスクトラッカーの設定ファイルが指定されている場合、その設定ファイルに、設定済みのトラッカーの読み取り方と更新方法が記載されています。設定ファイルがない場合や、その内容に記載がない場合は、ソースとアクセス方法を直接確認してください。

プロセス

1. ソース、対象、および作業コンテキストを特定する

ユーザーが指定または提供したソースを使用してください。それ以外の場合、現在のブランチまたは会話からソースが1つだけだと特定できる場合に限り、ソースを推測してください。特定できない場合は質問してください。

追跡可能なソースの場合は、タイトルと説明に加え、すべてのコメントとレビュースレッドを読んでください。変更の意図を説明している、または変更に制約を課しているものは、解決済みや古いスレッドも含めます。返信に使うため、各コメントの識別子を記録してください。

追跡できないソースの場合は、テキスト全体を読み、個々のポイントに分割してください。各ポイントには、内容を認識するのに必要最小限の引用文と、安定した参照番号（F1、F2、...）を付け、分かる場合はフィードバックを提供した人も記録してください。

対象を特定し、その現在の状態を確認してください。関連するコードと差分、ドキュメント、またはフィードバックが参照する成果物を読みます。対象がリポジトリ内にある場合は、リポジトリの指示を読み、チェックアウト中のブランチが変更先として適切であることを確認してください。対象を特定できない場合は、レビューされたバージョンを推測せずに質問してください。

ソースの種類、コメントまたはポイントの全件、対象の現在の状態が把握でき、リポジトリで作業する場合は変更先のブランチも確認できたら完了です。

2. フィードバックを整理する

実質的なコメントまたはポイントをそれぞれ1件のフィードバックとして扱ってください。同じ結果を求めている場合に限り、重複するものをグループ化し、グループ内のすべての参照番号を残して、それぞれに回答できるようにしてください。自動ステータスメッセージ、変更要求を伴わない承認、社交的な応答は、実質的でないものとして記録してください。

実質的な各項目に、次のいずれかの対応方針を割り当ててください。

• 受け入れ：要求どおりに対応するのが適切です。
• 調整：懸念は妥当ですが、別の変更の方が適切に解決できます。
• 対応済み：対象はすでに要求を満たしています。根拠を示してください。
• 見送り：要求が仕様、プロジェクトの制約、またはより根拠のある設計と矛盾します。トレードオフを説明してください。
• 保留：判断に必要な情報や決定が不足しているため、責任ある対応方針を決められません。

各項目を相互に照らし合わせ、ソースに記載された意図、プロジェクトの規約、テスト、現在の動作を確認してください。矛盾やスコープの拡大があれば、ユーザーが判断できるよう明示してください。事実確認が必要な場合は、保留とする前に読み取り専用の調査を行ってください。

参照番号、要求、評価、対応方針、提案する変更または返信を含む、簡潔な表を1つ提示してください。その後、変更が予想されるファイルを含め、実装と検証の計画を示してください。判断が必要な場合は、明確な推奨案を提示してください。

実質的な項目がすべて一度ずつ記載され、実質的でない項目もそれぞれ別に記録され、計画を受け入れた場合の影響をユーザーがすべて確認できる状態になったら完了です。

3. 変更計画の承認を得る

対応方針と計画を承認するか、修正するようユーザーに依頼します。この承認ゲートで許可されるのは、ローカルでの変更のみです。修正によって作業内容が大幅に変わる場合は、計画を再度提示します。

ユーザーが計画を承認した後にのみ、対象を編集します。承認後は、計画で扱われている定型的な選択について確認を求めず、実装と検証を続けます。

すべての実質的な項目について、ユーザーが具体的な対応方針とアクションを承認した時点で完了です。

4. 実装と検証

承認された変更のみを実装し、無関係な作業は維持します。リポジトリのコードを変更する場合は、承認された計画をユーザー承認済みの変更単位として、implement-changes.md に従います。それ以外の対象については、変更内容に応じた検証を行います。実装中に、承認された対応方針が誤っている、または作業範囲を大幅に広げる必要があると判明した場合は、その項目の作業を中断し、根拠を説明して計画の承認ゲートに戻します。

承認されたすべての対応方針に照らして、結果を確認します。テストスイートに合格しただけでは、項目単位で対応したことにはなりません。それぞれの項目を、変更した対象、既存の根拠、または明示した判断と結び付けます。

承認された変更が実装され、関連する検証に合格し、すべての実質的な項目について結果が確認された時点で完了です。

5. 返信を作成する

各返信の冒頭に、判断とその理由を示します。実装した変更については、確認可能な結果と、それを裏付ける検証を明記します。依頼を調整または見送る場合は、トレードオフを率直に伝えます。ステップ 4 で検証されていない変更を、完了したと述べてはいけません。返信は、フィードバックと同じ言語で簡潔かつ具体的にします。ユーザーから求められた場合、またはプロジェクトの慣例で必要な場合に限り、[AI] 接頭辞を使用します。

• 追跡対象のソース：見送った項目、対応できない項目、重複項目、すでに対応済みの項目も含め、実質的なコメントごとに返信を 1 件作成し、トラッカーがスレッドに対応している場合は元のスレッドに投稿します。スレッドがない課題やチケットでは、返信を特定できる最小限のテキストのみを引用します。スレッドの解決やステータス変更の提案は別途列挙します。返信の投稿は、スレッドの解決、レビューの承認、チケットのクローズ、ステータスの変更を許可するものではありません。
• 追跡対象外のソース：実質的なすべての指摘に、参照先または短い引用を添えて回答する、レビュー担当者宛ての統合返信を 1 件作成します。フィードバックを受け取った媒体で作成します。変更だけを回答として求めるとユーザーが述べている場合は、返信を省略します。

すべての実質的な項目に正確な返信案が用意されている（または追跡対象外のソースについてユーザーが返信を不要としている）こと、およびトラッカーへの変更がある場合は別途列挙されていることをもって完了とします。

6. 確認して提出する

返信案と、別途列挙したトラッカーへの変更をユーザーに承認してもらい、要望があれば修正します。実装結果を確認した後に投稿する返信文をユーザーが正確な文面で指定済みの場合に限り、この確認を省略します。

• 追跡対象のソース：ステップ 1 で確認したアクセス方法を使用して、承認された返信を投稿します。スレッドの配置を維持できる場合は、レビューをまとめて送信する方法を優先します。別途承認された解決処理やステータス変更のみを適用します。投稿したコメントの URL または参照先を報告します。
• 追跡対象外のソース：承認された返信をユーザーがすぐに送信できる形で渡します。エージェントには送信する手段がありません。

意図的に返信を付けなかった項目と、最終的な検証結果を報告します。

承認されたすべての返信が投稿先に公開されるかユーザーの手元に渡り、すべての実質的な項目が処理され、承認されていないトラッカーへの変更がない時点で完了です。