mcpField
P
pr-splitter

pr-splitter

github.com/mastra-ai开发29.2k44 次安装今天更新
代码仓库

关于 pr-splitter

pr-splitter 是供开发者将大型 Pull Request 拆分为较小、易审查 PR 的工作流技能。它强调保留原始分支、分别验证每个拆分结果，并记录评审反馈带来的变化。

主要功能

  1. 01备份原始分支
  2. 02规划堆叠或并行 PR
  3. 03按文件或代码块提取变更
  4. 04分别验证每个 PR
  5. 05跟踪评审引入的差异
  6. 06创建范围明确的 changeset

适用场景

  1. 01将大型 PR 拆成易审查的部分
  2. 02把相互依赖的变更拆为堆叠 PR
  3. 03根据评审反馈重置 PR 堆栈

安装

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

$npx skills add https://github.com/mastra-ai/mastra --skill pr-splitter

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

详细介绍

PR Splitter

将原始 PR 保留为素材，有意识地拆分出更小、便于评审的 PR，并在评审反馈改变 stack 时在本地追踪偏差。

必需的工作流程

  1. 在修改历史之前先做快照

    • 检查 git status。
    • 为原始分支创建一个不可变的本地引用：git branch backup/original-large-pr。
    • 在拆分完成之前，不要删除或重写原始分支。

  2. 盘点原始 PR

    • 检查 git diff --stat <base>...HEAD、git diff --name-only <base>...HEAD 和 git log --oneline <base>..HEAD。
    • 按评审单元对变更分类：准备/重构、API/类型变更、行为变更、测试、文档、清理、生成文件/锁文件。

  3. 创建本地草稿文件

    • 将拆分笔记写入未提交的本地文件，首选 .notes/pr-split.md。
    • 确保 .notes/ 被忽略，或保持未跟踪状态。除非用户明确要求，不要提交草稿笔记。
    • 追踪以下内容：原始分支、基础分支、计划中的 PR、已提取的文件/代码块、每个 PR 的验证情况、原始 diff 的剩余部分，以及评审反馈带来的有意偏差。

  4. 选择拆分方式

    • 当后续工作依赖于先前工作时，使用堆叠 PR。
    • 只有当变更确实相互独立时，才使用并行 PR。
    • 当一个共享的准备性变更能解锁多个独立工作时，使用“基础 PR + 并行后续 PR”的方式。

  5. 安全地提取变更

    • 优先从正确的基础分支新建分支，再进行选择性还原，而不是重写杂乱的历史。
    • 对于文件归属清晰的情况，使用路径级提取：git checkout backup/original-large-pr -- path/to/file。
    • 对于混合了多种变更的文件，使用代码块级提取：git restore -p --source backup/original-large-pr -- path/to/file。
    • 确保每个 PR 都可以独立构建、便于评审。

  6. 独立验证每个 PR

    • 针对该 PR 的范围，运行最小但相关的构建、类型检查、lint 和测试。
    • 除非拆分计划明确要求，否则不要把测试、文档或生成文件与其验证的代码分开。

  7. 有意识地管理偏差

    • 将评审者批准的变更视为 stack 的新事实来源。
    • 修改较早的 PR 之后，将依赖它的 PR 变基到该 PR 上，并以评审确认的方向解决冲突，而不是盲目采用原始分支的版本。
    • 将不断演进的 stack 与 backup/original-large-pr 比较，以找出剩余的意图，而不是强求逐字节一致。
    • 在 .notes/pr-split.md 中记录有意的差异。

  8. 对重写后的 stack 使用 range-diff

    • 在变基、解决冲突或强制推送之后，使用 git range-diff 了解发生了什么变化。
    • 更新堆叠 PR 时，向评审者总结有意义的 range-diff 结果。

PR 描述模板

保持 PR 描述简洁，面向评审者：

## Summary

This is PR N of M split from a larger change.

## Scope

- ...

## Intentionally excluded

- Follow-up PR will handle ...

## Verification

- ...

不要在 PR 描述中放入完整的拆分台账。详细的提取笔记和偏差追踪应保存在 .notes/pr-split.md 中。

草稿模板

# PR split scratchpad

Original branch: backup/original-large-pr
Base branch: main

## Planned PRs

1. branch-name
   - Scope:
   - Files/hunks extracted:
   - Verification:
   - Changeset: (package names, bump type, scoped message)
   - Status:

## Remaining original intent

- ...

## Drift notes

- Date / branch / reason:

Changesets

每个拆分出的 PR 都必须附带自己的 changeset，且仅涵盖该 PR 中的变更。不要保留源分支中的原始 changeset，因为它覆盖的是整体合并后的全部变更，不应出现在任何单个拆分 PR 中。

将变更提取到拆分分支后：

  1. 删除从原始分支带过来的所有 changeset 文件。 这些文件是针对合并后的整体 diff 编写的，会生成错误的变更日志条目。
  2. 使用 CLI 为每个 PR 创建新的 changeset（参见 .mastracode/commands/changeset.md）： 
    pnpm changeset -s -m "your scoped message" (--major | --minor | --patch) pkg-name
  3. 将消息范围限定在该 PR 的变更内。 changeset 消息应描述该特定 PR 的具体作用，而不是整个原始功能。
  4. 仅包含该 PR 实际修改的包。 如果原始 changeset 列出了五个包，但该 PR 只涉及 @mastra/core，则新的 changeset 只应引用 @mastra/core。
  5. 版本升级类型应与 PR 的范围相匹配。 准备性/重构类 PR 通常为 patch；引入新 API 表面的 PR 为 minor；包含破坏性变更的 PR 为 major。

将 changeset 创建步骤添加到草稿模板中每个计划 PR 的验证清单下，以免遗漏。

常见失败模式

避免以下情况：按文件拆分而行为跨文件；只提取测试而不提取代码；导致后续 PR 无法编译；在没有评审者摘要的情况下强制推送；过早删除原始分支；在解决堆叠冲突时还原评审反馈；在每个拆分 PR 中保留原始分支的 changeset，而不是为每个 PR 创建范围限定的 changeset。

默认输出

当被要求拆分 PR 时，应输出：

  1. 建议的 PR 顺序，
  2. 分支策略，
  3. 草稿路径及初始内容，
  4. 提取命令，
  5. 每个 PR 的验证计划，
  6. 偏移管理计划。

评论

支持 Markdown