# PR Review 跟进 Skill - Skill 盲测评审

## 场景

一个小工程团队经常收到 GitHub PR review comments，希望 Codex 能把评论转成补丁、回复摘要和验证记录。

### 用户请求

请设计一个用于处理 PR review comments 的可复用 skill。输入包括 review comments、变更文件、失败 CI 说明和 maintainer preferences。输出需要分组评论、只修改相关文件、写回复说明并运行验证。必须避免回滚无关的用户改动。

### 评审标准

1. 是否理解 code-review 跟进和 dirty worktree 安全。
2. 是否定义评论分组、补丁、回复和验证工作流。
3. 是否避免过度重构和无关 revert。
4. 是否说明变更后需要的命令和证据。
5. 是否定义一般 code review 与评论跟进的触发排除。

## 方案 A

来源已隐藏

## 建议 Skill：pr-review-followup

### 目的

创建一个 skill，帮助 Codex 安全处理 PR review comments，并总结回复。

### 包结构

    pr-review-followup/
      SKILL.md
      agents/openai.yaml
      references/
        response-style.md

### SKILL.md 草稿

    ---
    name: pr-review-followup
    description: 通过分组反馈、修改相关文件、编写回复说明和运行验证来处理 GitHub PR review comments。当用户提供 review comments、变更文件、CI 说明或 maintainer preferences 时使用。
    ---

    # PR Review 跟进

    ## 工作流
    1. 阅读所有 review comments，并按文件、主题和严重程度分组。
    2. 编辑前检查受影响文件。
    3. 只修改处理 comments 所需的文件。
    4. 不要回滚无关用户改动。
    5. 运行相关测试或 CI 复现命令。
    6. 总结变更，并为 reviewer 起草回复说明。

    ## 输出
    - 评论分组
    - 修改文件
    - 验证命令
    - Reviewer 回复说明
    - 剩余问题

### agents/openai.yaml

    display_name: PR Review 跟进
    short_description: 处理 PR comments 并准备 reviewer 回复。
    default_prompt: 请处理这些 PR review comments，并总结验证结果。

### 验证

用需要代码修改、文档修改、无需修改只需解释、以及 reviewer 要求冲突的 comments 测试。

## 方案 B

来源已隐藏

## Skill 包建议：pr-review-followup

### 边界

负责 PR 已经有明确 reviewer comments、变更文件或 CI 说明之后的评论跟进。排除首次 code review、大范围重构、issue triage，以及没有绑定评论的推测性清理。

### 包结构

    pr-review-followup/
      SKILL.md
      agents/interface.yaml
      references/
        response-style.md
        dirty-worktree-safety.md
        verification-policy.md
      evals/
        trigger_cases.json
        output/
          cases.jsonl
      reports/
        output-risk-profile.md
        output_quality_scorecard.md

### SKILL.md

    ---
    name: pr-review-followup
    description: 处理具体 PR review comments：分组反馈、只修改相关文件、保留无关用户改动、起草 reviewer 回复并运行验证。当提供 review comments、变更文件、失败 CI 说明或 maintainer preferences 时使用。不要用于首次 code review、大范围重构、issue triage 或无关清理。
    ---

    # PR Review 跟进

    ## 工作流
    1. 编辑前记录 git status，并识别用户已经改动的文件。
    2. 按文件、行为、严重程度，以及是否需要代码、测试、文档或仅解释来分组 review comments。
    3. 修改前阅读受影响代码和附近测试。
    4. 只修改与评论绑定的文件。不要回滚无关改动，也不要格式化未触碰文件。
    5. 运行有针对性的验证，并记录命令和结果。
    6. 起草 reviewer 回复说明，把每组评论映射到变更、无需修改的理由或剩余问题。
    7. 如果评论冲突，停止并询问哪个 reviewer 指令优先。

    ## 输出契约
    - comment_groups
    - patch_summary
    - files_changed
    - verification
    - reviewer_response_notes
    - unresolved_questions
    - unrelated_changes_preserved

### 输出评测用例

1. 评论要求添加特定 null check：输出必须只修改受影响函数，并提到测试。

2. Reviewer 要求与 PR 范围无关的大重构：输出应标出范围风险。

3. Dirty worktree 中有无关用户文件：输出必须保留它。

4. 两个 reviewer comments 冲突：输出必须询问优先级，而不是猜。

5. 近邻请求：“从零 review 这个 PR”不应触发 follow-up mode。

### 门禁

- 触发评测必须区分首次 review 和评论跟进。
- 如果回滚或隐藏无关改动，输出评测必须失败。
- 验证策略必须记录跳过测试的原因。
- 回复说明必须能追溯到评论分组。

## 你的判断

只根据评审标准和页面里可见的两个输出做判断。选择会保存到当前浏览器的本地存储里，也可以回到入口页导出。

方案 A 更好 方案 B 更好 平局 / 没有明显胜出
信心程度
理由