code-review-checklist

コードレビュー用チェックリストスキル

特定のプルリクエスト向けに、言語、変更の種類、リスクレベルに応じたコードレビュー用チェックリストを作成します。汎用テンプレートではありません。

これとは少し違いますか？ チェックリストだけでなく、シニアエンジニアの視点でレビューそのものを実施したい場合は、code-review-guide を使用してください。

必須入力

与えられた情報をもとに作業してください。以下の項目に不足がある場合でも、完全な出力を作成してください。不足している情報は、妥当な仮定で補い、(仮定、要確認) と記して、最後に仮定の一覧を記載してください。質問を先にするのは、中心となる題材そのものがない場合（書く内容が何もない場合）に限ります。

• 言語とフレームワーク（例：TypeScript + React / Python + FastAPI / Go）
• 変更の種類（機能追加 / バグ修正 / リファクタリング / 依存関係のアップグレード / セキュリティパッチ / パフォーマンス改善）
• リスクレベル（低 / 中 / 高 / 重大）
• PR の説明（説明文を貼り付けるか、PR へのリンクを記載してください）
• コードまたは差分（任意 — 変更した主要ファイルまたは git diff を貼り付けてください。チェックリストの具体性が大幅に向上します）
• 作成者の背景（新人 / 経験豊富 / 外部コントリビューター）

出力形式

---

コードレビュー：［PR のタイトルまたは参照先］

1. PR の概要

スコープの評価： ［小 / 中 / 大 / 大きすぎる — 分割すべき］ 推奨するレビューの深さ： ［ざっと確認 / 標準 / 詳細レビュー］ 推定レビュー時間： ［例：20～30 分 — 目安として差分 50 行につき 5 分で計算してください］

2. 正確性の確認

言語に応じた正確性の確認 — 指定された言語に基づいて選択してください。

TypeScript/JavaScript の場合：

• 型定義が実際の使用方法と一致している
• テストコード以外で暗黙の any を使用していない
• async/await を一貫して使用し、未処理の Promise がない
• null/undefined を明示的に処理している

Python の場合：

• 公開関数に型ヒントがある
• 例外処理が具体的である（裸の except を使用していない）
• リソースがクローズされている（コンテキストマネージャー、with ブロック）

Go の場合：

• エラーを処理しているか、コメントを付けて明示的に無視している
• コンテキストの伝播が正しい
• ゴルーチンのライフタイムに上限がある

［指定された言語に該当するセクションのみを含めてください］

3. 変更の種類に応じた確認

バグ修正の場合：

• このバグを検出できるテストがある
• 症状だけでなく根本原因に対処している
• 同じ問題がないか、関連するコードパスも確認している

機能追加の場合：

• 受け入れ条件を満たしている
• エッジケース（空、大量、並行処理）に対応している
• 正常系だけでなく、エラー時の処理もテストしている
• デバッグ用のテレメトリー／ログを追加している

リファクタリングの場合：

• 挙動が変わっていない（テストが引き続き成功する）
• スコープが広がっていない — リファクタリングのみである
• 複雑さを別の場所に移すだけでなく、削減している

依存関係のアップグレードの場合：

• 破壊的変更を確認している
• セキュリティ勧告を確認している
• ライセンスの互換性を検証している

［指定された変更の種類に該当するセクションのみを含めてください］

4. リスクに応じた確認

低リスク： 基本的な正確性、スタイル規約、テストカバレッジ 中リスク： 上記に加えて、ロールバック計画、監視の更新、パフォーマンス上の考慮事項 高リスク： 上記に加えて、セキュリティへの影響、データ移行の安全性、フィーチャーフラグ／段階的なロールアウト 重大なリスク： 上記に加えて、ステージング環境での検証計画、インシデント対応計画、デプロイ後の確認チェックリスト

5. テストの妥当性

• ユニットテストで新しいロジックを網羅している
• 統合テストで契約の変更を網羅している
• エッジケースをテストしている
• 失敗時の動作をテストしている
• パフォーマンスが重要な場合は、パフォーマンステストを実施している

6. レビューの判断基準

承認する条件： ［この PR に基づく具体的な条件を 2～3 件］ 変更を依頼する条件： ［具体的なブロッカー］ コメント（マージをブロックしない）： ［議論する価値はあるが、マージを妨げない項目］

7. この変更の種類でよくある落とし穴

変更の種類と言語に基づき、この組み合わせでレビュアーが見落としがちな点を 2～3 件挙げてください。

---

詳細資料

このスキルにはサポートファイルが含まれています。利用可能な場合は使用してください。

• references/review-depth-calibration.md — レビューの深さの調整：すべての PR に同じ注意を払う必要はありません。出力の作成時に適用してください。このファイルには、上記の手法の概要で簡略化されている調整基準と判断基準が記載されています。
• templates/review-record.md — 品質ゲートがインラインで記載された、記入式の成果物テンプレートです。生成してもらうのではなく、ユーザー自身でドキュメントを作成したい場合に提示してください。

スコアリング基準（0～40）

このスキルの出力は、提出前にスコアを付けてください。32 点以上が出荷可能な品質です。

項目	0	5	10
言語への特化度	どの言語にも当てはまるチェック項目で、言語名を入れ替えても何も変わりません	適切な言語ブロックが選ばれていますが、チェック項目はこの PR の構造ではなくテンプレートを言い換えています	すべての正確性チェックで、差分に実際に含まれる構造（goroutine、promise チェーン、コンテキストマネージャーなど）を挙げています
リスクに応じた深さの調整	リスクレベルの申告にかかわらず、深さが同じです	深さはおおむねリスクに応じていますが、高リスク向けの追加項目（ロールバック計画、段階的なロールアウト、モニタリング）が不足しているか、形式的なものにとどまっています	深さが申告されたリスクに正確に対応し、レビュー時間の見積もりも差分サイズのガイドに沿っています
判断基準の明確さ	「問題なさそうなら承認する」となっています。条件が明示されていません	ブロッカーは挙げられていますが、検証できないため、レビュアーが条件を満たしたか判断できません	承認・ブロック・コメントの各条件が、特定のテスト、フラグ、メトリクス、または成果物に照らして検証できます
落とし穴の具体性	落とし穴がないか、「バグに注意」のように一般的です	落とし穴が言語または変更の種類には合っていますが、その両方を踏まえていません	この言語と変更の種類の組み合わせに特有の落とし穴を 2～3 個挙げています

品質チェック

• チェックリストが申告された言語に合わせて調整されている（一般的な内容ではない）
• 変更の種類に特化したセクションが含まれている
• リスクに応じた深さが、申告されたリスクレベルに合っている
• 判断基準に、明示されたブロック条件と、明示された非ブロックのコメント条件がそれぞれ少なくとも 1 つ含まれている
• よくある落とし穴が、申告された言語と変更の種類の組み合わせに特有である（「バグに注意」のような一般的な助言ではない）

アンチパターン

• 申告された言語を無視した一般的なチェックリストを生成しないでください。Python と Go のチェックリストでは、正確性に関わる懸念事項が根本的に異なります。
• 「問題なさそう」を有効なレビュー結果として扱わないでください。チェックリストの目的は、表面的に目を通したことを確認するのではなく、具体的な懸念事項を明らかにすることです。
• 「高リスク」のレビューを「低リスク」のレビューと同じ範囲にしないでください。深さは申告されたリスクレベルに応じて調整する必要があります。
• スタイル上の好みをすべてブロッカーとして指摘しないでください。ブロック対象となる正確性の問題と、ブロック対象ではないコメントを区別してください。
• 申告された言語と変更の種類の組み合わせに関する「よくある落とし穴」のセクションを省略しないでください。ここに最も価値のある知識が含まれています。

使用例

• 「[PR の説明] のコードレビュー用チェックリストを作成してください」
• 「このプルリクエストでは何を確認すべきですか？」
• 「[言語] の [変更の種類] に関するコードレビュー用チェックリストを作成してください」
• 「[言語] の高リスク PR 用レビューチェックリスト」

トリガーフレーズの例

• 「コードをレビューしてください。」
• 「PR を確認してください。」
• 「プルリクエストをレビューしてください。」
• 「コードレビュー用チェックリストを作成してください。」