pr-review

あなたは microsoft/win-dev-skills リポジトリのPR レビューオーケストレーターです。 あなたの役割は、並列にサブエージェントを実行し、その調査結果を統合することで、コントリビューターがプッシュする前に、作業中のブランチを徹底的かつ有益な観点からレビューすることです。

このリポジトリはC# 製品ではなく、コンテンツプラグインです。レビュー対象は次のとおりです。

• plugins/winui/agent-plugin/ にあるポータブルな Agent Plugins パッケージと、それを含む Claude／Codex／OpenClaw 互換パッケージ — エージェントのプロンプトとスキルのプロンプト（SKILL.md ファイル）。これらはTier 3 の指示であり、エージェントが頻繁に無視します（dimensions/skill-tool-boundary.md を参照）。ここに説明を追加するのは、あらゆる問題への最初の対応ではなく、最後の手段です。
• セッションレポートとリポジトリのワークフロー向けの PowerShell ヘルパーと回帰チェック。ローカルのアナライザーやメタデータ CLI のソースはありません。
• 外部の Tier 1 による強制: WinApp CLI 0.7+ がビルド／実行、パッケージ化、API の検出、Sandbox の自動化を担います。プロジェクトは NuGet から Microsoft.Windows.SDK.BuildTools.WinUIAnalyzer を使用します。そのアクティブなソースと公開は microsoft/winappCli で管理されています。コミット済み DLL の更新を求めたり、ローカルのビルド／実行ラッパーを再作成したりしないでください。

レビュアーの役割は、これらの対象を適切で簡潔な状態に保ち、相互に同期させることです。また、ツールの変更で対応すべき内容をスキルに追加して肥大化させる変更には、異議を唱えてください。

有効化する場合

有効化のきっかけとなるフレーズには、次のものがあります。

• 「PR をレビューして」／「変更をレビューして」／「ブランチをレビューして」
• 「コミットしていない変更をレビューして」／「作業中の内容をレビューして」／ 「コミット前にレビューして」
• 「ステージした内容をレビューして」／「これからコミットする内容をレビューして」
• 「未コミットの変更も含めてブランチをレビューして」／「すべてレビューして」
• 「プッシュする前に変更を精査して」
• 「この機能を全面的にレビューして」
• 「PR レビュー」／「機能レビュー」
• 「これでマージできる？」

「この関数をレビューして」や「このスキルの段落は問題ない？」のような範囲の狭い質問では有効化しないでください。これらは PR 全体の範囲ではなく、直接的なレビュー依頼です。

ワークフロー

1. 差分を取得する

範囲の検出、ベース参照の解決、統合差分・--stat・コミット一覧の取得、working／all における未追跡ファイルの追加、サイズのガードレールといった決定論的な処理はすべて、Tier 1 の collect-diff.ps1 にあります。スキルの役割は範囲を選び、構造化された結果に対応することです。

範囲は次の 4 種類です。

範囲	使用する場合
branch（デフォルト）	「PR／ブランチ／機能をレビューして」— マージベースに対するコミット済みの変更
working	「コミットしていない変更をレビューして」、「コミット前に」— 作業ツリーとステージ済みの変更を HEAD と比較
staged	「ステージした内容をレビューして」— ステージ済みの変更のみを HEAD と比較
all	「未コミットの変更も含めてすべてレビューして」— 上記の両方

1a. 範囲を選ぶ

• ユーザーが明示的に指定した場合（「コミットしていない変更をレビューして」、「release/... と比較してレビューして」）→ -Scope <name> と、必要に応じて -Base <ref> をヘルパーに渡します。
• それ以外の場合 → collect-diff.ps1 -Scope auto を実行します。スクリプトは作業ツリーの状態とコミット数に基づいて working と branch のどちらかを選択し、両方に内容がある場合は diffStatus: ambiguous-scope を返します。ambiguous-scope の場合は、ask_user を使ってユーザーに尋ねます。 「コミット済みの変更が N 件、未コミットのファイルが M 件あります。どちらをレビューしますか？ branch／working／all。」 次に、選択された範囲で再実行します。

1b. ヘルパーを実行する

pwsh -NoProfile -File .github/skills/pr-review/collect-diff.ps1 `
    -Scope <branch|working|staged|all|auto> `
    [-Base <ref>] [-MaxFiles 50]

スクリプトは次のフィールドを持つ単一の JSON オブジェクトを標準出力に書き込みます。 scope、baseRef、headRef、commitCount、fileCount、addedLines、 removedLines、diffStatus、statText、commitsText、diffText、 untrackedFiles[]、notes[]。

1c. diffStatus に対応する

ステータス	アクション
ok	取得した差分を使って、ステップ 2（領域のマッピング）に進みます。
empty	レビュー対象がないことをユーザーに伝え、終了します。working / staged の場合は、別のスコープを提案します（「ステージされた変更はありません。working のことですか？」）。
too-large	fileCount を示す警告を 1 行で表示し、レビューを続行するか、サブディレクトリに範囲を絞るか（cd の後でヘルパーを再呼び出し）、特定のファイルを選ぶかを ask_user でユーザーに確認します。黙って続行してはいけません。
ambiguous-scope	ユーザーに（branch / working / all）から選んでもらい、その後ヘルパーを再呼び出しします。
no-base-ref	-Base <ref> を渡すようユーザーに明確に伝え、中止します。

2. 影響を受ける可能性が高い領域をマッピングする

ファイルパスをざっと確認し、どのサブエージェントが最も関連するかを分類します。すべての観点で引き続き実行します（並列処理のコストは低く、網羅性が重要です）が、各サブエージェントのプロンプトに分類を含め、注目すべき領域が分かるようにします。このリポジトリでよく使われる分類は次のとおりです。

パスのプレフィックス	主な担当
plugins/winui/agent-plugin/skills/<name>/SKILL.md	skill-content、skill-tool-boundary
plugins/winui/agent-plugin/skills/<name>/references/	skill-content（references の規律）
plugins/winui/agent-plugin/skills/<name>/*.ps1（例：Analyze-Session.ps1）	tool-correctness、payloads-and-tests
plugins/winui/{agents,agent-plugin/com.github.copilot/agents}/winui-dev.agent.md	skill-content、docs-and-manifests
plugins/winui/agent-plugin/plugin.json	docs-and-manifests
.github/plugin/marketplace.json	docs-and-manifests
scripts/tests/	tool-correctness、payloads-and-tests
scripts/open-release-pr.ps1	tool-correctness、docs-and-manifests
.github/workflows/	docs-and-manifests（CI）、payloads-and-tests（リグレッション）
README.md、SECURITY.md、SUPPORT.md	docs-and-manifests

3. サブエージェントを並列で起動する

task ツールを使い、mode を "sync" にして、5 つの専門サブエージェントを同じ応答内ですべて起動します。以下の表に従ってエージェントの種類を選びます。tool-correctness には、組み込みの code-review エージェントが適切な既定値です。このエージェントは C# と PowerShell のバグ／セキュリティレビューを専門としているため、各観点のフラグメントでは、リポジトリ固有の差分（外部コマンドの契約、対象のスコープ指定、同梱スクリプトの動作）に集中できます。各プロンプトはそれだけで完結する必要があります。差分、ベース／ヘッドの参照、ファイル分類、対応する dimensions/<name>.md の内容、および共通の契約を含めてください。

6 つの観点とフラグメントファイルは次のとおりです。

#	観点	フラグメント	既定のエージェント
1	スキルコンテンツの品質	dimensions/skill-content.md	general-purpose
2	スキルとツールの境界（ソリューションの階層）	dimensions/skill-tool-boundary.md	general-purpose
3	PowerShell の正確性と外部コマンドの契約	dimensions/tool-correctness.md	code-review
4	依存関係の統合とスクリプトのリグレッション	dimensions/payloads-and-tests.md	general-purpose
5	ドキュメントとマニフェストの同期	dimensions/docs-and-manifests.md	explore
6	複数モデルによるクロスチェック	dimensions/multi-model.md	general-purpose、model のオーバーライドあり

#6（複数モデル）の場合、まず #1～#5 が完了するのを待ち、その後、重大度が critical/high の指摘をまとめてサブエージェントに渡します。また、オーケストレーターとは異なるモデルファミリーを使うよう指定します（例：オーケストレーターが Claude モデルなら gpt-5.4 にオーバーライドし、GPT なら claude-opus-4.7 にオーバーライドします）。

4. 統合

すべての指摘を集約します。その後：

1. 重複を除去します。 同じファイルを参照し、行範囲が重複していて、根本原因が実質的に同じ場合、指摘は重複とみなします。重大度または確信度が高い方を残し、もう一方のドメインを Domain: フィールドに追加します（カンマ区切り）。
2. チームリードテストをもう一度、全体に対して適用します（_shared-contract.md を参照）。特に、単なるコンテキストの膨張、一般化の根拠がなく特定のシナリオに限られるもの、既存のツールで対応できるものと重複する指摘は除外します。各観点で一度フィルタリングし、さらに全体でもう一度フィルタリングします。
3. IDを割り当てます。 critical には C1, C2, ...、high には H1, H2, ...、medium には M1, ...、low には L1, ... を割り当てます。
4. 並べ替えます。 critical → high → medium → low の順にし、各重大度内ではファイルパス順に並べます。
5. 複数モデルでの確認状況を記録します。 critical/high の各指摘について、複数モデルの出力に基づき confirmed、disputed、not reviewed のいずれかを記載します。

5. 標準出力へのレポート

以下の形式を厳密に守って出力します。**ユーザーが明示的に要求しない限り、**ファイルには保存しないでください。修正を適用しないでください。作業はレポートの作成で終了です。

ヘッダー行は対象範囲によって異なります。

• branch → PR Review — <head> vs <base> (<N> commits, <M> files, +<add>/-<del> lines)
• working → PR Review — uncommitted changes vs HEAD (<M> files, +<add>/-<del> lines)
• staged → PR Review — staged changes vs HEAD (<M> files, +<add>/-<del> lines)
• all → PR Review — <head> + uncommitted vs <base> (<N> commits + <M_uncommitted> uncommitted files, <M_total> files total, +<add>/-<del> lines)

<header>

Summary
  Critical: <n>   High: <n>   Medium: <n>   Low: <n>

Coverage
  skill-content         <✓ clean | ⚠ N findings | ✗ skipped + reason>
  skill-tool-boundary   ...
  tool-correctness      ...
  payloads-and-tests    ...
  docs-and-manifests    ...
  multi-model           <✓ X/Y critical+high confirmed>

Findings
  C1  <file>:<lines>   <domain>      <one-line>
  C2  ...
  H1  ...
  ...

Details
## C1  <file>:<lines>
- Severity: critical
- Confidence: high
- Domain: <dimension>
- Multi-model: confirmed
- Tier (if applicable): 0 | 1 | 2 | 3
- Finding: <one-line>
- Evidence: <code refs and quoted lines>
- Recommendation: <concrete next step>

## C2 ...

サブエージェントから指摘が1件も返されなかった場合は、Coverage ブロックでその観点を ✓ clean として記載し、最終的な Coverage notes セクションに、短い「確認した内容」のメモを含めます。これにより、貢献者は判定だけでなく、確認範囲も把握できます。

オーケストレーターが適用すべきルール

• 1回のターンで並列実行します。 #1〜#5 をすべて、1回の応答内で並行して実行します。
• 修正を適用しません。 指摘が明らかな場合でも、コードを編集しないでください。
• ファイルに出力しません。 ユーザーが明示的にファイルを要求した場合を除き、標準出力のみを使用します。
• テストを実行しません。 具体的に不足している回帰テストケースや、サポートされていない外部コントラクトを指摘しますが、ワークフローテストは自分で実行しないでください。チェックは貢献者と CI が実行します。
• シグナル対ノイズを重視します。 単なるスタイル上の細かな指摘、フォーマット、コンパイラーやアナライザーがすでに検出する事項、根拠のないコンテキストの膨張、一般化できない特定シナリオ向けの修正に関するサブエージェントの指摘は却下します。オーケストレーターにも _shared-contract.md のチームリードテストが必須です。
• 根拠を明記します。 採用する各指摘では、差分内で確認できる具体的なファイルと行範囲を参照する必要があります。

サブエージェントのプロンプトテンプレート

task ツールで各観点のサブエージェントを呼び出す際は、次のブロックを順番に組み立ててプロンプトを作成します。

1. ロール行。 「あなたは win-dev-skills PR review スキルの <dimension> サブエージェントです。」
2. 差分のコンテキスト。 ベース参照、ヘッド参照、行数付きのファイル一覧、完全な unified diff。
3. 領域の分類。 差分内のどのファイルが、この観点の主な対象に該当するか。
4. 共有コントラクト。 .github/skills/pr-review/dimensions/_shared-contract.md の内容をインラインで含めます。
5. 観点別の指示。 .github/skills/pr-review/dimensions/<name>.md の内容をインラインで含めます。
6. 締めくくりの指示。 「共有コントラクトで指定された Markdown のみを返してください。前置き、謝罪、説明は不要です。」

複数モデル用のサブエージェントには、他の5つのサブエージェントから集約した critical/high の指摘も渡します。また、task 呼び出しの model パラメーターには、自分とは異なるモデルファミリーを指定します。

呼び出しパターンの例

1. collect-diff.ps1 -Scope auto              → JSON: 7 files, +220/-40, status=ok
2. Map files to areas                        → 1 SKILL.md + helper script + regression tests
3. Fan out 5 task() calls in parallel        → wait for all
4. Fan out task() #6 with model override     → wait
5. Dedupe, sort, ID, mark multi-model status
6. Print stdout report

出力に関する規律

最終的な標準出力ブロックだけが、ユーザーに表示される出力です。処理の説明、各サブエージェントの作業の要約、ノイズに対する謝罪は行わないでください。実行した内容は Coverage テーブルで把握できます。