用途：将含 N 个可执行子任务的父级工单（审计报告、RFC、设计文档、多发现项报告等）转化为一叠干净的 PR，并持续推动至可合并状态，直到评审者满意。
主要能力：分三阶段。阶段 A 规划：读取父级工单，按优先级/标签筛选可执行子任务，设计堆叠顺序，与操作者确认 PR 策略（单一 PR、堆叠 PR、独立 PR 加选择性堆叠），固定执行参数并取得批准。阶段 B 执行：按顺序对每个子任务建立 worktree，调用 dev-team 技能运行 Dev→QA→Reviewer→commit 循环，推送后用 gh pr create --base <stack-parent> 开 PR，并标记工单完成。阶段 C 响应反馈：抓取三类评论来源（行内评审线程、顶层评审正文、issue 级评论），分类、修复、提交、推送，回复 Addressed in <SHA>，级联 rebase 下游 PR，并 @机器人 重新评审，多轮直至无新意见。
依赖：需先安装 dev-team 与 pr-autopilot 两个插件，例如 /plugin install dev-team 和 /plugin install pr-autopilot；缺失时应停止并提示安装，不得内联重实现。
适用场景：子任务数量通常 5–30 个、可独立评审、共享足够代码面使堆叠分支比从 main 开 30 个分支更省事，且需要跨单次注意力周期的编排。不适用：父级只有一个大问题、子任务完全独立（不同服务/仓库）、或用户想要同步结对编程。
限制：循环的 cycle cap 会阻塞堆叠，子任务耗尽上限未获批准提交时须升级给用户，不得静默重试；每个子任务使用独立 dev 团队；默认不 amend、不用 --no-verify、不用 git add -A、不碰操作者主检出；级联 rebase 使用 git rebase --onto <new-base> <local-old-upstream>。具体机制详见 dev-team 与 pr-autopilot 技能及其 references 文件。