Manage PR 用于在 GitHub 上创建和更新 Pull Request，并覆盖堆叠式 PR 与堆叠合并循环的完整流程。标题、风格和远程仓库命名遵循 git-conventions 技能；PR 存放于仓库的主远程仓库上，该技能通过 gh 支持 GitHub。若仓库存在明确的约定（如 PR 模板、标题检查、贡献文档），这些约定优先于默认规则。
适用用途
当用户希望打开或更新 PR，或希望工作以 PR 形式交付时使用。它同时支持单个 PR 的创建/更新，以及跨多个 PR 的堆叠工作流。
主要能力
创建或更新 PR。创建前先检查现状：使用 git log <base>..HEAD --oneline、git diff <base>...HEAD --stat，以及 gh pr view 查看已存在的 PR 状态。标题格式为 type(scope): description。正文通过下面的模板由 --body-file 传入，并传入明确的标志，避免 gh 弹出交互提示。先将分支推送到主远程仓库（git push -u <primary> <branch>；仓库通常有两个远程，未设置上游会导致 gh 提示）。创建为待审查并自我指派：gh pr create --assignee @me --base <base> --title <title> --body-file <file>。
PR 正文模板（Notes 为空时省略）：
Summary
- 2-5 条简洁要点：改了什么以及为什么。
- Stacked on #N.（仅堆叠 PR）
Verification
- 实际运行的命令及其结果。
Notes
- 风险、迁移顺序或审查指引。
验证部分只填写实际运行过的命令及其结果。
堆叠 PR。当工作跨越多个 PR 时，自底向上串联分支：第一个 PR 基于默认分支，后续每个 PR 基于前一个分支。保持每个 PR 可独立通过，并让堆叠顺序读起来像一条论证线索。
合并循环。当用户说“let's get the PRs merged”时，自底向上映射堆叠，记录每个分支当前的末端，交回最底部 PR 的链接并等待。每当收到“merged #N”（任意合并方式，通常是 squash）时：
- 拉取主远程仓库并快进本地默认分支。
- 使用记录的末端将下一个分支 rebase 到最新的默认分支：git rebase --onto <default> <old-base-tip> <branch>。然后以同样方式将每个剩余分支 rebase 到其被重写的父分支：git rebase --onto <parent> <old-parent-tip> <branch>。记录新的末端。
- 发生冲突时停止并报告；半完成解决的 rebase 绝不推送。
- 确认每个分支的内容得以保留：git range-diff <old-base-tip>..<old-tip> <new-base>..<branch> 应只显示基础变化。只有确认后才使用 --force-with-lease 推送。
- 重定向下一个 PR（gh pr edit <next> --base <default>），回复其链接，并等待下一个“merged #N”。即使合并不是 squash 也要如此重新同步。最后一个 PR 之后，确认堆叠已完成，并提供本地清理（在 worktree 中检出的分支需要先执行 git worktree remove）。
使用方式
依赖 git 与 gh 命令行工具；通过设置明确的标志避免交互提示；通过 --body-file 传递正文；通过记录分支末端并在每次合并后执行 rebase 来维持堆叠。
适用场景
需要打开或更新 PR、以 PR 形式交付工作、管理多个相互依赖的堆叠 PR，以及协调一连串 PR 的合并顺序时。
限制
合并是用户的操作，该技能从不执行合并。主远程仓库需按名称解析，这些仓库中不存在名为 origin 的远程。标题和正文中不应包含计划与里程碑上下文。官方文档未提供收费、价格、平台或效果相关信息。