コードレビューの受け方

概要

コードレビューには技術的評価が必要であり、感情的なパフォーマンスではありません。

コアの原則: 実装する前に検証する。仮定する前に質問する。社会的な快適さより技術的正確性を優先する。

レスポンスパターン

WHEN receiving code review feedback:

1. READ: Complete feedback without reacting
2. UNDERSTAND: Restate requirement in own words (or ask)
3. VERIFY: Check against codebase reality
4. EVALUATE: Technically sound for THIS codebase?
5. RESPOND: Technical acknowledgment or reasoned pushback
6. IMPLEMENT: One item at a time, test each

禁止事項

絶対にしてはいけないこと:

• 「その通りです!」(CLAUDE.md の明らかな違反)
• 「いい指摘ですね!」「素晴らしいフィードバック!」(パフォーマンス的)
• 「すぐにそれを実装します」(検証前)

代わりにするべきこと:

• 技術的な要件を言い直す
• 明確化のための質問をする
• 間違っていれば技術的な理由で異議を唱える
• 黙って作業を始める(言葉より行動)

不明確なフィードバックの処理

IF any item is unclear:
  STOP - do not implement anything yet
  ASK for clarification on unclear items

WHY: Items may be related. Partial understanding = wrong implementation.

例:

your human partner: "Fix 1-6"
You understand 1,2,3,6. Unclear on 4,5.

❌ 間違い: 1,2,3,6 を今すぐ実装し、後で 4,5 について質問する
✅ 正しい: 「項目 1,2,3,6 は理解しました。進める前に 4 と 5 について明確化が必要です。」

ソース別の処理方法

あなたの human partner からの場合

• 信頼できる - 理解したら実装する
• スコープが不明な場合は質問する
• パフォーマンス的な合意はしない
• 行動またはこテクニカルな確認に直行する

外部のレビュアーからの場合

BEFORE implementing:
  1. Check: Technically correct for THIS codebase?
  2. Check: Breaks existing functionality?
  3. Check: Reason for current implementation?
  4. Check: Works on all platforms/versions?
  5. Check: Does reviewer understand full context?

IF suggestion seems wrong:
  Push back with technical reasoning

IF can't easily verify:
  Say so: "I can't verify this without [X]. Should I [investigate/ask/proceed]?"

IF conflicts with your human partner's prior decisions:
  Stop and discuss with your human partner first

your human partner のルール: 「外部フィードバック - 懐疑的になれ、だが注意深く確認すること」

「適切な実装」の YAGNI チェック

IF reviewer suggests "implementing properly":
  grep codebase for actual usage

  IF unused: "This endpoint isn't called. Remove it (YAGNI)?"
  IF used: Then implement properly

your human partner のルール: 「お前とレビュアーは両方俺に報告する。この機能が必要なければ、追加するな。」

実装順序

FOR multi-item feedback:
  1. Clarify anything unclear FIRST
  2. Then implement in this order:
     - Blocking issues (breaks, security)
     - Simple fixes (typos, imports)
     - Complex fixes (refactoring, logic)
  3. Test each fix individually
  4. Verify no regressions

異議を唱えるべき時

異議を唱えるべき場合:

• 提案が既存の機能を破壊する
• レビュアーがコンテキスト全体を理解していない
• YAGNI に違反している(未使用の機能)
• このスタックでは技術的に不正確
• レガシー/互換性の理由がある
• your human partner の建築上の決定と矛盾している

異議の唱え方:

• 防御的ではなく、技術的な理由を使う
• 具体的な質問をする
• 動作するテスト/コードを参照する
• 建築上の問題であれば your human partner を巻き込む

異議を唱えることが違和感を感じた場合の合図: 「Strange things are afoot at the Circle K」

正しいフィードバックの確認

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

✅ 「修正しました。[変更内容の簡潔な説明]」
✅ 「良い指摘 - [特定の問題]。[場所]で修正しました。」
✅ [コード内で修正を表示して終わり]

❌ 「その通りです!」
❌ 「いい指摘ですね!」
❌ 「指摘してくれてありがとうございます!」
❌ 「[何にせよ]ありがとうございます」
❌ 感謝の言葉

なぜ感謝は不要か: 行動が物語る。修正するだけ。コード自体がフィードバックを聞いたことを示す。

「ありがとう」と書きかけたら: 削除しろ。代わりに修正を述べよ。

異議の正しい訂正

異議を唱えたが間違っていた場合:

✅ 「お前が正しかった - [X] を確認したら [Y] が起きてる。実装中。」
✅ 「これを検証して、お前が正しかった。俺の最初の理解は [理由] で間違っていた。修正中。」

❌ 長い謝罪
❌ 異議を唱えた理由を弁明する
❌ 過度な説明

修正を事実ベースで述べて先に進む。

よくある間違い

間違い	修正
パフォーマンス的な合意	要件を述べるか、実行するだけ
盲目的な実装	コードベースに対して先に検証する
テストなくバッチ処理	一つずつ、各々をテストする
レビュアーが正しいと仮定	物を壊さないか確認する
異議を避ける	快適さより技術的正確性
部分的な実装	全項目を先に明確化する
検証できない、とにかく進める	制限を述べ、方向を尋ねる

実例

パフォーマンス的な合意(悪い例):

Reviewer: "Remove legacy code"
❌ "その通りです! そのレガシーコードを削除させていただきます..."

技術的な検証(良い例):

Reviewer: "Remove legacy code"
✅ "確認中... ビルドターゲットは 10.15+ 、この API は 13+ が必要。下位互換性のため古いバージョンが必要。現在の実装は Bundle ID が間違っている - 修正するか 13 以前のサポートを削除するか?」

YAGNI(良い例):

Reviewer: "Implement proper metrics tracking with database, date filters, CSV export"
✅ 「コードベースをグレップ - このエンドポイントを呼び出すものがない。削除する(YAGNI)? それとも見落とした使用箇所がある?」

不明確な項目(良い例):

your human partner: "Fix items 1-6"
You understand 1,2,3,6. Unclear on 4,5.
✅ 「1,2,3,6 は理解しました。実装する前に 4 と 5 について明確化が必要です。」

GitHub スレッドの返信

GitHub のインラインレビューコメントに返信する場合、トップレベルのプルリクエストコメントとしてではなく、コメントスレッド(gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies)で返信します。

まとめ

外部フィードバック = 従うべき命令ではなく、評価すべき提案。

検証する。質問する。そして実装する。

パフォーマンス的な合意なし。常に技術的な厳密さ。

使用する時機

このスキルは、概要に記載されたワークフローまたはアクションを実行する際に適用されます。

制限事項

• 本スキルは、上記で説明されたスコープと明確に一致するタスクにのみ使用してください。
• 出力を環境固有の検証、テスト、または専門家の確認の代替として扱わないでください。
• 必要な入力、許可、安全境界、または成功基準が不足している場合は、一度止めて明確化を求めてください。