mcpField
R
reviewing-code

reviewing-code

github.com/bostonaholicテスト・品質263 回インストール今日更新
リポジトリ

reviewing-code について

reviewing-codeは、指定されたコード差分を独立した読み取り専用のレビュアーが確認するスキルです。対象の解決、指摘の検証、判定形式、プルリクエストへのレビュー投稿手順を定めています。

主な機能

  1. 01対象を具体的な参照またはパスに解決
  2. 02ファイル編集権限のない新規コンテキストでレビュー
  3. 03再利用する指摘を現在のヘッドで検証
  4. 04判定形式を確認し一度だけ再試行
  5. 05プルリクエストに指摘と判定を投稿

活用シーン

  1. 01プルリクエストやブランチ差分のレビュー
  2. 02変更を再レビューし過去の指摘を検証
  3. 03インラインコメントでコードの指摘を報告

インストール

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

$npx skills add https://github.com/bostonaholic/skills --skill reviewing-code

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

agents/
openai.yaml
references/
code-reviewer.md
shared/
code-comments.md
code-standards.md
docs-vs-code.md
findings.md
independent-review.md
testing.md

詳細

コードレビュー

対象

  • リクエストでは、PR 番号または URL、ブランチ、コミット範囲、パスのいずれかで差分を指定します。
  • 会話内にすでにある差分は、その取得元の参照先に解決します。解決できない場合は、テキストとしてそのまま渡します。
  • 対象が指定されていない場合は、作業ツリーとベースブランチとの差分が対象です。
  • ベースとヘッドの具体的な参照先(またはパス)に一度だけ解決し、それをレビュアーに渡します。ユーザーに対象の再提示を求めてはいけません。

レビュアー

  • このセッションには作成者との会話が含まれるため、ここで作業をレビューすることはできません(独立レビューのルール)。
  • コードレビュアー向けブリーフを、新しいコンテキストのサブエージェントで実行します。この会話をフォークしたものは使わず、ファイル編集ツールを持たないサブエージェントを使用します。
  • 渡すのは、解決済みの対象、再レビューの入力、ブリーフのパス、およびブリーフからリンクされているファイルのパスだけです:指摘の形式、テストのルール、コード標準、コードコメントのルール、ドキュメントとコードのルール。
  • シェルを使用できる場合、実行できるのはプロジェクトのテストコマンドと読み取り専用の Git コマンドのみです。
  • そのようなサブエージェントを実行できない場合は、そこで停止して、その旨を伝えます。インラインでレビューしてはいけません。

再利用された指摘

  • 外部レビュアーは、後続のコミット後も指摘を再利用できます。
  • 再利用した指摘を現時点のものとして報告する前に、新しいコンテキストの読み取り専用検証者(この会話をフォークしたものは不可)に、解決済みのヘッドに照らして指摘の挙動に関する主張を確認させます。
  • 主張と引用されたパスを渡し、以前の判定や指摘者の説明は渡しません。
  • 古いパーマリンクだけでは、懸念事項が修正されたことの証明にはなりません。
  • 検証結果は別途報告します。キャッシュされた判定を使って新しいコミットを承認したり、元の判定を書き換えたりしてはいけません。

判定

  • レポートの1行目は、**Verdict: ...** の形式でなければなりません。判定語は APPROVE、REQUEST CHANGES、COMMENT のいずれかと完全一致させます(絵文字ではなく単語を照合します)。
  • 判定が欠落している、または誤っている場合は、同じ入力で新しいレビュアーを1人実行し、満たされなかった要件を示します。
  • 2回目のレポートも要件を満たさない場合は、そのレポートを出力し、失敗した要件を示して停止します。自分で判定を修正してはいけません。また、投稿もしてはいけません。

投稿

  • 対象がプルリクエスト、またはヘッドにオープンなプルリクエストがあるブランチの場合は、ユーザーに確認せず投稿します。
  • ### Checks に記載されたレビュー対象のヘッド SHA に対して、判定をイベントとしてレビューを1件投稿します。イベントは APPROVE、REQUEST_CHANGES、COMMENT のいずれかです。gh を使う場合は、commit_id、event、body、comments を指定して gh api repos/<owner>/<repo>/pulls/<n>/reviews を実行します。
  • file:line が差分内にある各指摘は、その行にインラインコメントとして投稿し、本文には指摘をそのまま記載します。レビュー本文には、レポートの ### Summary と、差分内の行に紐付けられないすべての指摘を含めます。
  • 再レビューでは、今回新たに見つかった指摘だけをインライン投稿します。本文には、未解決のまま残っている以前の指摘を列挙します。
  • GitHub は、閲覧者本人のプルリクエストに対する APPROVE と REQUEST_CHANGES を拒否します。その場合は COMMENT を投稿し、本文には判定語を残します。
  • 投稿に失敗した場合は、エラーの原因に一度だけ対処します(拒否されたコメントを本文に移すなど)。そのうえで再試行します。再試行も失敗した場合は、レポート全体とエラーを出力します。

出力

これだけを正確に出力し、レポートのそれ以外の内容は出力しないでください。

**Verdict: <✅ APPROVE | ❌ REQUEST CHANGES | 💬 COMMENT>**

<3 to 5 sentences: what was reviewed and at which short SHA; the finding count, blocking count, and the most serious finding; the test result; the review URL, or why nothing was posted.>
  • 何も投稿していない場合は、レポートの ### Findings セクションをサマリーの後に追加します。指摘はほかに記載されないためです。
  • 再利用された指摘を検証した場合は、判定とは分けて、その検証結果をサマリーの後に追加します。
  • レビュアーが標準外の見出しを使用した場合、または読み取り専用の制限がツールの権限ではなくプロンプトに基づいていた場合は、サマリーに1文で記載します。

再レビュー

  • この会話内のこのスキルに関する以前のレポートが同じ PR またはブランチを対象としている場合に限り、対象は再レビューとなります。作業ツリーまたは貼り付けられた差分を対象とする場合は該当しません。
  • 最も新しい該当レポートの ### Checks に記載された head SHA、その指摘事項、ラウンド番号をレビュー担当者に渡します。ラウンド番号は、該当する以前のレポート数に 1 を加えた数です。
  • 記録された head がない場合は、その理由を伝えたうえで完全なレビューを実行します。

コメント