mcpField
C
code-review

code-review

github.com/pipecat-aiテスト・品質16.9k41 回インストール今日更新
リポジトリ

code-review について

GitHubのプルリクエストを対象に、確度の高いバグとCLAUDE.mdへの準拠を確認するスキルです。複数のエージェントでレビューし、候補を検証したうえで、確認済みの問題だけを行内コメントにします。

主な機能

  1. 01PRのレビュー要否を確認
  2. 02CLAUDE.mdへの準拠を監査
  3. 03並行してバグをレビュー
  4. 04候補の問題を検証
  5. 05確認済みの行内コメントを投稿

活用シーン

  1. 01プルリクエストの明確なバグを確認
  2. 02変更が適用対象のCLAUDE.mdルールに沿うか確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/pipecat-ai/pipecat --skill code-review

インストール後、Claude Code で/code-reviewを入力して読み込まれたか確認します。

詳細

指定されたプルリクエストのコードレビューを行ってください。

エージェントの前提条件（すべてのエージェントとサブエージェントに適用）：

  • すべてのツールは正常に動作し、エラーなく使用できます。ツールをテストしたり、探索目的で呼び出したりしないでください。起動するすべてのサブエージェントに、この点を必ず明確に伝えてください。
  • タスクの完了に必要な場合に限り、ツールを呼び出してください。すべてのツール呼び出しには明確な目的が必要です。

以下の手順に正確に従ってください。

  1. haiku エージェントを起動し、次のいずれかに該当するか確認します。

    • プルリクエストがクローズされている
    • プルリクエストがドラフトである
    • プルリクエストにコードレビューが不要である（例：自動生成された PR、明らかに問題のない軽微な変更）
    • Claude がすでにこの PR にコメントしている（Claude が残したコメントについては gh pr view <PR> --comments を確認してください）

    いずれかに該当する場合は、そこで停止し、先に進まないでください。

注：Claude が生成した PR もレビューしてください。

  1. haiku エージェントを起動し、関連するすべての CLAUDE.md ファイルのファイルパス（内容ではなく）を一覧で返すよう依頼します。対象は次のとおりです。

    • ルートの CLAUDE.md ファイル（存在する場合）
    • プルリクエストで変更されたファイルを含むディレクトリ内の CLAUDE.md ファイル

  2. sonnet エージェントを起動し、プルリクエストを確認して変更内容の要約を返すよう依頼します。

  3. 変更内容を個別にレビューする4つのエージェントを並列で起動します。各エージェントは、各問題の説明と、問題として指摘した理由（例：「CLAUDE.md の遵守」「バグ」）を含む問題一覧を返します。各エージェントの担当は次のとおりです。

    エージェント1および2：CLAUDE.md 遵守を確認する sonnet エージェント CLAUDE.md の遵守状況を並列で監査します。注：あるファイルについて CLAUDE.md の遵守状況を評価する場合、そのファイルとパスを共有するファイル、またはその親ディレクトリにある CLAUDE.md ファイルのみを考慮してください。

    エージェント3：Opus バグ検出エージェント（エージェント4と並列で実行） 明らかなバグを調べます。追加のコンテキストは読まず、差分のみを対象にしてください。重大なバグのみを指摘し、細かな指摘や、誤検知の可能性が高いものは無視してください。Git の差分以外のコンテキストを確認しなければ検証できない問題は指摘しないでください。

    エージェント4：Opus バグ検出エージェント（エージェント3と並列で実行） 追加されたコードに存在する問題を調べます。セキュリティ上の問題やロジックの誤りなどが対象です。変更されたコードの範囲内にある問題のみを調べてください。

    重要：求めるのは、確度の高い問題のみです。 次の条件を満たす問題を指摘してください。

    • コードのコンパイルまたは解析に失敗する（構文エラー、型エラー、インポート漏れ、参照先の未解決など）
    • 入力にかかわらず、明らかに誤った結果が必ず生成される（明確なロジックエラー）
    • 違反している正確なルールを引用できる、明白で曖昧さのない CLAUDE.md 違反

    次のような指摘はしないでください。

    • コードスタイルや品質に関する懸念
    • 特定の入力や状態に依存する可能性がある問題
    • 主観的な提案や改善案

    問題が実在すると確信できない場合は、指摘しないでください。誤検知は信頼を損ない、レビュー担当者の時間を浪費します。

    さらに、各サブエージェントに PR のタイトルと説明を伝えてください。これにより、作成者の意図を把握できます。

  4. 前の手順でエージェント3と4が見つけた問題ごとに、問題を検証するサブエージェントを並列で起動します。これらのサブエージェントには、問題の説明に加えて PR のタイトルと説明も伝えてください。各エージェントは、指摘された問題が確度の高い本当の問題であることを検証します。たとえば、「変数が定義されていない」という問題が指摘された場合、実際にコード内でその変数が未定義であることを検証します。CLAUDE.md に関する問題の場合は、そのルールが対象ファイルに適用され、実際に違反していることを検証します。バグやロジックの問題には Opus サブエージェントを、CLAUDE.md 違反には sonnet エージェントを使用してください。

  5. 手順5で検証されなかった問題はすべて除外してください。この手順で、レビュー対象となる確度の高い問題一覧を作成します。

  6. 問題が見つかった場合は、コメントを投稿する手順8に進んでください。 問題が見つからなかった場合は、--comment 引数が指定されていれば、gh pr comment を使用して概要コメントを投稿します。 "No issues found. Checked for bugs and CLAUDE.md compliance."

  7. 投稿する予定のコメントをすべてリストアップします。これは、コメントの内容に問題がないことを確認するためだけに使用します。このリストをどこにも投稿しないでください。

  8. 各問題について、インラインコメントを gh pr review で投稿します。各コメントでは、以下を守ってください。

    • 問題を簡潔に説明します。
    • 小規模で自己完結した修正の場合は、コミット可能な提案ブロックを含めます。
    • 大規模な修正（6 行以上、構造の変更、または複数箇所にまたがる変更）の場合は、提案ブロックを含めずに、問題と推奨する修正を説明します。
    • 提案を適用するだけで問題が完全に解決する場合を除き、コミット可能な提案を投稿しないでください。追加の対応が必要な場合は、コミット可能な提案を投稿しないでください。

    重要：同じ問題についてコメントを複数投稿しないでください。

ステップ 4 と 5 で問題を評価する際は、以下のリストを参照してください（誤検知として扱い、指摘しないでください）。

  • 既存の問題
  • バグのように見えても、実際には正しいもの
  • シニアエンジニアが指摘しないような、細かな揚げ足取り
  • リンターで検出される問題（確認のためにリンターを実行しないでください）
  • 明示的に CLAUDE.md で求められていない、一般的なコード品質に関する懸念（テストカバレッジ不足や一般的なセキュリティ上の問題など）
  • CLAUDE.md に記載されていても、コード内で明示的に抑制されている問題（リンター無視コメントなど）

注意：

  • GitHub とのやり取りには gh CLI を使用してください（プルリクエストの取得やコメントの作成など）。Web フェッチは使用しないでください。
  • 作業を始める前に、TODO リストを作成してください。
  • インラインコメントでは、問題ごとに引用とリンクを記載してください（例：CLAUDE.md を参照する場合は、リンクを含めてください）。
  • 問題が見つからなかった場合は、次の形式でコメントを投稿してください。

コードレビュー

問題は見つかりませんでした。バグと CLAUDE.md への準拠を確認しました。

  • インラインコメントでコードにリンクする際は、Markdown プレビューが正しく表示されるよう、次の形式を正確に使用してください。https://github.com/OWNER/REPO/blob/FULL_SHA/path/to/file.py#L10-L15
    • 完全な Git SHA が必要です。
    • 完全な SHA を指定してください。https://github.com/owner/repo/blob/$(git rev-parse HEAD)/foo/bar のようなコマンドは使用できません。コメントは Markdown で直接レンダリングされるためです。
    • リポジトリ名は、レビュー対象のリポジトリと一致している必要があります。
    • ファイル名の後に # を付けます。
    • 行範囲は L[start]-L[end] の形式にします。
    • コメント対象の行を中心に、その前後の文脈を少なくとも 1 行ずつ含めてください（例：5～6 行目についてコメントする場合は、L4-7 にリンクします）。

コメント

Markdown 対応