gh-stack 原生 GitHub 叠加拉取请求管理

要解决什么问题

一次改动涉及多层逻辑时，单个 PR 往往变得过大：审阅者很难判断反馈针对的是接口层还是实现层，作者要么一次性合入全部内容，要么在已合入的代码上反复修补。原生 GitHub Stacked PRs 通过让上层分支依赖下层分支，使每一层 PR 都能独立审阅、独立合并。难点在于分支管理容易出错：层序混乱、基线漂移，PR 之间失去叠加关系。这个技能就是让编码代理自动完成这套流程。

它如何工作

核心能力是教会代理使用 gh stack CLI 管理一整个 PR 栈的生命周期：

• 拆分改动层：把大型改动分解为多个聚焦的分支，每层只负责一件事，形成自下而上的依赖链。
• 建层与入栈：在当前 HEAD 处创建新分支，将其加入栈顶并切换过去；未提供分支名时会提示输入。
• 维持层序：只在栈顶分支上执行操作，保证分支层与栈结构始终一致。
• 编号命名：支持 -n / --numbered 选项，配合 --prefix 生成自增编号分支名，便于识别层序。
• 提交审阅链：推送叠加分支链，打开一组可独立审阅的原生 GitHub Stacked PR。

代理的典型流程：确认仓库已启用 Stacked PRs，按层规划改动，自底向上逐层建分支并提交，最后打开完整 PR 链等待审阅。

适用边界与注意点

• 需要 GitHub CLI gh 2.0+，并安装 gh-stack 扩展。
• 目标仓库必须启用 Stacked PRs 功能，否则无法建立叠加关系。
• 代理需能在仓库内执行 Git 命令；本技能只负责栈的编排，不负责写代码本身。
• Stacked PRs 依赖分支层保持 rebased，长期搁置的栈可能出现层间漂移。