Critical Code Reviewer

4人の専門家ペルソナによる並列コードレビュー。

API不要

スキルパッケージをダウンロード (.skill) GitHubでソースを見る ワークフロー

目次

概要

Critical Code Reviewer は、ソースコードを 4人の独立した専門家ペルソナ で並列にレビューします。各ペルソナが異なる品質観点に集中し、重大度付きの統合レビューレポートを生成します。

4つのペルソナ:

ペルソナ 焦点 主な問い
ベテランエンジニア (経験20年) 設計判断、アンチパターン、長期保守性 「5年後も保守できるか?」
TDDエキスパート テスト容易性、依存関係管理、リファクタリング安全性 「単独でテストできるか?」
Clean Codeエキスパート 命名、可読性、SOLID原則 「一目で理解できるか?」
バグハンター 状態遷移、例外パス、非同期競合、依存関係の完全性 「本番で壊れないか?」

使用場面

  • PR マージ前に包括的なコードレビューを行いたい場合
  • リファクタリング前に既存コードの設計品質を評価したい場合
  • 状態管理、非同期処理、エラーハンドリングの本番バグを事前に検出したい場合
  • 不慣れなコードベースの品質を把握したい場合
  • 重大度付きの構造化されたレビューレポートが必要な場合

前提条件

  • Claude Code がインストール済みであること
  • critical-code-reviewer スキルが ~/.claude/skills/ にコピー済みであること
  • レビュー対象のソースファイルがワーキングディレクトリからアクセス可能であること

外部 API キーやサービスは不要です。

動作の仕組み

レビューは3つのフェーズで進行します:

Phase 1: 準備
       |
  +---------+---------+---------+
  |         |         |         |
ベテラン   TDD     Clean     バグ
エンジニア Expert  Code      ハンター
  |         |         |         |
  +---------+---------+---------+
       |
Phase 3: 統合レポート

Phase 1: 準備

Claude はペルソナを起動する前にレビュー対象を分析します:

  • 対象の特定 – レビューすべきファイル、ディレクトリ、クラス、関数を決定します。PR レビューの場合は変更ファイルに自動的にスコープを絞ります。
  • 言語の検出 – プログラミング言語を検出し、言語固有のチェックリストを有効化します。Python と JavaScript/TypeScript には追加チェックが適用されます(下記「言語固有チェック」参照)。
  • 依存関係の事前スキャン – 関数内 import を検索し、requirements.txt や pyproject.toml と照合して、不足・未使用の依存関係をフラグします。この情報はバグハンターペルソナに渡されます。
  • コンテキストの収集 – 設計書、既存テストスイート、関連設定ファイルが存在する場合、各ペルソナがプロジェクト固有の規約を参照できるようにロードします。

Phase 2: 並列レビュー

Agent ツールを使って4つのレビューを 同時に 実行します。各エージェントには references/agents/*.md のペルソナプロンプトをインラインで渡し、対象コードと必要なリファレンスを含めます。エージェントは Impact（影響の説明）を出力し、severity は Phase 3 で references/severity_criteria.md を参照して最終判定します。並列実行のため、合計レビュー時間は単一ペルソナの実行時間に近い水準に収まります。

スキルは完全に自己完結しています。全てのペルソナプロンプトが references/agents/ に埋め込まれており、外部のエージェント定義に依存しません。

Phase 3: 統合

Claude が全ての指摘事項を収集し、後処理を行います:

  • 重複排除 – 複数のペルソナが同じ問題を指摘した場合(例: バグハンターとベテランエンジニアの両方が null チェック欠如を指摘)、1つの指摘に統合し、貢献したペルソナを記録します。
  • 重大度の付与 – 各指摘に本番への影響度に基づいて重大度を付与します(下表参照)。
  • レポート生成 – バンドルされたテンプレート(assets/code_review_report_template.md)を使用して構造化された Markdown レポートを生成します。エグゼクティブサマリー、重大度別の指摘事項、ペルソナ別の総評、改善推奨事項が含まれます。

重大度レベル

重大度 定義 例
Critical バグ、データ損失、セキュリティ問題 Nullチェック欠如、リソースリーク
Major 重大な保守性・設計問題 God class、テスト不可能な設計
Minor 改善推奨だが緊急ではない 命名改善、軽微なリファクタリング
Info ベストプラクティス提案 代替アプローチの提示

ペルソナ詳細

各ペルソナはコードに対して異なるレンズを適用します:

ベテランエンジニア(経験20年)

長期的な持続可能性と運用準備状況を評価します。チェック項目:

  • 設計パターンの誤用とアンチパターン(God Object、Shotgun Surgery、Feature Envy)
  • モジュール間の結合度と凝集度のバランス
  • 運用面の懸念: ログ出力、監視フック、グレースフルデグラデーション
  • 後方互換性とマイグレーションの安全性

TDDエキスパート

「テストファースト」の哲学に基づいて評価します。チェック項目:

  • 依存性注入の準備 – 協調オブジェクトをテストダブルに置換可能か?
  • 副作用の分離 – 純粋なロジックと I/O が分離されているか?
  • テスト境界の明確さ – パブリック API が明確に定義されモック可能か?
  • リファクタリング安全性 – 構造変更後も既存テストが機能するか?

Clean Codeエキスパート

可読性と構造的明快さに焦点を当てます。チェック項目:

  • 命名の正確さ – コメントなしで意図が伝わる名前か?
  • 関数の長さと単一責任
  • SOLID原則の遵守(特に SRP、OCP、DIP)
  • コードの重複と抽象化の機会

バグハンター

実行時の障害モードに特化します。チェック項目:

  • 状態遷移 – モジュール間の状態一貫性、孤立状態
  • 例外パス – リソースが開いたままになる、または状態が破損する未処理エラー
  • 依存関係の完全性 – import とマニフェストファイルの宣言済み依存関係の照合
  • 非同期競合状態 – 共有可変状態、ロックの欠如、Promise の解決順序の不定

言語固有チェック

Python

チェック ペルソナが注目するポイント
型ヒント 不足・不正確な型アノテーション、Optional の誤用
Pythonic パターン リスト内包表記、コンテキストマネージャ、ジェネレータ式の活用機会
例外処理 裸の except、過度に広い例外句、エラーの握りつぶし
Import の衛生 関数内 import、循環 import、__init__.py の欠落

JavaScript / TypeScript

チェック ペルソナが注目するポイント
型安全性 (TS) any の乱用、戻り値型の欠落、不正なジェネリクス
非同期パターン 未処理の Promise rejection、並列化可能な逐次 await
this バインディング コールバックやクラスメソッドでのアロー関数と通常関数の誤用
エラー伝播 .catch() チェーンの欠落、try/catch でのエラー握りつぶし

使い方の例

例1: 単一ファイルのレビュー 

このファイルを批判的にレビューしてください: src/services/payment_processor.py

4つのペルソナすべてがファイルに対して実行され、重大度付きのレポートが生成されます。

例2: PRの差分レビュー 

このPRの変更をクリティカルコードレビューしてください。
特に新しい認証モジュールに注目してください。

変更されたファイルにスコープを絞り、差分によって導入されたリスクを指摘します。

例3: バグの集中探索 

src/workers/queue_handler.ts の非同期競合状態と
例外ハンドリングの問題をチェックしてください。

バグハンターペルソナに重点を置きつつ、他のペルソナも知見を提供します。

例4: リファクタリング前の評価 

src/etl/ のデータパイプラインをリファクタリングする予定です。
何を優先的に修正すべきかクリティカルコードレビューを実行してください。

ディレクトリ内の全ファイルをレビューし、問題を重大度で順位付けし、リファクタリング前または最中に対処すべき課題を明示します。

トラブルシューティング

大きなファイルでペルソナの指摘が浅い

症状: 500行を超えるファイルをレビューすると、一部のペルソナが表面的な指摘しか返さない。

解決策: クラスや関数を個別に指定してレビューを分割してください(例: 「checkout.py の PaymentProcessor クラスをレビューして」)。小さく焦点を絞った対象にすることで、各ペルソナがより深く分析できます。

言語固有チェックが適用されない

症状: Python や TypeScript 固有の指摘(型ヒント、非同期パターン)がレポートに含まれない。

解決策: プロンプトで言語を明示してください: 「この Python ファイルを批判的にレビューして」。Claude はファイル拡張子と内容のヒューリスティクスに依存しているため、言語を明示することで専用チェックリストの有効化が確実になります。

ペルソナ間で重複した指摘がある

症状: 統合レポートに異なるペルソナからのほぼ同一の指摘が残っている。

解決策: 指摘が類似しているが異なる表現で記述されている場合に発生します。フォローアップで「重複する指摘を統合して」と依頼するか、簡潔なレポートスタイルを指示してください。

ヒントとベストプラクティス

  • レビュー範囲を絞る – リポジトリ全体ではなく、特定のファイルやディレクトリを指定すると、より集中した結果が得られます。
  • 言語を明示する – 自動検出されない場合は言語を伝えることで、言語固有チェック(Python, JavaScript/TypeScript)が有効になります。
  • テストと組み合わせる – tdd-developer スキルと併用し、レビューで見つかった問題に対してテストを作成できます。
  • 重大度で優先順位付け – Critical と Major はマージ前に修正し、Minor と Info はバックログに回すのが効果的です。

関連スキル

  • TDD Developer – レビューで見つかった問題に対してテストを作成
  • Data Scientist – データ分析・機械学習ワークフロー