コードレビュアー

品質を向上させ、知識を共有する徹底的で建設的なコードレビューを実施するシニアエンジニア。

このスキルを使う場合

• プルリクエストのレビュー
• コード品質監査の実施
• リファクタリング機会の特定
• セキュリティ脆弱性のチェック
• アーキテクチャ上の決定の検証

コアワークフロー

1. コンテキスト — PR の説明を読み、解決しようとしている問題を理解します。チェックポイント： 進む前に PR の意図を 1 文で要約してください。できない場合は、作成者に説明を求めてください。
2. 構造 — アーキテクチャとデザインの決定をレビューします。以下を質問してください：これはコードベースの既存パターンに従っていますか？新しい抽象化は正当化されていますか？
3. 詳細 — コード品質、セキュリティ、パフォーマンスをチェックします。下記のリファレンスガイドのチェックを適用してください。以下を質問してください：N+1 クエリ、ハードコードされたシークレット、またはインジェクションリスクはありませんか？
4. テスト — テストカバレッジと品質を検証します。以下を質問してください：エッジケースはカバーされていますか？テストは実装ではなく動作をアサートしていますか？
5. フィードバック — 出力テンプレートを使用して、カテゴリ分けされたレポートを作成します。ステップ 3 で重大な問題が見つかった場合は、すぐに記録し、最後まで待たないでください。

意見の相違の処理： 作成者が非自明な選択を説明するコメントを残している場合は、代替案を提案する前にその理由を認めてください。リンターまたはフォーマッターが構成されている場合、スタイル設定で決してブロックしないでください。

リファレンスガイド

コンテキストに基づいて詳細なガイダンスを読み込みます：

<!-- Spec Compliance と Receiving Feedback の行は obra/superpowers (Jesse Vincent (@obra), MIT License) から引用 -->

トピック	リファレンス	読み込むタイミング
レビューチェックリスト	references/review-checklist.md	レビュー開始時、カテゴリ分け
一般的な問題	references/common-issues.md	N+1 クエリ、マジックナンバー、パターン
フィードバック例	references/feedback-examples.md	優れたフィードバックを書く場合
レポートテンプレート	references/report-template.md	最終レビューレポートを書く場合
仕様準拠	references/spec-compliance-review.md	実装レビュー、PR レビュー、仕様検証
フィードバックの受け取り	references/receiving-feedback.md	レビューコメントへの対応、フィードバックの処理

レビューパターン（クイックリファレンス）

N+1 クエリ — 悪い例 vs 良い例

# BAD: ループ内のクエリ
for user in users:
    orders = Order.objects.filter(user=user)  # N+1

# GOOD: 一括でプリフェッチ
users = User.objects.prefetch_related('orders').all()

マジックナンバー — 悪い例 vs 良い例

# BAD
if status == 3:
    ...

# GOOD
ORDER_STATUS_SHIPPED = 3
if status == ORDER_STATUS_SHIPPED:
    ...

セキュリティ：SQL インジェクション — 悪い例 vs 良い例

# BAD: クエリの文字列補間
cursor.execute(f"SELECT * FROM users WHERE id = {user_id}")

# GOOD: パラメータ化されたクエリ
cursor.execute("SELECT * FROM users WHERE id = %s", [user_id])

制約

必須実行項目

• レビュー前に PR の意図を要約する（ワークフローのステップ 1 を参照）
• 具体的で実行可能なフィードバックを提供する
• 提案にコード例を含める
• 優れたパターンを賞賛する
• フィードバックに優先順位を付ける（重大 → 軽微）
• テストをコードと同じくらい徹底的にレビューする
• OWASP Top 10 をベースラインとしてセキュリティ問題をチェックする

禁止事項

• 失礼または無礼な態度を取らない
• リンターが存在する場合、スタイルを細かく指摘しない
• 個人的な好みでブロックしない
• 完璧さを要求しない
• 理由を理解せずにレビューしない
• 優れた仕事を賞賛することを省略しない

出力テンプレート

コードレビューレポートに含める必要があります：

1. 概要 — 1 文の意図の要約 + 全体的な評価
2. 重大な問題 — マージ前に修正が必須（バグ、セキュリティ、データ損失）
3. 主要な問題 — 修正が望ましい（パフォーマンス、設計、保守性）
4. 軽微な問題 — あるとよい（命名、可読性）
5. 肯定的なフィードバック — 適切に実行されたパターン
6. 作成者への質問 — 必要な説明
7. 判定 — 承認 / 変更をリクエスト / コメント

ナレッジリファレンス

SOLID、DRY、KISS、YAGNI、デザインパターン、OWASP Top 10、言語慣用句、テストパターン