用途
该技能用于构建、提交、合并和修复「堆叠式」的依赖拉取请求（Pull Request）、合并请求（Merge Request）或分支。适用于一项变更被拆分到多个层次、且每一层依赖下一层的情况。
两条工作流不可互换
资料明确说明这里有两条工作流，且不能互换。必须在改动历史之前，按托管平台和堆叠形态做选择：
- GitHub，且所有层在同一个仓库：使用原生 gh stack，参考 references/github-native.md。
- GitLab、Gitea 或任何其他托管平台：手动 rebase，参考 references/manual-rebase.md。
- GitHub，但跨 fork 或从未注册为堆叠：手动 rebase，参考 references/manual-rebase.md。
只有 GitHub 具备此功能的平台自动化。手动路径就是普通 Git，因此在其他所有托管平台上都要靠它承担整个工作流：git rebase --update-refs 和 git rebase --onto 完成 gh stack 本应在服务端完成的工作。
资料警告两种反向错误：对已注册的 GitHub 堆叠手工重建历史，会丢弃平台已经做的服务端 rebase 与重定向，并可能导致堆叠无法合并；而在不支持的堆叠上贸然使用 gh stack，会明确报错，代价不大。
运行前先识别托管平台
资料要求读取远程地址而非凭习惯判断。gh 命令在非 GitHub 远程上会失败或产生误导，且一个仓库可以有多个指向不同托管平台的远程。
命令：
git remote -v
如果远程不是 GitHub，直接转到 references/manual-rebase.md，下文不再适用。
在 GitHub 上，原生路径需要 gh CLI，并添加 GitHub 的 stack 扩展。资料要求在路由到该路径前确认扩展已存在，并在用户同意时安装。
相关检查命令：
gh repo view --json url,isFork,parent gh stack view 2>&1 | head -5
isFork 和 parent 决定堆叠是否跨 fork，而原生功能不支持跨 fork。gh stack view 在不属于堆叠的分支上会失败，由此可判断这些分支是否已注册。
手动路径的安全规则
资料列出的规则不论托管平台都成立：
- 在改写前，把每个提交归类为由父层所有、由子层所有或归属不确定，并展示该分类。
- 归属不确定的提交留给用户判断，不要从分支名或提交信息猜测。
- 在任何改写之前，于 refs/heads 之外创建备份引用，且绝不自动删除。由于 Git 可能随堆叠分支移动该分支，使用 git rebase --update-refs 时分支并不安全。创建新引用时不要覆盖已有的恢复点。
- 在执行 --force-with-lease 前要求明确确认，绝不使用无保护的强制推送。
- 改写后校验生成的历史、差异和 PR/MR 元数据。
权威来源
资料指出原生堆叠功能处于活跃预览阶段，因此应从来源确认标志，而非依赖背下来的配方：
gh stack <command> --help
https://gh.io/stacks
https://docs.github.com/en/pull-requests/reference/stacked-pull-requests
资料还提到，其他托管平台按各自节奏提供各自的依赖功能，此处均未做检查。在假定某平台没有相关能力之前，应先查证其是否提供依赖或堆叠式合并请求，以及所需套餐层级。
相关技能
- vp-git：用于单分支提交、清理和常规拉取请求生命周期工作。
- vp-pr-comment-resolver：当堆叠中的某个 PR 有可执行的作者侧反馈时使用。
限制
资料未提供具体支持的平台版本、安装步骤细节、收费信息或性能数据，这些内容暂未提供。