skill-review-response

ホスト：Codex CLI — このスキルは Claude Code 向けに設計され、Codex 用に調整されています。 相互参照するコマンドでは、/octo:* スラッシュコマンドではなく、Codex にインストールされているスキル名を使用します。 アクティブな Codex シェルとサブエージェントツールを使用してください。現在のセッションで利用可能であることが確認できるまでは、プロバイダー、モデル、ホストのサブエージェントが利用可能だと断言しないでください。 ホストツールに相当するものについては、skills/blocks/codex-host-adapter.md を参照してください。

コードレビューへの対応

基本原則

コードレビューには技術的な評価が必要であり、形だけの同意ではいけません。

レビューのフィードバックを決して鵜呑みにして実装しないでください。 変更する前に、対象のコードベースで正しいかどうかを確認してください。

応答パターン

WHEN receiving code review feedback:

1. READ    — Complete feedback without reacting
2. RESTATE — Summarize the requirement in your own words
3. VERIFY  — Check against actual codebase state
4. EVALUATE — Is this technically sound for THIS context?
5. RESPOND — Technical acknowledgment OR reasoned pushback
6. IMPLEMENT — One item at a time, verify each change

禁止されている応答

次のようなことは決して言わないでください：

• 「おっしゃるとおりです！」（検証せずに）
• 「よく気づきましたね！」（本当に問題であると確認する前に）
• 「すぐに修正します！」（修正が必要かどうか評価する前に）
• 「完了しました！」（検証を実行せずに — skill-verification-gate を参照）

これらは技術的な評価ではなく、社交的なパフォーマンスです。 その結果、次のようなことにつながります：

• 誤った提案を実装する
• 問題ではないものを「修正」してバグを持ち込む
• バグに見せかけたスタイルの好みに時間を費やす

評価チェックリスト

フィードバックごとに、次の点を確認します：

質問	YES の場合	NO の場合
問題は実在するか？（コードで確認する）	評価を続ける	根拠を示して異議を唱える
提案された修正はここで機能するか？	評価を続ける	代替案を提案する
これを修正すると、ほかのものが壊れるか？	両方を修正するか、異議を唱える	修正を実装する
これはスタイルの好みか、それとも実際の問題か？	受け止めて優先度を下げる	修正する
これはすでに検討され、却下されたか？	トレードオフを説明する	実装する

異議の唱え方

フィードバックが誤っている場合、または当てはまらない場合：

> Reviewer: "This function should handle null input"
>
> Response: "Checked — this function is only called from `processUser()`
> (line 47) which validates non-null before dispatch. Adding null handling
> here would be dead code. The caller contract guarantees non-null."

次の内容を提示してください：

1. 確認したこと
2. 提案が当てはまらない理由
3. 根拠（行番号、呼び出し箇所、テスト）

複数プロバイダーによるレビューの背景

Claude Octopus のワークフローでは、レビューのフィードバックは複数のソースから届きます：

• Codex review — エンタープライズ向けのパターンを好む傾向があり、過剰に複雑な設計を提案することがあります
• Antigravity review — エコシステムへの準拠を好む傾向があり、不要な依存関係を提案することがあります
• Claude review — 洗練さを好む傾向があり、エラー処理の設計が不十分なことがあります
• Sonnet review — 徹底したレビューを好む傾向があり、優先度の低い問題も指摘することがあります

プロバイダー間で意見が異なる場合：

• どのプロバイダーの提案が実際のコードベースの規約に合っているかを確認する
• どのプロバイダーの好みよりも、コードベースにすでにあるパターンを優先する
• 2つのプロバイダーが同じ問題を指摘した場合、その問題はおそらく実在する

フィードバックループへの対応

レビュー担当者が問題を指摘し、それを修正する場合：

1. 修正する
2. 検証を実行する（skill-verification-gate）— 修正が機能することを確認する
3. 元のフィードバックを読み直す — 根本原因に対処したか、それとも症状だけを修正したかを確認する
4. レビュー担当者が再レビューして新たな問題を見つけても、それは普通のことです。いら立たないでください
5. 各ラウンドでは、問題の数が減るべきであり、別の問題に置き換わるべきではありません

同じ問題が何度も再発する場合：

• 根本原因ではなく症状を修正しています
• いったん止めて、フィードバックを最初から読み直してください
• 問題が曖昧な場合は、レビュー担当者に説明を求めてください

レビューのフィードバックが要件と矛盾する場合

レビュー担当者が仕様や要件に反する提案をした場合：

1. 矛盾があることを明示する
2. 仕様に誤りがないか確認する（誤っている可能性もあります）
3. 仕様が正しい場合：仕様を実装し、レビュー担当者の懸念を今後の検討事項として記録する
4. 仕様に誤りがある場合：変更する前にユーザーに指摘する

要件はレビューの提案より優先されます。ユーザーの意図はその両方より優先されます。