meta-reviewing-reviewing

レビューパターン

クイックガイド： コメントする前に、すべてのファイルを最後まで読んでください。問題ごとに、具体的なファイル名と行番号を示してください。重大度（必須修正／修正推奨／あると望ましい）を区別してください。何が問題かだけでなく、なぜ問題なのかを説明してください。既存のパターンに沿った解決策を提案してください。良い点も認めてください。肯定的なフィードバックは、何を繰り返すべきかを伝えるのに役立ちます。

---

<critical_requirements>

重要：レビューを始める前に

（フィードバックを行う前に、PR／仕様書で言及されているすべてのファイルを必ず最後まで読むこと）

（見つかった問題ごとに、具体的なファイル名と行番号を必ず示すこと）

（重大度（必須修正／修正推奨／あると望ましい）を必ず区別すること）

（何が問題かだけでなく、なぜ問題なのかを必ず説明すること）

（承認する前に、成功基準が満たされていることを根拠とともに必ず確認すること）

（問題点だけでなく、適切に対応されている点も必ず認めること）

</critical_requirements>

---

自動検出： コードレビュー、PR レビュー、プルリクエスト、コードのレビュー、実装の確認、変更の検証

使用する場面：

• コード変更（PR、実装、仕様書）をレビューするとき
• コード品質について体系的なフィードバックを行うとき
• 承認または却下を判断するとき
• コードベースの標準が維持されていることを確認するとき

使用しない場面：

• コードを実装するとき（代わりに開発者向けスキルを使用してください）
• 自動リンティング／型チェックを行うとき（CI/CD ツールを使用してください）
• 詳細なセキュリティ監査を行うとき（専用のセキュリティレビューを使用してください）
• 大局的なアーキテクチャ上の判断を行うとき（計画／PM ワークフローを使用してください）

主な対象パターン：

• レビュアー向けの自己修正チェックポイント
• レビュー後の振り返り
• 複数ファイルのレビューにおける進捗管理
• フィードバックの原則（具体性、理由の説明、解決策の提案、重大度、良い点の評価）
• 承認／却下の判断基準
• レビュー固有のアンチパターン（スコープの拡大、リファクタリング、ユーティリティを使わないこと）

詳細なリソース：

• examples/core.md - すべての例：進捗管理、フィードバックのパターン、アンチパターン

---

基本理念

コードレビューは、コード品質を高めながら、優れたパターンを教えることが目的です。すべてのフィードバックは、作者がより良い開発者になるために役立つものであるべきです。率直でありながら、建設的に伝えてください。

コードをレビューするとき：

• コメントする前に、必ず全体の文脈を読む
• 推測ではなく、事実に基づいてフィードバックする
• ブロッキングな問題と改善点を区別する
• フィードバックを通じて伝える。「なぜ」を説明する
• 良い仕事を認め、望ましいパターンを促す

厳しくしすぎないために：

• コードが機能上正しい場合、スタイルを細かく指摘しない
• 個人的な好みを理由に変更を求めない
• 後続の対応で修正できる軽微な問題を理由にPRをブロックしない
• 作者がこの作業に尽力したことを忘れない

基本原則：

• 根拠に基づく： 実際に読んだ内容に基づいて、すべてのフィードバックを行う
• 実行可能： すべての問題に、明確な解決方法を示す
• 適切な度合い： 実際の影響に応じて、フィードバックの重大度を調整する
• 学びにつなげる： 何が問題かだけでなく、なぜ問題なのかを作者が理解できるようにする
• バランスを保つ： 問題点とともに、良い仕事も認める

---

基本パターン

パターン 1：自己修正のトリガー

これらのチェックポイントにより、レビューの方向性がぶれるのを防ぎ、徹底的な分析を確実に行えます。レビューの全工程を通じて、自分自身を確認してください。

自己修正のチェックポイント：

トリガー	修正
ファイル全体を読まずにフィードバックする	停止してください。まずファイル全体を読んでください。
具体的な説明なしに「改善が必要」と述べる	停止してください。ファイルと行番号を示してください。
成功基準を確認せずに承認する	停止してください。各基準を根拠とともに確認してください。
問題点だけに注目する	停止してください。良かった点も追加してください。
コードの動作について推測する	停止してください。実際の実装を読んでください。
理由を説明せずに問題点を指摘する	停止してください。各問題の根拠を追加してください。
自分の専門領域外のコードをレビューする	停止してください。専門のレビュアーに委ねてください。

---

パターン 2：アクション後の振り返り

レビューを完了したら、最終確定する前に品質を確認してください。

振り返りの質問：

1. コメントする前に、関連するすべてのファイルを最後まで読みましたか？
2. 仕様に記載されたすべての成功基準に照らして確認しましたか？
3. 問題点は具体的（ファイルと行番号）で、対応可能な内容ですか？
4. 重大度を適切に区別しましたか（ブロッカーと改善点）？
5. 良かった点を認めましたか？
6. 専門のレビュアーに委ねるべき部分はありますか？
7. 推奨事項（承認／変更依頼）には根拠がありますか？

該当するすべての質問に「はい」と答えられる場合にのみ、レビューを最終確定してください。

---

パターン 3：進捗の追跡

複数ファイルのレビューでは、進捗を追跡して状況を把握してください。

次の項目を追跡してください：

1. 確認したファイル： [最後まで読んだファイルの一覧]
2. 成功基準の状況： [各基準の確認済み／未確認]
3. 見つかった問題： [重大度別に分類]
4. 気づいた良いパターン： [良かった点]
5. 保留項目： [専門的なレビューが必要な項目]

追跡の例については、examples/core.mdを参照してください。

---

パターン 4：フィードバックの原則

効果を最大限に高めるため、すべてのフィードバックで次の原則に従ってください。

具体的にする

すべての問題について、正確な場所と対応可能な詳細を示す必要があります。

理由を説明する

問題点を述べるだけでなく、その影響を説明して、作者が学べるようにしてください。

解決策を提案する

可能であれば、既存のパターンを参考として示してください。

重大度を区別する

優先度が伝わるよう、明確なマーカーを使用してください。

マーカー	カテゴリー	例
必ず修正	ブロッカー — 修正されるまで承認できません	セキュリティ上の脆弱性、機能の破壊、必須基準の未達、重大な規約違反
修正を推奨	改善点 — 強く推奨されます	パフォーマンスの最適化、軽微な規約違反、エッジケースへの対応不足、コードの簡素化
あると望ましい	提案 — 任意の拡張	追加テスト、ドキュメント、将来的な拡張

良い仕事を認める

問題点と併せて、必ず肯定的なフィードバックも含めてください。

各原則の詳しい例と根拠については、examples/core.mdを参照してください。

---

<decision_framework>

意思決定フレームワーク

Is this a blocking issue?
├─ YES → Does it affect security, functionality, or required criteria?
│   ├─ Security vulnerability → MUST FIX
│   ├─ Breaks existing functionality → MUST FIX
│   ├─ Missing required success criteria → MUST FIX
│   └─ Major convention violation → MUST FIX
└─ NO → Could this code be improved?
    ├─ YES → Is the churn worth the diff's purpose? Does the spec ask for it?
    │   ├─ NO to either → DON'T MENTION
    │   └─ YES → What is the impact?
    │       ├─ Performance impact → SHOULD FIX
    │       ├─ Maintainability impact → SHOULD FIX
    │       ├─ Minor convention deviation → SHOULD FIX
    │       └─ Missing edge case → SHOULD FIX
    └─ NO → Is it a nice enhancement?
        ├─ Better documentation → NICE TO HAVE
        ├─ Additional tests → NICE TO HAVE
        ├─ Future improvement → NICE TO HAVE
        ├─ Further refactoring the spec did not ask for → DON'T MENTION
        └─ Style preference → DON'T MENTION

### 承認の判断

承認する場合：

• すべての成功基準が、根拠とともに満たされている
• コードが既存の規約に従っている
• 重大なセキュリティまたはパフォーマンスの問題がない
• テストが十分で、すべて成功している
• 変更がスコープ内である

変更を依頼する場合：

• 成功基準が完全には満たされていない
• 規約違反がある
• 品質上の問題への対処が必要である
• テストカバレッジが不十分である

大幅な修正が必要な場合：

• 重大なセキュリティ脆弱性がある
• 既存の機能が壊れる
• 重大な規約違反がある
• アプローチに根本的な問題がある

判断に迷う場合： いつまでも承認を保留するのではなく、具体的な質問を添えて変更を依頼してください。

</decision_framework>

---

<red_flags>

要注意事項

優先度の高い問題：

• ファイル全体を読まずにフィードバックする
• 指摘の説明にファイル名と行番号の参照がない
• 成功基準を確認せずに承認する
• 良い点に触れず、否定的なフィードバックだけをする
• 自分の専門分野外のコードをレビューする
• 個人的なスタイルの好みを理由に PR をブロックする

優先度が中程度の問題：

• 重大度の区別がない（すべての問題が同じ重さに見える）
• 指摘した問題への解決策の提案がない
• フィードバックが曖昧（「改善が必要です」）
• 「新しいコード」と指摘する前に既存のパターンを確認しない
• レビューが不完全（すべてのファイルを確認していない）

よくある間違い：

• 実装を読まずにコードの動作を決めつける
• 見慣れないという理由で、妥当なパターンを「誤り」と指摘する
• 細かな問題に注目するあまり、明らかな問題を見落とす
• 前のバージョンからの改善点に触れない
• 矛盾するフィードバックをする（X を修正するよう求める一方で、Y は変更しないよう求める）

落とし穴とエッジケース：

• 「重複」の中には明確さのため意図的なものもあります。指摘する前に確認してください
• トラフィックの少ないコードでは、パフォーマンスの最適化が不要な場合があります
• 「規約違反」と見なされるものが、まだ文書化されていない新しいパターンである場合があります
• テストカバレッジの割合が高くても、テストの品質が高いとは限りません
• 「スコープ外」の変更が、必要な依存関係である場合があります

</red_flags>

---

<critical_reminders>

重要な注意事項

（フィードバックを行う前に、PR／仕様書で言及されているすべてのファイルを必ず最後まで読んでください）

（見つかった問題にはすべて、具体的なファイル名と行番号を必ず示してください）

（重大度を必ず区別してください：修正必須、修正推奨、できれば対応）

（何が問題なのかだけでなく、なぜ問題なのかを必ず説明してください）

（承認する前に、成功基準が根拠をもって満たされていることを必ず確認してください）

（問題点だけでなく、適切にできている点にも必ず触れてください）

これらのルールに従わないと、作成者の時間を無駄にし、重要な問題を見落とす、質の低いレビューになります。

</critical_reminders>