技能介绍

问题：PR 数据很多，报告口径却各说各话

工程团队常需要按仓库、时间段、作者或标签筛 PR，再产出周报、个人工作说明、发布说明或面向客户的进度摘要。若直接用 gh 临时拼查询，容易出现三类麻烦：草案 PR 把审查周期算偏、把 LOC/PR 数当生产力排名（Goodhart 陷阱）、以及 DORA 仍用已弃用的低/中/高/精英分层而忽略 DORA 2025 的百分位与 7 种团队原型。Harvest 的定位是只读事实来源：从 GitHub PR 历史安全聚合，再按受众选模板输出。

它如何工作

工作流固定为 SURVEY → COLLECT → ANALYZE → REPORT → VERIFY。在 COLLECT 阶段用 gh REST（per_page=100、--paginate、在缓存仍新鲜时用 ETag/If-Modified-Since）拉取 PR；在 ANALYZE 阶段做大小分级（≤200 / 201–400 / 401–1000 / >1000 LOC，并对超大 PR 标注缺陷检出率风险）、从「就绪审查」时间戳起算四段周期（编码→接单→审查→合并），并做橡皮图章检测（审查前置时间与 PR 大小弱相关时标记）。

子命令（配方）决定算什么：weekly 默认周报；monthly 含原型画像与周期分解；release 按标签区间生成变更日志式发布说明；retro 叙述性回顾；dora 按 DORA 2025 五关键指标（3 吞吐量 + 2 不稳定性）与 7 原型映射；okr 做季度 PR→目标关联；prstats 做 P50/P75/P90、Lorenz/Gini 与大 PR 账本。报告模式（摘要、详细列表、个人、客户报告、质量趋势等）与配方正交，决定输出形态与文件名。

边界与注意点

绝不创建/编辑/关闭/评论 PR，也不改仓库状态。单次请求若超过约 100 个 PR、访问外部仓库或拉全量 PR 历史，应先确认范围。工作量一律以范围估算（如 2–4 小时）呈现，并配对审查评论、回退率等质量上下文；不做个人开发者评分或贡献者排名。比较 AI 前后时期须在报告中注明 DORA 2025 关于 AI 与吞吐量/稳定性的上下文，并警惕大批次 PR 回归。实时 KPI 仪表板交给 Pulse，发布执行交给 Launch，超大 PR 拆分策略交给 Sherpa。