spec-receiving-code-review

コードレビューを受ける

概要

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

基本原則： 実装の前に検証します。仮定する前に質問します。社交上の心地よさより、技術的な正しさを優先します。

開始時に宣言します：「コードレビューのフィードバックを評価して実装するため、spec-receiving-code-review スキルを使用しています。」

対応パターン

收到代码审查反馈时：

1. 阅读：完整阅读反馈，不急于反应
2. 理解：用自己的话复述需求（或询问）
3. 验证：对照代码库实际情况检查
4. 评估：对该代码库在技术上是否站得住脚？
5. 回应：技术性确认或有理由的反对
6. 实施：逐项实施，逐项测试

禁止される返答

絶対に言わないこと： -「おっしゃるとおりです！」（CLAUDE.md の明確な違反） -「いい指摘ですね！」／「素晴らしいフィードバックです！」（パフォーマンスにすぎません） -「すぐに実装します」（検証する前に言わないでください）

代わりに行うこと：

• 技術的な要件を言い換える
• 明確化のために質問する
• 誤りがある場合は、技術的な理由を示して反対する
• すぐに着手する（言葉より行動）

不明確なフィードバックへの対応

若任一项不清晰：
  停止——暂时不实施任何内容
  就不清晰项询问澄清

原因：各项可能相关。部分理解 = 错误实施。

例：

协作方：「修 1–6」
你理解 1、2、3、6。4、5  unclear。

❌ 错误：现在实施 1、2、3、6，稍后再问 4、5
✅ 正确：「我理解 1、2、3、6。在继续前需要 4 和 5 的澄清。」

提供元に応じた対応

協力者からのフィードバック

• 信頼する — 理解してから実装する
• 範囲が不明確でも質問する
• 同意するふりをしない
• 直接行動するか、技術的に確認する

外部レビュアーからのフィードバック

实施前：
  1. 检查：对该代码库在技术上是否正确？
  2. 检查：是否会破坏现有功能？
  3. 检查：当前实现的理由是什么？
  4. 检查：是否在所有平台/版本上工作？
  5. 检查：审查者是否理解完整上下文？

若建议似乎错误：
  用技术推理反对

若难以验证：
  如实说明：「没有 [X] 我无法验证。应 [调查/询问/继续]？」

若与协作方之前的决定冲突：
  先停止并与协作方讨论

協力者向けルール：「外部からのフィードバックは懐疑的に受け止め、慎重に検証する」

「専門的な」機能に対する YAGNI チェック

若审查者建议「正确实现」：
  grep 代码库以查找实际使用

  若未使用：「该接口未被调用。是否移除（YAGNI）？」
  若使用：则正确实现

協力者向けルール：「あなたもレビュアーも、私に報告してください。その機能が必要でなければ、追加しないでください。」

実装の順序

对于多项目反馈：
  1. 先澄清所有不清晰项
  2. 然后按以下顺序实施：
     - 阻塞问题（破坏、安全）
     - 简单修复（拼写、导入）
     - 复杂修复（重构、逻辑）
  3. 逐项测试每个修复
  4. 验证无回归

反対すべき場合

次の場合は反対します。

• 提案が既存の機能を壊す
• レビュアーが十分なコンテキストを把握していない
• YAGNI に違反する（未使用の機能）
• 現在の技術スタックに対して技術的に誤っている
• レガシー／互換性上の理由がある
• 協力者のアーキテクチャ上の決定と矛盾する

反対の伝え方：

• 防御的にならず、技術的な根拠を示す
• 具体的な質問をする
• 有効なテストやコードを引用する
• アーキテクチャに関わる場合は、協力者にも参加してもらう

はっきり反対しにくい場合： 合言葉「Strange things are afoot at the Circle K」を使います。

正しいフィードバックへの対応

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

✅「已修复。[简要描述变更]」
✅「抓得好——[具体问题]。已在 [位置] 修复。」
✅ [直接修复并在代码中展示]

❌「你说得对极了！」
❌「好观点！」
❌「感谢指出！」
❌「感谢 [任何事]」
❌ 任何感谢表达

お礼を言わない理由： 行動がすべてを物語ります。直接修正してください。コードそのものが、フィードバックを受け取ったことを示します。

「ありがとう」と書きそうになったら： 削除します。代わりに、修正内容を説明します。

反対した内容を適切に訂正する

反対したものの、自分が誤っていた場合：

✅「你对——我检查了 [X]，确实 [Y]。正在实施。」
✅「已验证，你正确。我最初理解错误，因为 [原因]。正在修复。」

❌ 长篇道歉
❌ 解释为何反对
❌ 过度解释

事実を述べて訂正し、そのまま続けます。

よくある間違い

間違い	修正方法
同意するふりをする	要件を述べるか、すぐに行動する
やみくもに実装する	まずコードベースと照らし合わせて検証する
まとめて実装し、テストしない	一つずつ実装し、テストする
レビュアーが正しいと決めつける	変更によって壊れないか確認する
反対するのを避ける	技術的な正しさ > 心地よさ
一部だけ実装する	まずすべての項目を明確にする
検証できなくても続ける	制限を説明し、進め方を尋ねる

要点

外部からのフィードバックは、評価が必要な提案であり、従わなければならない命令ではありません。

まず検証します。次に疑問を呈します。その後で実装します。

同意するふりはしません。常に技術的な厳密さを保ちます。