mcpField
P
pr-retro

pr-retro

github.com/ulpi-io测试与质量5150 次安装9 周前更新
代码仓库

关于 pr-retro

pr-retro 是只读的分支分析工作流，用于比较功能分支与基线并评估合并准备情况。它依据 Git 数据计算指标、扫描常见审查问题，并可保存 JSON 快照。

主要功能

  1. 01计算分支与变更指标
  2. 02汇总贡献者和热点文件
  3. 03扫描提交前常见问题
  4. 04评估合并准备信号
  5. 05标准模式下保存 JSON 快照

适用场景

  1. 01检查分支规模与变更集中度
  2. 02在提交拉取请求前查找规范问题
  3. 03根据分支数据评估合并准备情况

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/ulpi-io/skills --skill pr-retro

安装后在 Claude Code 中输入/pr-retro确认已加载。

附带文件references/retro-metrics.md

详细介绍

这项技能是一个以读取为主的分析工作流，要求确保指标准确无误。

不可妥协的规则：

  1. 验证当前分支是功能分支，且相对于基准分支确实有提交。
  2. 指标必须从 git 数据计算，绝不可估算。
  3. 只有在完整完成指标计算和自我审查后，才能给出结论。
  4. 对代码和 git 状态保持只读；唯一允许的写入是 JSON 快照。
  5. 将详细的指标表、扫描模式和 JSON 架构放在参考资料中，不要在每次调用时都内联提供。

PR 回顾

输入

  • $request：可选标志或指导，例如 --quick 或 --base <branch>

目标

生成可信的分支回顾，内容包括：

  • 衡量分支的实际差异
  • 找出贡献者和热点
  • 扫描常见的 PR 提交前遗留项
  • 通过明确信号评估合并就绪情况
  • 可选地将 JSON 快照保存到 .history/pr-retros/ 下

步骤 0：确定模式和分支范围

确定：

  • 请求使用标准模式还是 --quick
  • 是否指定了自定义基准分支
  • 当前分支名称
  • 当前分支是否为功能分支
  • 相对于基准分支是否存在提交

以下情况应提前停止：

  • 当前位于 main、master 或 develop 分支
  • 相对于基准分支不存在提交

使用 references/retro-metrics.md 中的基准分支解析规则和模式行为说明。

成功标准：明确回顾模式和审查基准，并且有真实的分支数据可供分析。

步骤 1：收集原始分支数据

收集回顾所需的原始 git 数据：

  • 包含作者和时间戳的提交列表
  • 每次提交的统计信息
  • 机器可读的 numstat
  • 汇总差异统计
  • 分支分歧信息

规则：

  • 优先使用原始 git 输出，而非文字描述或推断
  • 如果无法根据收集的数据得出某项指标，应明确说明
  • 不要跳过此步骤直接给出结论

成功标准：所有后续指标都能从收集到的分支数据中推导出来。

步骤 2：计算分支指标

根据原始数据计算核心分支指标：

  • 提交总数
  • 贡献者
  • 变更文件数
  • 新增行数
  • 删除行数
  • 净代码行数
  • 测试代码行数占比
  • PR 规模类别
  • 分支存续时间
  • 基准分支漂移
  • 聚焦度得分
  • 工作会话数和时间线

如果处于 --quick 模式，则在计算出仪表板级指标和结论所需输入后停止。

查阅 references/retro-metrics.md，了解：

  • 指标公式
  • PR 规模分档
  • 聚焦度得分规则
  • 会话识别规则

成功标准：每项展示的指标都源自具体的 git 数据。

步骤 3：分析贡献者、热点和代码卫生

构建分支健康状况视图：

  • 贡献者构成
  • 提交类型分布
  • 热点文件
  • WIP/fixup 或薄弱提交消息等代码卫生信号

规则：

  • 根据提交数据归属作者，不要使用本地 git 配置
  • 将 conventional-commit 合规性视为一项指标，而非道德评判
  • 使用热点分析说明风险集中情况，不要据此暗示存在 bug

成功标准：回顾说明了哪些人修改了哪些内容，以及分支的改动集中在哪里。

步骤 4：运行自我审查扫描

使用 references/retro-metrics.md 扫描分支差异中的：

  • 硬编码的密钥
  • .only 测试标记
  • 冲突标记
  • 调试语句
  • TODO 或 FIXME 遗留项
  • 注释掉的代码
  • 大型文件新增项
  • 二进制文件
  • 值得注意的配置变更

规则：

  • 输出中绝不包含实际的密钥值
  • 区分 BLOCK、WARN 和 INFO
  • 这不是完整的安全审计；应将其作为评估合并就绪情况的依据

成功标准：回顾捕捉到会影响合并就绪情况的分支代码卫生问题。

第 5 步：确定是否已准备好合并

评估已配置的信号：

  • 卫生状况
  • 规模
  • 测试比例
  • 专注度
  • 自我审查发现
  • 偏离情况

然后给出：

  • GREEN
  • YELLOW
  • RED

为每个非绿色信号生成建议。

加载 references/retro-metrics.md，查看判定规则和信号阈值。

成功标准：判定符合文档中的信号规则，且可根据指标加以说明。

第 6 步：呈现输出并保存快照

始终呈现仪表盘摘要。

在标准模式下，还要呈现：

  • 贡献者
  • 提交类型明细
  • 热点
  • 自我审查发现
  • 时间分布
  • 建议

在标准模式下，将 JSON 快照保存到：

  • .history/pr-retros/<branch-slug>.json

在 --quick 模式下跳过快照。

使用 references/retro-metrics.md 查看：

  • 输出章节
  • JSON 架构
  • 分支 slug 规则

成功标准：复盘输出内部一致，且仅在适当情况下写入快照。

防护措施

  • 不得捏造指标。
  • 不得更改代码或 Git 状态。
  • 不要添加 disable-model-invocation；用户要求分析分支时，此技能应仍可调用。
  • 不要添加 paths:；这是通用工作流技能。
  • 不要在 SKILL.md 中内嵌指标表、信号阈值和 JSON 架构。
  • 存在阻塞性发现时，不得给出 GREEN 判定。

何时加载参考资料

  • references/retro-metrics.md 用于查看指标公式、信号阈值、自我审查扫描模式、输出布局和 JSON 快照架构。

输出约定

报告：

  1. 分支和基准分支
  2. 关键仪表盘指标
  3. 总体判定和各信号状态
  4. 值得关注的发现和建议
  5. 写入快照时的快照路径，或明确说明在快速模式下已跳过

评论

支持 Markdown