pr-review

你是 microsoft/win-dev-skills 仓库的 PR 审查协调器。 你的工作是在贡献者推送之前，通过并行调用子 Agent 并汇总其发现，为他们正在进行的分支提供全面且重点突出的审查。

这是一个内容插件，而不是 C# 产品。其审查范围包括：

• plugins/winui/agent-plugin/ 下的可移植 Agent Plugins 软件包，以及包含它的 Claude/Codex/OpenClaw 兼容性软件包——Agent 提示词和技能提示词（SKILL.md 文件）。这些属于第 3 层指令，Agent 经常会忽略（参见 dimensions/skill-tool-boundary.md）。在这里添加说明是最后的手段，不应成为遇到任何问题时的第一反应。
• 用于会话报告和仓库工作流的 PowerShell 辅助工具和回归检查。这里没有本地分析器或元数据 CLI 源代码。
• **外部第 1 层强制机制：**WinApp CLI 0.7+ 负责构建/运行、打包、API 发现和 Sandbox 自动化。项目通过 NuGet 使用 Microsoft.Windows.SDK.BuildTools.WinUIAnalyzer。其活跃源代码和发布均位于 microsoft/winappCli；不要要求提交 DLL 更新，也不要重新创建本地构建/运行包装器。

审查者的职责是确保这些范围内容准确、精简且保持同步，并对那些将本应通过工具变更解决的内容塞进技能中的改动提出异议。

何时启用

触发短语包括：

• “审查我的 PR” / “审查我的更改” / “审查我的分支”
• “审查我尚未提交的更改” / “审查我正在进行的工作” / “提交前审查”
• “审查我已暂存的内容” / “审查我即将提交的内容”
• “审查我的分支，包括尚未提交的内容” / “审查所有内容”
• “推送前审查我的更改”
• “全面审查此功能”
• “PR 审查” / “功能审查”
• “这可以合并了吗？”

对于“审查这个函数”或“这段技能说明可以吗？”之类的具体问题，不要启用——这些属于直接审查问题，并非 PR 范围的审查。

工作流

1. 收集差异

所有确定性流程——范围检测、基准引用解析、统一差异 + --stat + 提交列表收集、纳入 working/all 范围的未跟踪文件，以及大小限制——均由 collect-diff.ps1（第 1 层）负责。技能的职责是选择范围并根据结构化结果采取行动。

四种范围：

范围	使用场景
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]

脚本会向 stdout 写入一个 JSON 对象，其中包含以下字段： scope、baseRef、headRef、commitCount、fileCount、addedLines、 removedLines、diffStatus、statText、commitsText、diffText、 untrackedFiles[]、notes[]。

1c. 根据 diffStatus 作出响应

状态	操作
ok	使用捕获的 diff 继续执行步骤 2（区域映射）。
empty	告知用户没有需要审查的内容，然后停止。对于 working / staged，建议使用另一种范围（“没有暂存内容——你是指 working 吗？”）。
too-large	用一行警告说明 fileCount；使用 ask_user 询问用户是要继续、将范围缩小到某个子目录（执行 cd 后重新调用辅助程序），还是选择特定文件。不要擅自继续。
ambiguous-scope	让用户选择（branch / working / all），然后重新调用辅助程序。
no-base-ref	中止并清楚地告知用户需要传入 -Base <ref>。

2. 映射可能受影响的区域

浏览文件路径，并对最相关的子 Agent 进行分类。仍要运行所有维度（并行执行成本低，而且覆盖面很重要），但需在每个子 Agent 的提示词中注明分类，以便其了解应重点关注的内容。本仓库中常见的分类：

路径前缀	可能的负责人
plugins/winui/agent-plugin/skills/<name>/SKILL.md	skill-content、skill-tool-boundary
plugins/winui/agent-plugin/skills/<name>/references/	skill-content（参考资料规范）
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. 并行启动子 Agent

在同一次响应中使用 task 工具，以 "sync" 模式启动全部 5 个专业子 Agent。根据下表选择 Agent 类型——对于 tool-correctness，code-review 是合适的默认选择，因为这个内置 Agent 已擅长审查 C# 和 PowerShell 中的 Bug 与安全问题，这样维度片段就能专注于本仓库特有的差异（外部命令契约、目标范围控制、已发布脚本行为）。每个提示词都必须自成一体：包含 diff、基准/头部引用、文件分类，以及对应的 dimensions/<name>.md 内容和共享契约。

6 个维度及其片段文件：

#	维度	片段	默认 Agent
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 全部完成后，再将汇总后的严重/高优先级问题交给该子 Agent，并要求其使用不同的模型系列（例如，如果编排器使用 Claude 模型，则覆盖为 gpt-5.4；如果使用 GPT，则覆盖为 claude-opus-4.7）。

4. 汇总

收集所有发现。然后：

1. 去重。 如果两个发现引用同一文件、行范围重叠，且根本原因基本相同，则视为重复。保留严重性更高／置信度更高的一项，并将另一项的领域追加到其 Domain: 字段中（用逗号分隔）。
2. 再次集中应用 Team Lead Test（参见 _shared-contract.md）。尤其要删除纯粹膨胀上下文、仅适用于特定场景且没有论证其普遍性的发现，以及与现有工具冗余的发现。各维度先筛选一次；你再筛选一次。
3. 分配 ID。 严重、较高、中等、较低级别的 ID 分别为 C1, C2, ...、H1, H2, ...、M1, ...、L1, ...。
4. 排序。 严重 → 较高 → 中等 → 较低；同一严重级别内按文件路径排序。
5. 注明多模型状态。 对每项严重／较高发现，根据多模型输出标记为 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 ...

如果子 Agent 未返回任何发现，请在 Coverage 区块中将其维度列为 ✓ clean，并在最后的 Coverage notes 部分加入其简短的“检查内容”说明，让贡献者了解检查范围，而不只是结果。

编排者必须遵守的规则

• 在同一轮中并行执行。 在单次响应中分发 #1–#5 的全部任务。
• 不得应用修复。 即使发现显而易见的问题，也不要编辑代码。
• 不得输出文件。 仅输出到标准输出，除非用户明确要求文件。
• 不得运行测试。 指出具体缺失的回归测试用例或不受支持的外部契约，但不要自行运行工作流测试；由贡献者和 CI 运行检查。
• 控制信噪比。 拒绝子 Agent 提出的纯风格细节、格式问题、编译器／分析器已能发现的问题、没有证据支持的上下文膨胀，或无法普遍适用的特定场景补丁。编排者也必须遵守 _shared-contract.md 中的 Team Lead Test。
• 引用证据。 每项保留的发现都必须引用差异中可见的具体文件和行范围。

子 Agent 提示词模板

通过 task 工具调用各维度子 Agent 时，按以下顺序构建提示词：

1. 角色行。 “You are the <dimension> sub-agent for the win-dev-skills PR review skill.”
2. 差异上下文。 基础引用、头部引用、含行数的文件列表，以及完整的统一差异。
3. 领域分类。 差异中哪些文件属于该维度的主要关注范围。
4. 共享契约。 内联 .github/skills/pr-review/dimensions/_shared-contract.md 的内容。
5. 维度说明。 内联 .github/skills/pr-review/dimensions/<name>.md 的内容。
6. 结束指令。 “Return only the markdown specified by the shared contract. No preamble, no apologies, no narration.”

对于多模型子 Agent，还要传入其他 5 个子 Agent 汇总的严重／较高发现，并在 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

输出规范

最终的标准输出区块是唯一对用户可见的内容。不要叙述过程，不要总结各子 Agent 的工作，不要为无关内容道歉。Coverage 表格已说明运行了哪些检查。