用途
pr-split 用于把一个大型分支转换为一系列小型、高质量的 PR。其意图是改善评审体验，而非按提交做机械切分。每个拆分出的 PR 应当只做好一件事、便于评审（理想篇幅 500-1000 行）、在序列中讲述连贯的故事、通过全部质量检查，并配有清晰且说明原因（WHY）的提交信息。每个 PR 都应当是你愿意提交评审的作品。
若用户提供 help 命令选项，技能会解释如何使用该提示，并说明是否缺少前置条件或工具要求，随后立即退出，不继续执行。
主要能力
- 前置条件校验与基准分支识别：检查 Git CLI、已认证的 GitHub CLI、工作区是否干净、是否处于特性分支而非主干分支。运行共享检测脚本 bash .rulesync/skills/git-conventions/detect-base-branch.sh 来确定基准分支，该脚本遍历所有 origin/bX.Y.Z 发布分支（新版本优先），比较 merge-base 距离并输出 BASE_BRANCH=<branch>；若某发布分支比 origin/latest 更近则选用它，否则使用 latest。
- 前缀提取：根据仓库名（所在目录）判断项目并确定提交前缀。ag-studio 的分支模式为 st-NNNNN/description，前缀 ST-；ag-charts 与 ag-grid 的分支模式均为 ag-NNNNN/description，前缀 AG-；默认为 ag-NNNNN/description，前缀 AG-。若分支匹配项目模式，则提取 JIRA 工单（如 ST-12345、AG-12345）；否则从分支名派生前缀（如 feature/null-keys 变为 null-keys）。该前缀用于提交信息与 PR 标题。
- 改动理解：使用 Explore 类型子代理深入分析改动，获取相对基准分支的完整 diff，查看所有提交信息及其内容，了解改动范围（变更文件、增删行数、涉及的包）。分析时聚焦内容与目的而非提交边界，识别不同特性或关注点、逻辑依赖、自然边界（包边界、代码与测试与文档、重构与特性），并评估评审者的认知负担。
- 拆分方案设计：基于内容分析，使用 AskUserQuestion 提出 2-3 个具体的拆分提案。可考虑的类型包括按逻辑单元（推荐的默认方式，按特性或关注点分组）、按包/模块（跨代码库边界拆分，如 core、community、enterprise 的顺序）、自定义（由用户指定拆分点）。每个选项应包含 PR 数量及各 PR 的内容，目标为每个 PR 500-1000 行以便评审。不提供“按提交”拆分。
- 方案确认与校验：呈现详细拆分计划供确认，计划包含每个 PR 的标题、目的、文件、行数及依赖关系；运行 /plan-review 技能检查完整性与正确性。
- 拆分执行：创建临时分支以暂存全部改动（记录当前分支名、从当前 HEAD 创建临时分支、软重置到与基准分支的 merge base，把所有提交转为已暂存改动）。为计划中每个 PR 创建分支：首个 PR 从基准分支创建，用 git checkout <temp-branch> -- <files> 引入相关文件，必要时用 git add -p 做部分暂存；后续 PR 从前一个 PR 的分支创建并引入下一批文件，维持依赖链。
- 提交信息质量：每条提交信息应以 JIRA 工单或分支前缀开头，使用祈使语气（Add、Fix、Refactor），说明改了什么与为什么（而非仅列文件），简洁但完整，不含 LLM 署名或表情符号。
- 质量迭代：逐个分支 rebase（首个 rebase 到基准分支，后续 rebase 到前一个 PR 分支），通过子代理运行 /pr-review，识别代码质量问题、检查逻辑连贯性、评估范围是否合适（是否只做好一件事、能否独立理解、是否 500-1000 行、有无遗漏或放错位置的内容），检查提交信息与 PR 标题质量，运行项目在受影响包上的 pre-commit 校验命令，确保类型检查、lint 与测试全部通过。修复问题后反复迭代直至达到可评审标准，并使用质量清单逐项核验。
- 创建 PR 与推送：用 git push -u origin "${branch_name}" 推送各分支并设置上游跟踪；用 gh pr create 为各分支创建草稿 PR，首个 PR 指向基准分支，后续 PR 指向前一个 PR 的分支。PR 描述使用模板，包含 Summary、Position in Stack（栈中位置，第 N 个共 M 个、上一个与下一个 PR）、JIRA、Test Plan 等部分。
- 结果报告：输出所创建 PR 的摘要，包括原始分支拆分为 N 个堆叠 PR 的说明、PR 链表格（序号、分支、PR、描述、基准）、依赖图，以及评审者说明（按顺序评审、每个 PR 只显示其增量改动、查看截至第 N 个 PR 的累计改动可比较该分支与基准分支、按顺序批准并合并后后续 PR 会自动更新其基准）。
使用方式
该技能以提示（prompt）形式组织，按阶段顺序执行：Phase 0 前置条件、Phase 1 理解改动、Phase 2 设计拆分、Phase 3 执行拆分、Phase 4 质量迭代（关键）、Phase 5 创建 PR 并推送、Phase 6 报告结果。工具要求为 Git CLI 可用、GitHub CLI（gh）可用且已认证、工作区干净、处于特性分支而非主干分支。
适用场景
适用于需要将大型分支整理为逻辑清晰、便于评审的堆叠 PR 序列的场景，尤其关注评审者体验、单 PR 目的单一、篇幅适中、提交信息说明原因的情况。
限制与错误处理
- 工作区不干净时：告知用户需要提交或暂存改动，给出命令 git stash 或 git commit -am "WIP"，并在不做任何更改的情况下退出。
- rebase 期间出现合并冲突时：暂停并向用户展示冲突，询问是手动解决还是中止，不尝试自动解决冲突。
- 构建、lint、测试失败时：尝试使用 code-fixup 技能修复；若两次尝试后仍失败则询问用户；不推送存在已知失败的分支。
- GitHub CLI 失败时：提供通过 GitHub 网页 UI 手动创建 PR 的说明，包括分支名、基准分支及建议的标题与正文。
- 本技能不提供“按提交”拆分选项。
具体的收费、价格、平台等信息暂未提供。