receive-feedback

フィードバックを受け取る

概要

検証を最優先する方針で、コードレビューのフィードバックに対応します。 形だけの同意はしません。対人的な配慮より技術的な正確さを優先します。

オーケストレーターは、厳格な項目ごとの契約に従って検証し、修正を適用します。 エージェントがサブエージェントをサポートしている場合、有効な項目ごとに専任のサブエージェントを並行して起動して修正します。サポートしていない場合、オーケストレーター自身が同一の修正品質契約に従い、項目を一つずつ順番に修正し、同じ結果を出力します。

クイックリファレンス

┌─────────────┐     ┌──────────────┐     ┌──────────────────────┐
│   VERIFY    │ ──▶ │   CONFIRM    │ ──▶ │   APPLY FIXES        │
│ (tool-based)│     │ ("launch     │     │ (one fix per valid   │
│             │     │  fixes for   │     │  item — parallel     │
│             │     │  1,2,3?")    │     │  subagents if        │
│             │     │              │     │  supported, else     │
│             │     │              │     │  sequential)         │
└─────────────┘     └──────────────┘     └──────────────────────┘

基本原則

検証し、一度確認を取り、選択された項目の修正を適用します。

バグが有効であれば、必ず修正します。それだけです。先送りも言い訳もありません。サブエージェントを利用できる場合は、各項目を一つずつサブエージェントが並行して修正します。利用できない場合は、オーケストレーターが同じ契約に従って各項目を順番に修正します。

使用する場面

• 別の LLM セッションからコードレビューを受ける場合
• PR のレビューコメントに対応する場合
• CI やリンターのフィードバックを評価する場合
• ペアプログラミングでの提案を扱う場合

ワークフロー

1. 現在のコードベースに照らし、すべての項目を検証します（記憶ではなく、ツールを使います）。
2. 各項目を有効（修正必須）または無効（証拠を示して却下）に分類します。
   • 本当に解釈できない項目については、確認の質問を一度だけ行います。それ以外に例外はありません。
3. 短い要約を出力します。無効な項目には証拠を添え、有効な項目には番号を付けます。
4. launch fixes for 1,2,3? というプロンプトを正確に一つだけ尋ねます（有効な項目すべての番号を列挙します。既定の提案には常に有効な項目すべてを含めます）。
5. ユーザーの返信を処理します。
   • 承認（y、yes、go、ok、do it、lgtm、または ↵ のみ）→ 提案した項目すべてを実行します。
   • 数字をカンマまたはスペースで区切ったリスト（例：1,3 または 1 3 4）→ 指定された番号だけを実行します。提案した有効な項目の範囲内でなければなりません。ユーザーが省略した項目は先送り扱いにせず、今回実行しないだけです。
   • no／cancel／stop → 実行せずに停止します。
   • その他の返信 → プロンプトを一度だけ再表示します。新たな処置を勝手に決めてはいけません。
6. 修正品質契約に従い、選択された各項目の修正を適用します。エージェントがサブエージェントをサポートしている場合、選択された項目ごとにサブエージェントを一つ並行して起動します（この場合、オーケストレーターは自分でファイルを編集しません）。サポートしていない場合、同じ契約に従い、各修正を一項目ずつ順番に適用します。どちらの方法でも同じ結果を出す必要があります。
7. 項目ごとの結果を集約し、最終回答の表を出力します。

禁止事項

以下は絶対に守らなければなりません。オーケストレーターは次のことをしてはいけません。

• どの項目を修正するかユーザーに尋ねること。許される質問は、有効な項目すべてを既定値とする launch fixes for <numbers>? のみです。（ユーザーが独自の番号の一部を返信して上書きすることはできます。これはユーザーによる上書きであり、エージェントからの質問ではありません。）
• 問題が以前から存在していたと主張すること。レビュアーがこの PR で指摘した問題は、対応対象です。
• 問題が PR の対象外だと主張すること。このブランチにバグが存在するなら、PR の責任範囲です。
• 有効な項目を「後で」「バックログ」「フォローアップ PR」「将来のチケット」に先送りすること。
• リスク、複雑さ、時間、変更の波及、「軽微」「見た目だけ」「エッジケース」といった理由を使い、有効な項目の修正を避けること。
• 複数の修正をまとめること。有効な項目一つにつき、独立した修正一つです（サポートされている場合はサブエージェント一つ、そうでない場合は対象を絞った順次作業一回）。
• サブエージェントを利用できる場合、オーケストレーターが直接コードを編集すること。代わりに、修正ごとにサブエージェントへ委任してください。

コードまたはセキュリティのレビュアーが指摘した有効なバグは、必ず修正しなければなりません。ほかに選択肢はありません。

厳格なゲート

各ゲートの合格条件を満たすまで、次のゲートに進まないでください。詳細は VERIFICATION.md、EVALUATION.md、RESPONSE.md に記載されています。

ゲート 1 — 検証エビデンス（項目ごと）

1. 参照されているコードまたは動作を確認します（ファイルを読む、コードベースを検索する、該当するテストを実行する、または VERIFICATION.md に記載された別の確認方法を使います）。
2. 結果をエビデンスとともに記録します。結果は VALID（指摘が妥当で対応可能）または INVALID（指摘が誤り）とします。エビデンスには、ファイルパスと行の範囲、コマンド／テストの結果、またはツール出力の短い引用を記載します（言い換えだけでは不十分です）。
3. 解釈できない場合は、具体的な質問とともに NEEDS CLARIFICATION と記録します。判断を捏造しないでください。

合格条件： すべての項目に VALID / INVALID / NEEDS CLARIFICATION のいずれかとエビデンスがあること。不合格（停止）： エビデンスなしで進めること、または VALID の項目を「skip」／「defer」／「pre-existing」／「out of scope」に格下げすること。

ゲート 2 — バッチ一括確認

1. 無効な項目（却下のエビデンス付き）と、有効な項目（番号付き）を出力します。
2. 次のプロンプトを1 回だけ提示します：launch fixes for <comma-separated numbers>? — <numbers> には、有効な項目の番号をすべて含めます。事前に候補を絞ってはいけません。
3. Workflow の解決ルールに従ってユーザーの返答を受け付けます。確認 → 全項目、番号の一部 → その番号のみ、拒否 → 停止。

合格条件： ユーザーが提示された番号をすべて確認するか、一部を指定し、ゲート 3 の前に選択された項目が書面で確定していること。不合格（停止）： 事前に絞ったデフォルトを提案すること、「どれを修正しますか？」と尋ねること、または有効な項目の保留を提案すること。

ゲート 3 — 選択された項目の修正

1. 選択された各項目に対して、元のフィードバックのテキスト、検証エビデンス、対象ファイル／行、および Fix-Quality Contract を含む、独立した修正を 1 件だけ実施します。
2. エージェントがサブエージェントに対応している場合は、 1 つのブロックで項目ごとにサブエージェントを 1 つ割り当て、並列で実行させます。オーケストレーターはファイルを編集しないでください。対応していない場合は、 同一の契約のもと、各修正を 1 項目ずつ順番に自分で適用します。

合格条件： ユーザーが選択したすべての項目が、契約に従って修正されていること（対応している場合は項目ごとにサブエージェントを 1 つ割り当て、対応していない場合は項目ごとに集中して順番に処理します）。不合格（停止）： 修正をまとめること、またはユーザーが選択した項目をスキップすること。

ゲート 4 — 回答成果物（バッチ）

1. サブエージェントからの応答後、RESPONSE.md の構造化テンプレートに記入します。
2. 回答は Implemented と Rejected の 2 つのセクションだけで構成します。Deferred セクションはありません。
3. 今回のラウンドからユーザーが明示的に除外した有効な項目は、表の下に次の 1 行だけを記載します — Not run this round: <numbers> (user-excluded) — それ以外は記載しないでください。「deferred」や「out of scope」として扱ってはいけません。

合格条件： すべての項目がファイルと行の引用付きで Implemented または Rejected に記載され、ユーザーが除外した有効な項目があれば、表の下に指定どおりの文言で記載されていること。不合格（停止）： 項目を省いた要約を提出すること、却下の根拠を示さないこと、または「Deferred」の分類を作ること。

コマンドワークフロー

フィードバックファイルのパスを引数として、receive-feedback スキルを呼び出します。

1. $ARGUMENTS にあるフィードバックファイルを読み取る
2. 番号付き、箇条書き、自由形式を問わず、個々のフィードバック項目を解析する
3. VERIFICATION.md に従って各項目を検証する
4. launch fixes for <numbers>? という単一のプロンプトで確認する
5. 有効な項目ごとに修正を適用する — サブエージェントに対応している場合は項目ごとに 1 つ割り当て、対応していない場合は順番に 1 件ずつ処理する
6. RESPONSE.md で定義された回答の要約を作成する

期待されるフィードバックファイル形式

1. Remove unused import on line 15
2. Add error handling to the API call
3. Consider using a generator for large datasets
4. Fix typo in variable name: `usr` → `user`

自由形式の文章も受け付けます。テキストから対応可能な項目を抽出してください。

修正指示テンプレート

項目を修正する際は、サブエージェントに依頼する場合も、自分で順番に対応する場合も、修正概要に以下を必ず含めてください。

• 元のフィードバック全文（そのまま記載）。
• 検証結果：ファイルパス、行範囲、確認できた内容。
• 必要な修正の詳細。レビュアーが修正方法を指定している場合は、「レビュアーの提案どおりに実装する」。
• 以下の修正品質契約。サブエージェントを使用する場合は、各サブエージェントへのプロンプトにそのまま記載してください。

修正品質契約（各修正に適用）

You are fixing one code review finding. Hard requirements:

1. Make the fix. Do not defer. Do not declare anything out of scope.
   Do not call anything pre-existing. If you discover the fix needs to
   touch adjacent code to be correct, touch it.

2. The fix must be clean and architectural — idiomatic for the language
   and the file's surrounding patterns. Read enough of the
   surrounding module to match its conventions before editing.
   No inline hacks, no band-aids, no "minimum to make it green".

3. Do NOT over-engineer. No new abstractions, no speculative
   generality, no helper layers, no config knobs. Solve the actual
   reported problem. If three lines are right, write three lines.

4. Write NO comments unless a future reader would be genuinely
   confused without one (a non-obvious invariant, a workaround for a
   specific upstream bug, a hidden constraint). Never write comments
   that restate what the code does. Never write headers, banners,
   "fix:" markers, or "// added for review feedback" notes.
   Excessive comments are a defect — do not produce them.

5. Run the project's typecheck / lint for the file you touched if a
   command is obvious from the repo. Report what you ran.

6. Report back: the resulting diff, the file:line of the change, and
   one sentence on what you changed and why.

サブエージェントに依頼する場合は、特定の分野に特化したサブエージェントが明らかに適している場合を除き、汎用サブエージェントを使用してください。

例

フィードバックファイルのパスを指定して、receive-feedback スキルを呼び出します。

receive-feedback reviews/pr-123-feedback.md

ファイルを読み込み、各項目を検証して、無効／有効の概要を出力し、launch fixes for 1,3,4? と確認します。確認後、項目1、3、4を修正します。対応している場合は3つのサブエージェントを並行して起動し、そうでない場合は同じ契約のもとで3つの修正を順番に行います。

ファイル

• VERIFICATION.md - ツールを使用した検証ワークフロー
• EVALUATION.md - 分類ルール（VALID / INVALID / NEEDS CLARIFICATION）
• RESPONSE.md - 構造化された出力形式
• references/skill-integration.md - コードレビュー用スキルとの連携方法