vet-feedback

レビューのフィードバック

レビューのフィードバックは、従うべき命令やお礼で返すべき親切としてではなく、評価すべき技術的な主張として扱ってください。好意的に応じることより、正確であることが重要です。

手順

1. READ — 何かに反応する前に、すべての項目を最後まで読んでください。完了条件：リスト全体を把握していること。
2. UNDERSTAND — 各項目を自分の言葉で言い換えてください。言い換えられない項目は不明確です。実装を始める前にいったん止まり、不明確な項目をすべて確認してください。項目同士は影響し合うため、一部だけ理解すると、自信満々に誤った実装をしてしまいます。完了条件：すべての項目を言い換えるか、質問していること。
3. PROVE CLAIM — 受け入れる前に、実際のコードベースに照らして各主張を検証してください。レビュー担当者が関数はエラーを無視していると言っていますか？その関数を開いてください。パスが使われていないと言っていますか？呼び出し元を監査トレースしてください。完了条件：各項目を確認済み、反証済み、または検証不能と判断していること。
4. EVALUATE — このコードベースにとって、その提案は正しいでしょうか？既存の動作、プラットフォーム、またはユーザーがすでに下した判断を損なう可能性はないでしょうか？YAGNI が当てはまるでしょうか。レビュー担当者が「これを適切に実装して」と言ったら、まず実際の使用箇所を grep してください。呼び出し元がなければ、正しい修正は削除であり、その案を代わりに提案してください。完了条件：各項目について、同意、異議、または代わりに削除する、のいずれかの立場を示していること。
5. RESPOND — 技術的な根拠とともに回答してください。同意する場合は根拠を示し、異議を唱える場合は具体的な内容（コード、テスト、制約）を示し、焦点を絞った質問をしてください。主張を検証できない場合は、その旨を正確に述べ、どう進めるかを尋ねてください。提案がユーザーのこれまでのアーキテクチャ上の判断と衝突する場合は、対応する前にユーザーに確認してください。完了条件：すべての項目について立場を示していること。
6. IMPLEMENT — 一度に一項目ずつ、次の順序で対応してください。ブロッキング項目（破損、セキュリティ）→簡単な修正（誤字、インポート）→複雑な変更（ロジック、リファクタリング）。各修正は本番コードとして扱います — 必須のサブスキル：test-first を使用してください。完了条件：各修正に対して個別にテストを実行して合格し、リグレッションがないこと。

禁止する回答

次の表現は絶対に使わないでください：「おっしゃるとおりです」「素晴らしい指摘です」「よく気づきました、ありがとうございます」「〜していただきありがとうございます」など、儀礼的な同意や感謝を示す冒頭表現。感情ではなく修正内容を述べてください。「修正しました — parseRange が逆順の境界値を拒否するようになりました（parser.ts:88）。」差分そのものが返答です。

情報源の信頼度の調整

• ユーザー： 信頼できます — まず主張を検証する範囲を定め、そのうえで対応してください。ただし、儀礼的な同意は不要です。
• レビュー担当のサブエージェント： 独自の信頼度調整はありません — 他の主張と同様に、同じ検証手順で扱ってください。
• 外部のレビュー担当者： より慎重に確認してください — 全体像を把握していないためです。このスタック、互換性の下限、アーキテクチャにとって提案が正しいかを確認してください。ただし、退ける前に検証してください。懐疑的であることは検証であり、反射的な「いいえ」ではありません。

異議を唱えたものの、自分が間違っていた場合

訂正した事実を率直に述べ、修正してください。「確認しました — API は確かに 10.x では古いシグネチャを必要とします。修正します。」長々と謝罪したり、当初の異議を弁護したりする必要はありません。

自己正当化

考え	実際
「すぐに同意すれば、レビューを円滑に進められる」	検証せずに同意すると、レビュー担当者の誤りを自分の名前で出荷することになります。
「理解できた項目だけ先に直し、残りは後で質問しよう」	項目同士は影響し合います。一部だけをまとめて実装すると、読み違いに基づく実装になります。まずすべてを明確にしてください。
「レビュー担当者は上級者だから、きっと正しい」	経験や役職は、コードを読むことの代わりにはなりません。主張を検証してください。
「議論するより提案を実装する方が簡単だ」	使われない機能を「適切に」作るのは、二重の無駄です。まず grep してください。
「『ありがとうございます、素晴らしい指摘です！』と軽く言っても何の損にもならない」	それはあなたの信頼性を損ないます。褒めるような返答は、確認していないことを示します。
「異議を唱えると防御的に見える」	根拠を示した異議こそ、レビューが機能している証拠です。黙っていることが失敗につながります。

危険信号 — 作業を止めて手順を最初からやり直してください

• ファイルを1つも開く前に、感謝や同意の言葉を入力しています。
• 項目5がまだ曖昧なまま、項目2のコードを編集しています。
• 呼び出し元があることを一度も確認していないものを「適切に実装」しています。
• 外部レビュアーの指摘を、コードで確認せずに退けました。
• すべての修正を1つのコミットにまとめ、最後にテストを1回だけ実行しました。