pr-code-review

PR コードレビュー

open-skills 向けのポータブルな PR レビューです。Anthropic Claude Code の code-review プラグインのフロー（適格性、複数の視点、信頼度 ≥80、パーマリンク付きコメント）、mattpocock の Standards∥Spec の分離と固定点の diff、Superpowers の 計画との整合性／重要度／長所を先に示す習慣を組み合わせています。プラットフォームに依存しないエージェントの振り分け（ホストのモデル階層をハードコードしません）。

インストール：npx skills add FuDesign2008/open-skills -g --skill pr-code-review --yes

適用条件

• ユーザーがオープン中の PR/MR のレビューを依頼した場合、または merge-discipline の Part R でマージ前レビューが必要な場合。
• スキップ（理由を伝え、コメントしない）：PR がクローズ済み、ドラフト、些細な変更／自動生成の変更、またはこのセッション／この tip でこのスキルによるレビューがすでに行われている場合。

深度（full | light）

呼び出し元（特に merge-discipline の Part R）は depth=full または depth=light を渡してもかまいません。デフォルト：full。

深度	動作
full	Standards∥Spec の二軸レビュー。ホストがサポートする場合は、複数の視点からのレビューを並行して行うことを推奨します（現在のデフォルトプロセスは以下を参照）。
light	ピン留めした tip に対する Standards∥Spec の二軸レビューは引き続き必須です。複数の視点による並行スウォームは必須ではありません。Critical／Important のクリアランスに対する信頼度 ≥80 と公開ルールに変更はありません。

深度パラメーターを指定しない単独のユーザートリガーでは、必ず full を使用してください。

プロセス

1. 適格性 — オープン中で、ドラフトではなく、レビューが必要であること。このセッションのこの tip ですでにレビューされていないこと。そうでなければ停止します。
2. 深度の解決 — 呼び出し元から指定された full（デフォルト）または light を使用します。
3. 固定点をピン留め — PR/MR のベース ref、ユーザーが指定したコミット／ブランチ、またはマージ候補の場合は origin/<default-branch> を使用します。ref が解決できることを確認し、tip との差分を三点 diff で確認します。差分が空でないことが必要です。差分が空の場合は中止します（視点の展開は行いません）。
4. Spec ソースの解決（最初に見つかったものを使用）：PR／issue の本文とリンクされたチケット → ユーザー指定のパス → OpenSpec の変更差分／関連する openspec/specs → ユーザーに確認 → それ以外は Spec 軸をスキップ（Spec がありません）。
5. Standards ソースの解決 — AGENTS.md／CLAUDE.md（ルートと PR が変更するディレクトリ）に加え、存在する場合はコーディング規約のドキュメントを確認します。任意でコードの問題点に関するベースラインとして reference.md を使用できます（リポジトリのドキュメントが優先されます。問題点の判断には裁量が伴うため、それだけを根拠に重大な違反とはしません）。
6. 要約 — 変更の簡潔な要約（タイトル、意図、差分の形状）。
7. 二軸レビュー（軸をまたいだ統合的な優先順位付けはしません）：
   • Standards 軸 — 文書化されたガイダンスへの違反（ファイルとルールを引用）。任意でコードの問題点に関するヒューリスティックも使用します。
   • Spec 軸 — 計画された動作の欠落／一部のみの実装、正当化されないスコープの拡大、記載された要件の誤った実装（Spec／計画の該当箇所を引用）。Spec ソースがなければ、軸全体をスキップします。
   • full のみ： バグの検出に限定したレビュー、blame／履歴、同じファイルに対する過去の PR コメント、ファイル内コメントのガイダンスなど、複数の視点からのレビューも優先します。
   • light： 必須の並行スウォームはスキップします。単独での二軸レビューで十分です。
8. 調整 — 残った候補ごとに、重要度を Critical／Important／Minor、次に信頼度を 0～100（下記の基準）で評価します。80 未満の評価は除外します。 目安：Critical／Important は検証済みであれば通常 75～100、Minor はガイダンスに明確に違反するものでない限り通常は除外されます。
9. 長所 — あれば、問題点より先に簡潔に列挙します（的確な称賛は、以降の指摘への信頼につながります）。
10. 適格性を再確認 — 公開前に、引き続きオープン中で、同じ tip であることを確認します。
11. 公開 — gh／glab でコメントします（ホストがコメントを禁止している場合は、セッション内で報告します）。コメントには二軸のセクションを含め、完全な SHA のパーマリンクを使用します。テンプレート：reference.md。

信頼度の基準

スコア	意味
0	誤検知／既存の問題／精査に耐えない
25	未検証／スタイル上の問題／ガイダンスに記載なし
50	実際の問題だが、細かなもの、またはまれなもの
75	実際の重要な問題である可能性が高い、またはガイダンス／計画で明示的に要求されている
100	間違いなく実際の問題であり、証拠で確認できる

誤検知として除外するもの

既存の問題、バグに見えるだけのもの、細かすぎる指摘、リンター／型チェッカー／コンパイラーで検出可能なもの、「テスト／ドキュメント／セキュリティをもっと充実させる」といった一般論（ガイダンス／計画で求められている場合を除く）、変更されていない行、意図的なPRの範囲内の動作。

ホスト側の契約（merge-discipline Part R）

• マージ直前のオープンなPR/MRを対象に、Part Rで選択した深度（fullまたはlight）で実行します。
• 合格 → どちらの軸にも、スコアが80以上のCriticalまたはImportantの問題が残っていない状態です（Minorのみ、またはすべてのスコアが80未満であれば合格です）。lightの深度でも、このゲートを緩和してはなりません。
• 不合格 → 呼び出し元に不合格を報告します。修正し、問題がなくなるまで再レビューを続ける（または、ユーザーがPart Rのスキップ／残存リスクの受け入れを明示的に選択し、その記録を残す）役割はmerge-discipline Part Rが担います。指摘を実装しただけでは、Part Rの合格にはなりません。
• CIの成功／カバレッジのスキップは、代わりにはなりません。
• Part Rに合格するために、レビューの受け入れから反映までの一連のプロセスをすべて実施する必要はありません。

フィードバック後（任意の参考情報）

レビューコメント（人間またはこのスキルによるもの）に対応する際は、変更前にコードベースで確認します。形だけの同意はせず、誤りがある場合は技術的な根拠に基づいて異議を唱えます。不明確な点は実装前に確認します。レビューの受け入れから反映までの厳密なプロセスは任意であり、Part Rの範囲外です。

統合ガイド

• merge-disciplineに強く依存します。見つからない場合は、次を実行して中止します。
  npx skills add FuDesign2008/open-skills -g --skill pr-code-review --yes
• 外部で名前が衝突するため、code-reviewに改名しないでください。