Dbk Pr Feedback

---
name: dbk-pr-feedback
description: 处理 GitHub PR 收到的他人评审反馈(review comments / review 意见)：逐条核实每条意见是否属实、值不值得修，用户确认后再动手改。当用户让你看、评估、处理某个 GitHub PR 上的评审意见，让你判断某条意见说得对不对、属实吗，提到 reviewer 或 CodeRabbit 等留下的评论，转发粘贴评论内容，或给出 PR 链接时使用——即使用户没有明说"评估"。仅适用于已推送到远端的 PR 上的评审反馈，只做到修复为止，提交、推送与回复评审意见不在范围内；对本地未提交改动做一般性 code review、自查代码质量、创建或合并 PR、排查 CI 失败等任务不适用，勿触发本技能。
compatibility: 需要已安装并登录 gh CLI
license: MIT
metadata:
  author: DBinK
  version: "0.2.0"
---

# PR 评审意见处理

处理 GitHub PR 收到的评审意见。核心纪律：**先评估，再动手**——不马上照单全收别人的意见。

## 工作流

### 1. 拉取评审意见

系统已安装 gh CLI 且已登录。用 gh 拉取指定 PR 的评审意见：

```bash
# 普通 review 评论 + 内联评论
gh api repos/{owner}/{repo}/pulls/{pr_number}/comments
# PR 级普通评论
gh api repos/{owner}/{repo}/issues/{pr_number}/comments
```

如果用户直接粘贴了评论内容或链接，跳过拉取步骤，以用户提供的内容为准。

### 2. 逐条评估

按评论顺序，对每条意见依次回答三个问题：

1. **是否属实** —— 先核实代码事实。评审意见可能是误读、基于旧版本代码、或与项目约定冲突，发现不属实要如实说明，不盲从。
2. **修复价值** —— 属实的话值不值得修？区分：必须修 / 可修可不修 / 不建议修（说明理由）。
3. **修复思路** —— 怎么修？给具体方案而不是空话。

设计层面的分歧（比如架构取舍、两种方案各有道理）：不要替用户拍板，列出选项和利弊让用户决策。

### 3. 写入评估笔记

把评估写入仓库根目录 `./notes/review/` 下（目录不存在则创建）：

- 文件名格式：`<PR编号>-<YYMMDD>-<HHMM>-<简短主题>.md`，例如 `158-260805-1358-something.md`。时间取写笔记时的本地时间，主题用简短小写英文、短横线连接
- 目录里已有的旧笔记不回溯改名
- 格式同样参考同目录已有文件；无参照时用下面的模板
- 按评论顺序排列，一条意见一个二级标题

```markdown
# PR #<编号> 评审意见评估

## <序号>. <意见标题或一句话摘要>

### 是否属实&问题简述

<核实结论 + 问题简述>

### 修复价值

<必须修 / 可选 / 不修，理由>

### 修复思路（供参考）

<具体修复方案>
```

写完笔记后向用户汇报评估结论，**等用户确认哪些要修之后再进入下一步**。

### 4. 修复

只修改文件。不要执行 add / commit / push / 回复评论等任何会产生历史记录或对外可见的动作。

### 5. 交出去

本技能到修复为止。提交、推送和回复评审意见属于下一步，由 `dbk-pr-commit-reply` 负责（该技能只在用户显式调用时执行）。修复完成后告诉用户改动已就绪，要落地提交推送并回复评审时走那一步。

## 注意事项

- 评审意见针对的代码可能在你上次提交后又变了，评估前确认意见指向的最新代码状态。
- CodeRabbit 等机器人意见同样先过第 2 步的评估流程，机器人的意见也会错。
- 一批意见里通常混着「真问题」和「风格偏好」，评估时分开标注，别一起修。