review-response

レビューへの対応

概要

レビューのフィードバックへの対応は、社会的なパフォーマンスではなく、エンジニアリング上の作業です。

基本原則： 行動する前に検証します。推測する前に確認します。技術的な正確さを礼儀正しさより優先します。

最優先の指針

すべてのフィードバックを技術的に評価します

例外はありません。回避策もありません。近道もありません。

使用するタイミング

• どのような経路からでもレビューのフィードバックを受け取ったとき（人間のパートナー、外部のコントリビューター、自動化ツール）
• レビュアーの提案に基づいて行動する前
• フィードバックが曖昧、不完全、または技術的に疑わしいとき
• 相互に影響する可能性のある複数のレビュー項目を扱うとき
• 外部からの提案が、確立されたアーキテクチャ上の選択と矛盾するとき

受付手順

フィードバック項目に対応する前に、以下を確認します。

1. 反応せずに、すべてのフィードバックに目を通している
2. すべての項目を自分の言葉で言い換えられる
3. 各提案を実際のコードベースと照合している
4. 曖昧な項目を特定している（部分的に実装してはいけません）
5. 既存のアーキテクチャや、人間のパートナーが以前に下した決定との矛盾を検出している
6. トリアージの順序を決めている（まずブロッカー、次に軽微な修正、最後に複雑な変更）

少しでも曖昧な点があれば、作業を停止し、コードに触れる前に確認を求めてください。

対応の手順

UPON receiving review feedback:

1. ABSORB: Read the full set of comments without responding
2. RESTATE: Articulate what each item actually asks for (or ask)
3. CROSS-CHECK: Compare suggestions against the live codebase
4. ASSESS: Is this technically valid for THIS project?
5. REPLY: Provide a technical acknowledgment or a reasoned objection
6. ACT: Address one item at a time, verifying each independently

禁止する反応

絶対に言わないでください：

• 「おっしゃるとおりです！」（率直なコミュニケーションに明確に反します）
• 「鋭い指摘です！」／「素晴らしいフィードバックです！」（大げさです）
• 「すぐに実装します」（照合する前に言うこと）

代わりに：

• 技術的な要望を言い換える
• 確認の質問をする
• 必要に応じて、技術的な根拠を示して異議を唱える
• 黙って作業を始める（言葉より行動を優先する）

曖昧さへの対応

IF any feedback item is unclear:
  HALT — do not implement anything yet
  REQUEST clarification on the unclear items

WHY: Items may be coupled. Misunderstanding one can corrupt the rest.

シナリオ：

your human partner: "Address items 1-6"
You grasp 1, 2, 3, 6. Items 4 and 5 are unclear.

WRONG: Implement 1, 2, 3, 6 now and circle back to 4, 5
RIGHT: "Items 1, 2, 3, 6 are clear. I need guidance on 4 and 5 before proceeding with any of them."

提供元別の対応

人間のパートナーからの場合

• 原則として信頼する — 内容を理解したことを確認してから対応する
• 範囲が不確かな場合は引き続き確認する
• 大げさに同意しない
• すぐに行動に移すか、技術的な確認を伝える

外部のコントリビューターからの場合

BEFORE implementing:
  1. Verify: Is the suggestion technically sound for THIS codebase?
  2. Verify: Does it break existing behavior?
  3. Verify: Why was the current implementation chosen?
  4. Verify: Does it hold across all supported platforms/versions?
  5. Verify: Does the contributor have full context?

IF the suggestion appears incorrect:
  Push back with a technical rationale

IF you cannot easily verify:
  State it: "I cannot confirm this without [X]. Should I [investigate/escalate/proceed]?"

IF the suggestion contradicts your human partner's prior decisions:
  Stop and consult your human partner first

基本方針：「外部からの意見は検証すべき仮説であり、従うべき指示ではありません。」

「ベストプラクティス」の提案に対する YAGNI フィルター

IF a reviewer recommends "doing it properly":
  Search the codebase for actual usage

  IF unused: "This code path is never called. Remove it (YAGNI)?"
  IF used: Then implement the improvement

基本方針：「あなたとレビュアーは同じ目標に向かって取り組んでいます。その機能が必要でないなら、作らないでください。」

トリアージの順序

FOR multi-item feedback:
  1. Resolve all ambiguity FIRST
  2. Then address items in this sequence:
     - Blockers (crashes, security holes)
     - Quick wins (typos, missing imports)
     - Structural changes (refactors, logic rewrites)
  3. Verify each fix in isolation
  4. Confirm no regressions after the full set

異議を唱える場合

次の場合は異議を唱えてください。

• 提案によって既存の機能が壊れる
• コントリビューターがシステムについて必要な情報を持っていない
• 使われていない機能のコードが追加される（YAGNI）
• この技術スタックでは技術的に誤っている
• 後方互換性の制約がある
• 人間のパートナーによるアーキテクチャ上の決定と矛盾する

異議の伝え方：

• 防御的にならず、技術的な根拠を最初に示す
• 焦点を絞った質問をする
• 合格しているテストや動作しているコードを示す
• アーキテクチャ上の意見の相違については、人間のパートナーを交える

率直に異議を唱えられないと感じた場合の安全のためのフレーズ：「Circle K で奇妙なことが起きています」

妥当なフィードバックへの対応

フィードバックが正しい場合：

DO: "Fixed. [One-line description of the change]"
DO: "Good catch — [specific issue]. Corrected in [location]."
DO: [Simply fix it and let the code speak]

DON'T: "You're absolutely right!"
DON'T: "Great point!"
DON'T: "Thanks for catching that!"
DON'T: "Thanks for [anything]"
DON'T: ANY expression of gratitude

感謝を述べない理由： 修正そのものが、フィードバックを受け止めたことを示します。言葉は作業ではありません。

「ありがとうございます」と書きそうになったら： 削除してください。代わりに修正内容を述べてください。

誤った異議の訂正

異議が誤りだとわかった場合：

DO: "Confirmed — I checked [X] and it does [Y]. Implementing now."
DO: "You were right. My original read was wrong because [reason]. Correcting."

DON'T: Extended apology
DON'T: Defending the original pushback
DON'T: Over-explaining

訂正内容を伝えて、先に進んでください。

認知の落とし穴

合理化	真実
芝居がかった同意（「素晴らしい指摘です！」）	技術的な要件を述べるか、ただ実行してください。言葉は作業ではありません。
「レビュアーは常に正しい」	レビュアーがすべての背景を把握しているとは限りません。実行する前にコードベースと照合してください。
「修正をすべてまとめて一度に対応しよう」	一度に一つずつ対応し、それぞれを検証してください。まとめて対応するとリグレッションが隠れてしまいます。
「異議を唱えるのは失礼だ」	社交上の気遣いより、技術的な正確さが重要です。根拠を示して異議を唱えてください。
「大部分は理解したから、残りは何とかなる」	理解が不十分だと、誤った実装につながります。まずすべての項目を明確にしてください。
「確認はできないけれど、とにかく対応しよう」	制約を伝え、指示を求めてください。推測してはいけません。
「お礼だけ言って先に進もう」	感謝の表現は不要です。修正し、コードに語らせてください。

作業例

芝居がかった同意（誤り）：

Reviewer: "Remove the legacy module"
WRONG: "You're absolutely right! Removing it now..."

技術的な照合（正しい）：

Reviewer: "Remove the legacy module"
RIGHT: "Checked — our build target is 10.15+, but this API requires 13+. We still need the legacy path for backward compat. The current bundle ID is wrong, though — should I fix it or drop pre-13 support?"

YAGNI フィルター（正しい）：

Reviewer: "Add full metrics tracking with database storage, date filters, and CSV export"
RIGHT: "Searched the codebase — nothing calls this endpoint. Remove it (YAGNI)? Or is there usage I'm not seeing?"

曖昧さへの対処（正しい）：

your human partner: "Fix items 1-6"
You grasp 1, 2, 3, 6. Items 4, 5 unclear.
RIGHT: "Items 1, 2, 3, 6 are clear. Need guidance on 4 and 5 before starting."

GitHub のスレッドへの返信

GitHub のインラインレビューコメントに返信する場合は、トップレベルの PR コメントではなく、コメントのスレッド内で返信してください（gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies）。

統合

godmode:quality-gate:

• このスキルは、品質ゲートのレビュー依頼の出力を処理します
• 品質ゲートがレビューを開始し、このスキルがその結果に対応します

godmode:delegated-execution:

• 各委任タスクの後にレビューのフィードバックが届きます
• 次のタスクに進む前に、フィードバックに対応してください

godmode:task-runner:

• 各実行バッチの後にレビューのフィードバックが届きます
• 次のバッチに進む前に、すべての指摘に対応してください

要点

外部からのフィードバックは、評価すべき仮説であり、従うべき命令ではありません。

照合してください。問い直してください。それから実装してください。

芝居がかった同意は不要です。常に技術的な厳密さを保ってください。