name: pr-operations description: 用于处理PR审查评论、解决线程或回复讨论评论时。对于理解PR线程操作的正确erk exec命令至关重要。
PR操作技能
核心规则
关键：仅使用
erk exec命令进行PR线程操作
- ❌ 不要使用原始
gh api调用进行线程操作- ❌ 不要直接使用
gh pr命令进行线程解析- ✅ 仅使用下面列出的
erk exec命令
erk exec命令正确处理线程解析。原始API调用只会回复而不解析。
快速参考
| 命令 | 目的 | 关键点 |
|---|---|---|
get-pr-review-comments |
获取未解决的审查线程 | 返回带行信息的线程 |
get-pr-discussion-comments |
获取PR讨论评论 | 返回顶级评论 |
resolve-review-thread |
回复并解析单个线程 | 在一次操作中完成两者 |
resolve-review-threads |
批量解析多个线程 | JSON标准输入，一次调用处理N个线程 |
reply-to-discussion-comment |
回复讨论评论 | 用于非代码反馈 |
post-pr-inline-comment |
发布新的内联评论 | 创建新的审查线程 |
何时使用每个命令
获取评论
# 获取所有未解决的审查线程（代码评论）
erk exec get-pr-review-comments
# 获取所有讨论评论（顶级PR评论）
erk exec get-pr-discussion-comments
# 包括已解析的线程（用于参考）
erk exec get-pr-review-comments --all
解析审查线程
# 解析单个线程
erk exec resolve-review-thread --thread-id "PRRT_abc123" --comment "Fixed in commit abc1234"
# 批量解析多个线程（推荐用于pr-address批次）
echo '[{"thread_id": "PRRT_abc", "comment": "Fixed"}, {"thread_id": "PRRT_def", "comment": "Applied"}]' | erk exec resolve-review-threads
回复讨论评论
# 用于PR讨论评论（非代码审查线程）
erk exec reply-to-discussion-comment --comment-id 12345 --reply "**已采取行动：**按要求更新了文档。"
常见错误
| 错误 | 为什么错误 | 正确方法 |
|---|---|---|
使用gh api repos/.../comments/{id}/replies |
只回复，不解析 | 使用erk exec resolve-review-thread |
使用gh pr comment |
不解析线程 | 使用erk exec resolve-review-thread |
| 跳过过时线程的解析 | 线程在PR中保持开放 | 总是解析，即使已修复 |
| 通用回复如"已注意" | 对PR历史无益 | 包括调查发现 |
回复 vs 解析
重要：回复 ≠ 解析
- 回复（通过原始
gh api .../replies）：添加评论但线程保持开放- 解析（通过
erk exec resolve-review-thread）：添加评论并标记线程为已解析始终使用
erk exec resolve-review-thread（单个）或erk exec resolve-review-threads（批量）- 它们在一次操作中完成两者。
评论分类模型
分析PR反馈时，按复杂性对评论进行分类并分组处理批次。
复杂性类别
- 本地修复：单个评论 → 单个位置更改（例如，“修复拼写错误”、“添加类型注释”）
- 多位置：单个评论 → 一个文件中多个位置更改
- 跨领域：单个评论 → 跨多个文件更改
- 相关：多个评论告知单个统一更改
批次顺序
从最简单到最复杂处理批次：
| 批次 | 复杂性 | 描述 | 示例 |
|---|---|---|---|
| 1 | 本地修复 | 一个文件，每个评论一个位置 | “在行42使用LBYL模式” |
| 2 | 单文件多位置 | 一个文件，多个位置 | “重命名此变量在此文件中的每个出现” |
| 3 | 跨领域 | 多个文件受影响 | “更新此函数的所有调用者” |
| 4 | 复杂/相关 | 多个评论告知一个更改 | “将validate折叠到prepare中” + “为此使用联合类型” |
注意：需要文档更新的讨论评论归入批次3（跨领域）。
批次确认流程
- 批次1-2（简单）：自动进行，无需确认
- 批次3-4（复杂）：显示计划并等待用户批准
内联评论去重
发布内联审查评论时，始终去重以防止重新发布现有评论：
- 构建去重键：
(file_path, line_number, body_prefix)其中前缀是评论正文的前80个字符 - 检查邻近性：在2行容差内匹配（行42匹配行40–44的现有评论）
- 跳过重复项：如果存在匹配键，则不发布评论
这防止相同反馈在审查迭代中多次出现。查看内联评论去重获取完整算法详情。
详细文档
完整命令文档包括JSON输出格式、选项和示例：
@references/commands.md