receive-review

レビューを受ける

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

手順

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

禁止する返答

「おっしゃるとおりです」「素晴らしい指摘です」「よく気づきました、ありがとうございます」「〜してくれてありがとうございます」など、感謝や同意を大げさに表す書き出しは決して使わないでください。感情ではなく、修正内容を述べてください。「修正しました — parseRange が逆順の境界値を拒否するようになりました（parser.ts:88）。」と伝えます。差分が返答になります。

情報源に応じた判断

• ユーザー： 信頼します — 範囲を確認してから行動します。ただし、感情的な同意は示しません。
• レビュアーのサブエージェント： 独自の信頼度調整はしません — 他の主張と同じように扱い、同じ検証手順を適用します。
• 外部のレビュアー： 文脈を十分に把握していないため、より慎重に確認します。このスタック、互換性の下限、アーキテクチャに照らして提案が正しいか確認してください。ただし、退ける前に検証してください。懐疑的であることは検証であり、反射的な「いいえ」ではありません。

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

訂正を明確に述べて修正してください。「確認しました — おっしゃるとおり、10.x では API に古いシグネチャが必要です。修正します。」長々と謝罪したり、最初に異議を唱えたことを弁護したりしないでください。

自分に言い聞かせがちなこと

考え	実際
「すぐ同意すれば、レビューを円滑に進められる」	検証していない同意は、レビュアーの誤りを自分の名前で取り込むことになります。
「理解できた項目を修正して、残りは後で質問しよう」	項目同士は影響し合います。一部だけをまとめて実装すると、誤解に基づいた修正になります。
「レビュアーは経験豊富だから、正しいはずだ」	経験はコードを読むことの代わりにはなりません。検証してください。
「議論するより、提案を実装するほうが簡単だ」	使われていない機能を「適切に」作るのは、二重の無駄です。まず grep してください。
「『ありがとうございます、素晴らしい指摘です！』と一言添えても損はない」	信頼を損ないます。称賛めいた返答は、確認していないという印象を与えます。
「異議を唱えると防御的に見える」	根拠を伴う異議は、レビューが機能している証拠です。何も言わないことが問題です。

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

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