pr-retro

PR 复盘技能

通过分析 PR 的接受/拒绝模式，从结果中吸取经验。

概述

PR 合并或被拒绝后，分析哪些做法有效、哪些无效，以改进未来的贡献。

输出： .agents/learnings/YYYY-MM-DD-pr-{repo}-{outcome}.md

使用时机：

• PR 合并后（记录成功模式）
• PR 被拒绝后（了解原因）
• 收到重要评审反馈后
• 定期回顾贡献模式

---

工作流

1.  PR Discovery    -> Find the PR to analyze
2.  Outcome Analysis -> Merged/rejected/changes requested
3.  Feedback Extraction -> What did reviewers say?
4.  Pattern Identification -> What worked/didn't
5.  Lesson Extraction -> Reusable learnings
6.  Output -> Write retro document

---

阶段 1：发现 PR

# If PR number provided
gh pr view <number> --json state,reviews,comments,mergedAt,closedAt

# Find recent PRs by you
gh pr list --state all --author @me --limit 10

# Find PRs to a specific repo
gh pr list -R <owner/repo> --state all --author @me --limit 10

---

阶段 2：结果分析

结果	含义	重点
已合并	成功	哪些做法有效？
已关闭（未合并）	被拒绝	为什么？
开放（停滞）	被忽略/放弃	哪里出了问题？
要求修改	需要改进	有哪些反馈？

# Get PR outcome
gh pr view <number> --json state,mergedAt,closedAt,reviews

---

阶段 3：提取反馈

# Get all review comments
gh pr view <number> --json reviews --jq '.reviews[] | "\(.author.login): \(.body)"'

# Get all comments
gh api repos/<owner>/<repo>/pulls/<number>/comments --jq '.[].body'

# Get requested changes
gh pr view <number> --json reviews --jq '.reviews[] | select(.state == "CHANGES_REQUESTED")'

反馈类别

类别	示例
风格	命名、格式、约定
技术	算法、架构、模式
范围	过大、范围蔓延、无关改动
测试	缺少测试、覆盖率、边界情况
文档	缺少文档、注释不清晰
流程	分支错误、缺少签核

---

阶段 4：识别模式

成功模式（已合并时）

有效之处	依据
PR 小而聚焦	< 5 个文件
遵循约定	没有风格方面的评论
测试充分	没有“添加测试”的要求
描述清晰	很快获批

失败模式（被拒绝时）

失败之处	依据
规模太大	“请拆分此 PR”
范围蔓延	“这超出了范围”
缺少测试	“请添加测试”
方案错误	“考虑改用 X”

---

阶段 5：提炼经验

经验模板

## Lesson: [Title]

**Context**: [When does this apply?]
**Learning**: [What did we learn?]
**Action**: [What to do differently?]

**Evidence**:
- PR #N: [quote or summary]

常见经验

经验	行动
PR 过大	将 PR 拆分为不超过 200 行
缺少背景信息	添加“## 背景”部分
风格不一致	提交 PR 前运行代码检查工具
缺少测试	为新代码添加测试
评审缓慢	1 周后提醒

---

阶段 6：输出

写入 .agents/learnings/YYYY-MM-DD-pr-{repo}-{outcome}.md

# PR Retro: {repo} #{number}

**Date**: YYYY-MM-DD
**PR**: {url}
**Outcome**: Merged / Rejected / Stale

## Summary

{What was the PR about? What happened?}

## Timeline

| Date | Event |
|------|-------|
| {date} | PR opened |
| {date} | First review |
| {date} | {outcome} |

## Feedback Analysis

### Positive Feedback
- {quote}

### Requested Changes
- {quote}

### Rejection Reasons (if applicable)
- {quote}

## Lessons Learned

### Lesson 1: {title}
**Context**: {when this applies}
**Learning**: {what we learned}
**Action**: {what to do differently}

## Updates to Process

{Any changes to make to pr-prep, pr-plan, or other skills}

## Next Steps

{Future actions based on this retro}

---

反模式

不要这样做	应改为
跳过已合并 PR 的复盘	也从成功中学习
责怪维护者	聚焦于你能改变的事情
总结泛泛的经验	提炼具体、可执行的经验
跳过被拒绝的 PR	这是最有价值的学习来源

示例

从被拒绝的 PR 中学习

用户说：“复盘一下这个 PR 被拒绝的原因。”

处理过程：

1. 分析评审反馈和时间线。
2. 找出可以避免的流程和范围问题。
3. 记录可复用于未来 PR 的经验。

从成功合并中学习

用户说：“总结这个已合并 PR 中哪些做法有效。”

处理过程：

1. 找出加快评审/批准的模式。
2. 提炼可执行的工作手册更新。
3. 保存经验，供未来贡献流程参考。

故障排除

问题	原因	解决方案
复盘内容泛泛	反馈未与证据关联	引用具体评论/决策及结果
未提炼出明确经验	分析停留在描述层面	将观察结果转化为行为改变
维护者的信号相互矛盾	评审评论相互矛盾	区分硬性阻碍与偏好反馈
流程变更未被采用	经验未转化为实际行动	在准备/计划/验证工作流中明确更新