名称: phx:pr-review 描述: 处理PR审查评论 — 获取、分类、起草响应，可选地修复代码。当PR有审查者反馈需要处理时使用。参数提示: <PR编号或URL> [–fix] 禁用模型调用: true

PR审查响应

获取PR审查评论，将其分类，起草响应，并可选地应用代码修复。

使用方式

/phx:pr-review 42              # 处理PR #42的评论
/phx:pr-review 42 --fix        # 处理评论 + 应用代码修复
/phx:pr-review https://...     # 完整URL也可使用

参数

$ARGUMENTS = PR编号（或URL），可选后跟 --fix。

工作流程

步骤 1: 获取PR上下文

# 获取PR元数据
gh pr view {number} --json title,body,state,baseRefName,headRefName

# 获取所有审查评论（行内 + 常规）
gh api repos/{owner}/{repo}/pulls/{number}/comments --paginate
gh api repos/{owner}/{repo}/pulls/{number}/reviews --paginate

# 获取差异以供上下文
gh pr diff {number}

从 $ARGUMENTS 解析PR编号。如果是URL，从中提取编号。检测 --fix 标志。

步骤 2: 分类评论

将每个评论分组到以下类别之一：

类别	信号	操作
代码更改	“应该改为”、“更改为”、“使用X代替”	起草修复 + 响应
问题	“为什么”、“如果”、“如何做”	起草解释
细枝末节	“nit:”、仅样式、格式化	快速确认
表扬	“很好”、“好”、“LGTM”	无需操作
讨论	架构、权衡、替代方案	起草深思熟虑的响应

步骤 3: 映射到代码位置

对于每个代码更改评论：

从评论的 path 和 position 找到文件和行号
读取该位置的当前代码
在上下文中理解审查者的建议
检查建议是否与铁律冲突

步骤 4: 起草响应

对于每个评论，按照 references/response-patterns.md 中的模式起草响应。

将所有草稿响应呈现给用户审查：

## PR #{number}: {title}
### {n} 条评论需处理

**代码更改 ({n}):**
1. {file}:{line} — {reviewer suggestion} → {proposed fix}

**问题 ({n}):**
1. {question summary} → {draft answer}

**细枝末节 ({n}):**
1. {nit} → 已确认

**讨论 ({n}):**
1. {topic} → {draft response}

步骤 5: 应用修复（如果 --fix）

如果提供 --fix 标志且用户批准：

应用已批准的代码更改响应中的代码更改
运行 mix compile --warnings-as-errors && mix test
如果测试通过，呈现更改
不要提交或推送 — 留给用户处理

步骤 6: 发布响应（经用户批准）

停止并请用户审查所有草稿响应。

用户批准后（可能会编辑一些）：

# 将每个响应作为对原始评论的回复发布
gh api repos/{owner}/{repo}/pulls/{number}/comments/{id}/replies \
  -f body="{response}"

铁律

绝不自动发布响应 — 始终显示草稿并获得明确批准
绝不驳回审查 — 只有审查者可以驳回
铁律优先于审查者建议 — 如果审查者建议违反铁律的代码，在响应中解释原因
保持响应建设性 — 确认反馈，解释推理
分离修复和响应 — 在单独步骤中应用代码更改

集成

PR收到审查评论
       ↓
/phx:pr-review {number}  ← 你在此处
       ↓
   修复代码？ → --fix标志应用更改
       ↓
   发布响应（用户批准后）
       ↓
   推送更改 → 用户处理git推送

参考

references/response-patterns.md — 响应模板和常见模式

名称: phx:pr-review 描述: 处理PR审查评论 — 获取、分类、起草响应，可选地修复代码。当PR有审查者反馈需要处理时使用。 参数提示: <PR编号或URL> [–fix] 禁用模型调用: true