用途：当操作者指向一个包含 N 个可执行子任务的上层工单（审计、RFC、设计文档、多发现报告等），并希望每个子任务各自成为一个 PR 时使用。典型触发语包括“为每个 P1/P2/P3 子任务各建一个 PR”“每个发现一个 PR，堆叠”“处理 PR #N..#M 上的所有评论和机器人审查”“把这些 PR 推进到可合并，更新后重新请求审查”。
主要能力：分为三个阶段。阶段 A 规划：读取上层工单，按优先级/标签/条件筛选可执行子任务，与操作者确认 PR 策略（单 PR、堆叠 PR、独立 PR 加选择性堆叠），确定子任务顺序并固定执行参数，获得批准后再动代码。阶段 B 执行：按顺序为每个子任务建立 worktree，调用 dev-team 技能运行 Dev→QA→Reviewer→commit 循环，推送提交，按所选模式用 gh pr create --base <stack-parent> 或 --base main 开 PR，并标记工单完成。阶段 C 响应反馈：对每个 PR 抓取三类评论来源（内联 reviewThreads、顶层 reviews、issue 级 comments），分类、修复、提交、推送，回复“Addressed in <SHA>”，用 GraphQL resolveReviewThread 解决内联线程，级联 rebase 下游 PR，并 @ 机器人重新审查，多轮直至审查者不再提出问题。
使用方式：完整执行时按顺序阅读三个阶段文件；仅需响应评论等部分调用时直接读对应阶段文件。每子任务循环由 dev-team 技能负责，本技能不重复实现。
限制：不适用于只有一个大问题、子任务完全独立（不同服务/仓库）或需要同步结对编程的场景。循环达到周期上限而未获批准提交时会阻塞整个堆叠，需升级给用户，不应静默重试。堆叠相关硬性规则包括：默认不 amend、每次推送后使用 git rebase --onto <new-base> <local-old-upstream> 做堆叠感知 rebase、必须抓取三类评论来源、回复格式为 Addressed in <SHA>、每轮每 PR 都要请求重新审查。具体命令与参数细节以资料中的参考文件为准，此处未提供完整代码示例。