用 GitHub 父议题的子议题树在 worktree…

当需要把 GitHub 父议题下的子议题（含孙）按依赖顺序批量并行实现并自动推进到 PR 可合并状态时使用。

适用场景

解决思路

1. 确认环境：gh CLI 已安装并认证（gh auth status）；jq 可用（command -v jq）；awk 可用（command -v awk）；git working tree 干净（git status）；对目标仓库有写权限；父议题与子议题已通过 GitHub sub-issues API 关联。
2. 确认合并目标分支 CI green；该确认依赖向合并目标分支 push 会触发 CI，若仓库没有 push 触发的 workflow 或 paths 过滤导致不触发，则不要启用 autoMerge: true。
3. 若使用 autoMerge: true，先把 base 分支 ruleset 的 required status checks strict（strict_required_status_checks_policy）设为 false，否则每 merge 一件都会让其他 open PR 的 base 陈旧，并行运行无法收敛。
4. 用 Workflow 工具启动，scriptPath 指向本 skill 目录下的 scripts/implement-issue-tree.js；路径按 upstream skills/、.agents/skills/、.claude/skills/ 三种布局取实际路径，js 与 merge-guard hook 必须同属同一 skill 目录。
5. 在 args 中传 parent（必填）、branch（默认 main）、parallel（1-8，默认 3）、phaseGate（boolean，默认 false）、externalChecks（三态数组）、autoMerge（boolean，默认 false）、maxResidualWorktrees、maxResidualWorktreeBytes、maxBaseMerges、repo。
6. phaseGate: true 时让根的直接子节点按 sub-issues 列表顺序（siblingIndex）串行；前一个 Phase 的全部子孙 merged/closed 后才进入下一个 Phase 的子树；不要解析标题中的 feat(phase-N) 来判定。
7. externalChecks 元素写成 {"app":"slug","context":"required check context"}；多个 context 用 contexts 数组；最多 10 件；[] 表示明确没有外部检查；未指定表示构成未确定，自动合并必须停止。
8. autoMerge 只接受 boolean，非 boolean 报错停止；maxResidualWorktrees/maxResidualWorktreeBytes/maxBaseMerges 只接受非负整数（maxBaseMerges 0-10），非法报错停止；repo 必须 owner/repo 格式，未指定则 base 合并自动停止（fail-closed）。
9. 用 gh api --paginate 'repos/{owner}/{repo}/issues/<parent>/sub_issues?per_page=100' 递归获取整棵子树。
10. 用 post-order DFS 构建执行队列：同父节点按 sub_issues API 返回顺序（siblingIndex）排列；子全完成后再处理父（父节点为 verify-close）；closed 节点自动跳过。
11. 对每个 open issue 用 gh issue view <N> 读正文，抽取功能依赖 dependsOn；只把功能上必须先完成的 issue 号放进 dependsOn，仅相关或可能冲突的不放。
12. 忽略指向祖先 issue 的 dependsOn；DFS 检测依赖循环并删除构成循环的 dependsOn 非树边，防止死锁。
13. 依赖阻塞每轮重新判定：前提失败/阻塞时不要立刻确定；若在 halt 之前前提在运行中被外部完成（issue CLOSED / PR MERGED），同一运行内重新判定下游并开始下游。
14. 观测最近 3 个 merged PR 的 check-runs，找 GitHub Actions 以外的外部检查 App：先 gh pr list --state merged --limit 3 --json headRefOid --jq '.[].headRefOid'，再对每个 sha 调 gh api 'repos/{owner}/{repo}/commits/<sha>/check-runs' 并筛 .app.slug != "github-actions"；此结果只作参考，不作为外部检查构成的确定依据。
15. 默认 phaseGate false 时 siblingIndex 只是 post-order 优先级，parallel >= 2 时后 Phase 的 leaf 可能提前抢空槽；要严格按 sub-issues 列表顺序就用 phaseGate: true。
16. 每个 leaf issue 开始前，检查是否存在残留 worktree/branch；没有残留就跳过 Recover 直接 Plan。
17. 有残留时启动 Recover（会话继承模型）判断 continue 或 discard；continue 则检出已有 branch，把 done/remaining/broken 摘要交给 Implement 继续，跳过 Plan；discard 则删除 worktree 和 branch，走常规 Plan → Implement（新 branch）。
18. Recover 绝不直接进 Review；继续作业必须走 Implement → Review → Merge。
19. 删除旧 worktree 需同时满足两个条件：Recover 返回 wipCommitted: true，且 host 启动的只读安全确认 agent 确认该 worktree 的 git status --porcelain 输出为空；否则不删，failed 保全。
20. 旧 worktree 的清理和 implementing/reviewing 状态迁移若不能用状态更新返回值确认，则停止并 failed 保全；worktree 无但只有 branch 残留时不适用此 gate。
21. 每个 leaf issue 实现前，用一个只读、无 worktree 的 Plan agent 做 per-issue 计划，把计划作为参数传给 Implement，避免跨 worktree 读文件。
22. 计划内容包含：背景/目的、目标文件与改动点、按顺序可执行的实现步骤、验证方法（build/lint/test/动作确认）、OWASP Top 10 安全考虑。
23. Plan agent 异常退出或计划正文为空，则该 issue 记 failed 并继续。
24. Recover 判定 continue 时跳过 Plan。
25. 用独立 git worktree 隔离每个 implement/fix，post-order DFS 顺序作为优先级贪心填入空槽，最多并行 parallel（默认 3）个。
26. Implement 阶段不 push、不建 PR。
27. 各 issue 流程第 0 步：执行 worktree routing guard，用 git remote get-url origin 和 issue 标题核对当前 worktree 是否放对 repo/issue。
28. 第 0b 步：用 gh pr list --state open 找该 issue 对应的 open PR；有则获取其 branch 继续，不建新 PR，返回 branch 名，不做第 2 步的 checkout -B，否则会丢 PR 提交。
29. 若没有 open PR，用 git ls-remote --heads origin 查包含 issue 号的远程 branch（命名规范 <type>/<N>-<short-name>）；有则 git fetch origin <branch> && git checkout -B <branch> origin/<branch>，保留已 push 提交继续，不新建。
30. 只有 open PR 和远程 branch 都不存在时，才新建 branch：git fetch origin && git checkout -B feat/<N>-<short-name> origin/<base-branch>。
31. 在隔离 worktree 里先确认 git status 干净；有 diff 就不工作直接失败。
32. 按 Plan 计划实现；按目标仓库的 delegation 规则/专家子代理分配角色。
33. 代码注释写 why 和该符号在包/服务中的角色，以及调用方/被调用方/边界；有 .claude/rules/code-comment-style.md 则遵循。
34. 按目标仓库 CLAUDE.md、rules、测试规范跑 build/lint/test；失败时先调查根因再修，有 .claude/rules/debugging.md 按其 4 阶段，没有也按调查→分析→假设→修正；同一处失败 3 次则判架构问题，记 blocked 并报告用户。
35. 实现后按 OWASP Top 10 做安全检查（硬编码 API key、注入等），发现问题先修再继续。
36. 用 create-commit skill 按 Conventional Commits 只创建 1 个实现提交；提交前读目标仓库 commitlint 配置（commitlint.config.* / .commitlintrc* / package.json 的 commitlint 字段）确认 type-enum / scope-enum，只用允许值；没有对应 scope 就省略 scope；scope 不要放 issue 号；用 footer Refs #N 关联，PR 正文用 Closes #N。
37. push 前 base 更新 gate 产生的 base 合并提交也用同样方式决定 type/scope；被 commit-msg hook 拒则 git merge --abort 并 fail-closed，不 push。
38. 实现完成后停在本地分支有提交的状态，交给 Review。
39. Implement 后 push 前，在 worktree 隔离启动独立 Review agent，只审本地 diff，Review agent 不做修改只判定。
40. Review 分两阶段：先规格符合（满足 issue 要求/验收条件、无 out-of-scope 实现、按 Plan 实现），通过后再代码质量（可读性/重复/设计/命名/架构、OWASP Top 10）。
41. Review 前用 git checkout --detach <branch> 取本地分支，push 前 origin/<branch> 不存在。
42. 每次 review 前必须执行一次 git fetch origin <base-branch>:refs/remotes/origin/<base-branch> 更新比较基准，必须显式写 refspec；fetch 失败或 fetch 后仍无法 resolve 则不 review，返回 blocked / highestSeverity none，fail-closed。
43. 用 git diff origin/<base-branch>...HEAD 看本地 diff；比较点由 3 点确定在 merge-base，origin 后续前进不改比较点。
44. Low（要改善）也只要有 1 条就返回 needs-fix；无指出则 ok。
45. ok 则走 push + PR 创建后进 Merge；needs-fix 则 fix agent 只在本地重新提交并再 review，不 push。
46. Review 最多 3 次；第 3 次（剩余 0 次）needs-fix 不再 fix，判收敛失败；3 次未收敛则 push 和 PR 都不做，记 blocked 并进下一个 issue；blocked 要把残留 worktree/branch/最终指出汇总到报告。
47. Review / Merge 的 fix 共用 fixCount（上限 6）；base 冲突解消不消耗 fixCount，使用独立 baseMergeCount（上限 maxBaseMerges，默认 3）。
48. Review 全部 ok 后才执行唯一一次 push，这个 push 会触发 CI：git push origin <branch>。
49. push 成功后、gh pr create 前，用 gh pr list --state open --head <branch> --json number,baseRefName,headRefOid 检查是否已有针对该 branch 的 open PR。
50. 只有 baseRefName 与指定 base 一致且 headRefOid 与刚 push 的 branch 头部 sha 一致时才复用该 PR 号；sha 必须从 branch ref 解析（git rev-parse --verify 'refs/heads/<branch>'，失败则 'refs/remotes/origin/<branch>'），不能用 git rev-parse HEAD。
51. 复用 PR 且正文缺 Closes #N 及 out-of-scope 节时追加；追加时不要把既有正文嵌入 shell 命令串或 HEREDOC，用 gh pr view <N> --json body --jq .body > "$f" 落到文件，grep -qF 确认，printf/固定模板追加，最后 gh pr edit <N> --body-file "$f"。
52. 没有可复用 PR 时用 gh pr create --base <branch> --title 'feat: issue 标题' --body ... 创建，正文含 Summary 和 Closes #N。
53. 条件不符的 open PR 存在时，既不复用也不新建，返回 prNumber: 0 和理由停止。
54. PR 创建失败记 failed 并保存 branch；branch 已保存的 failed 下次重跑触发 Recover；continue 时回复 Implement 第 2 步后先 git fetch origin <branch>:refs/remotes/origin/<branch> → git merge --ff-only refs/remotes/origin/<branch> 追到远程 tip，保留已 push 的 base 合并提交；ff 不可的真 diverged 继续，由下次 PR 创建 fail-closed 阻止。
55. 用 gh pr checks <N> --watch --interval 60 盯 CI；watch 结束后必须再执行 gh pr checks <N> 列出全部检查结论，不能只以 watch 结束作为合格。
56. CI 合格条件：全部检查 success/neutral/skipped 且 failure/cancelled/timed_out 0 件、pending/queued/in_progress 0 件，且检查总数 >=1；checks 总数 0 不算 green，监视侧最多 10 分钟再确认后 blocked(quality)，merge-exec 侧以 checks-not-green 辞退。
57. 例外：state=OPEN 且 mergeable=CONFLICTING 的 PR 即使检查总数 0 也不进 blocked，直接走 conflicting 的 base 合并专用 agent（独立 baseMergeCount，不耗 fixCount）；mergeable=UNKNOWN 视为计算中，不当作 CONFLICTING。
58. 监视侧在 gh pr checks --watch 前先取 head 的检查总数（check-run + commit status 合计）；确定 0 件就直接进总数 0 判定，不空等；取不到总数就不当 0 件、省略 checksTotal 进 --watch。
59. gh pr checks --watch 重试 4 次用尽也不返回 timeout，而进总数确认；只有检查存在但 pending 到监视上限才返回 timeout；host 不接受 checksTotal:0 的 timeout，会再判 conflicting。
60. 外部检查按 externalChecks 四分支：未指定→不管 CI 结果一律 blocked 停，且 host 侧也 gate 新合并；[]→跳过外部评审等待，只看 CI green 和无未解决线程；指定 app+context→按指定 App 验证 HEAD sha 的启动，优先于观测结果。
61. cursor 的等待流程：HEAD sha 无评审时只催一次 @cursor review，不重复；Bugbot 自动跑时 0 条指出只发 check-run 不发评审，所以不能把评审缺失当无指出；check-run 只用于判断可催促时机（queued/in_progress 就等）和失败检测（非允许 conclusion 则 needs-fix）；HEAD sha 的 cursor[bot] 评审最多等 10 分钟，来了等指出解决再 merge；不来则 blocked，不跳过 gate。
62. cursor 以外外部 App（如 sonarcloud）：不能只信 gh pr checks --watch，必须确认 HEAD sha 对该 App 有 check-run 启动；0 件则最多等 10 分钟再确认，仍 0 件则 blocked；也可用 <slug>[bot] 评审回退，但评审要验证 state：仅 APPROVED >=1 且 CHANGES_REQUESTED/COMMENTED/PENDING =0 才合格；DISMISSED 不计。
63. 检查 HEAD sha 的 cursor[bot] 评审：gh api --paginate 'repos/{owner}/{repo}/pulls/<pr>/reviews' --jq 筛选 user.login == "cursor[bot]" 且 commit_id == HEAD_SHA，计数，必须 --paginate。
64. 检查其他 App 的 check-run：gh api --paginate 'repos/{owner}/{repo}/commits/<HEAD_SHA>/check-runs' --jq 筛 .app.slug == "sonarcloud"，按 conclusion/status 分组计数；输出只取状态 enum 件数，不取 check 名/description。
65. 未解决评审线程：用 GraphQL reviewThreads(first:100, after:$cursor) 迭代全页，条件是全部 isResolved。
66. 只有 CI 全 green、外部检查无指出（或 externalChecks: [] 确定无）、未解决评审线程 0 时，才可 squash merge。
67. autoMerge 默认 false：即使 monitor 返回 ready 也不执行新 merge，PR 停在可合并 blocked(quality) + 保留 pr；由人类在 GitHub merge，或交给服务器端 auto-merge workflow（docs/implement-issue-tree/auto-merge-sample.yml）+ branch protection。
68. autoMerge: true 且 externalChecks 确定（含全部 App 的可信 context 声明）时，merge-exec 自己重新取 HEAD sha、检查状态件数、未解决线程数、外部检查件数/状态 enum，并过 G0 服务器强制检查（ruleset bypass_actors 为空、required checks 不可绕过、评审线程解决必须、合格判定 context 的 required 化、外部 App 声明 context + App ID 绑定、全 required checks issuer integration_id 绑定；classic branch protection only 则 classic-unsupported；验证不了则 server-enforcement-missing blocked）。
69. 通过后执行 gh pr merge <N> --squash --delete-branch --match-head-commit <自己取的 sha>；再用独立只读 merge-verify agent 执行 gh pr view <N> --json state,headRefOid,mergeCommit，确认 state=MERGED 且 sha 一致；只有通过才终态 merged；否则 blocked(quality) fail-closed。
70. merge-exec 不读评审正文、issue 正文、check 名、仓库内可能被 PR 改的文件（CLAUDE.md/.claude/rules 等）；只取 state/headRefOid/mergeable、检查状态件数、未解决线程数、外部 App 件数/状态 enum。
71. merge-exec 的 HEAD sha 自取固定，不从 monitor 接收；monitor 的 ready 只用做起动时机，headSha 只作诊断记录。
72. 若 merge 成功但 issue 未关闭（issueClosed: false），不终态 merged；继续再监视重试关闭，监视次数用尽则 PR 已 merge 但关闭未确认 blocked，下次 monitoring 恢复。
73. 驳回理由映射：head-moved/checks-not-green/merge-failed → 再监视；unresolved-threads → fix 循环（若手上无结构化线程列表则不启动 fix，再监视让 monitor 收集）；not-mergeable → conflicting（base 合并专用 agent，独立 baseMergeCount）；wrong-target/pr-closed → blocked；external-review-missing → blocked 并附解决提示；enum 外 → systemic failure。
74. fix agent 在 detached HEAD 取目标 branch，先 git fetch → git merge base 再提交并再 push；fix 在 worktree 隔离运行，不干扰其他并行 issue branch。
75. base 合并专用 loop：从创建时就冲突（monitor 报 mergeable: CONFLICTING，或 merge-exec 报 not-mergeable）的 PR 不进入 fix loop，启动 baseMergePrompt；该 agent 只做取入 base/提交/push，不修改评审指出、不 resolve 线程、不编辑 PR 正文；冲突一律不解决（普通文件内容冲突不编辑，submodule gitlink 冲突也不解），返回 commitFailed: true；有 conflict:true 时 host 转交 fix 路径（带 build/lint/test 验证、fixCount 有界）。
76. base 合并提交 subject 使用 host 固定字面量 'chore: base ブランチの変更を取り込む'；base 合并 agent 不读 commitlint 配置/提交历史等仓库内文件；被 commit-msg hook 拒（hookRejected: true）则交 fix 路径处理；无 conflict/hookRejected 的 commitFailed 按 failed 终止。
77. push 后取 gh pr view 的 mergeable，UNKNOWN 则重试，并记录 mergeableAfter（只日志，不用于 merge 判定，下一轮 monitor 再观测）；同时记录 push 后 head 的 check-run 是否启动（checksStarted，只日志）。
78. baseMergeCount 达 maxBaseMerges 时 blocked(quality) 终止（不 halt 计数），下次运行 monitoring 重开同一 PR；baseMergeCount 从状态文件继承并 clamp 到 maxBaseMerges，不重置；人工直接向 PR branch 取入 base 并 push 可解决。
79. 监视通常最多 7 次；强制线程再扫描的拯救轮只延长 1 次，整个执行绝对上限 8 次；push 后 CI 启动确认报告 mergeableAfterPush: CONFLICTING 的一轮不启动 monitor，不耗监视配额。
80. 连续 2 轮既无 push 也无新线程 resolve 的 issue 记 blocked；有 push 路径外但报告了已监视却未计入的 threadId resolve 的轮次视为有进展，重置连续计数并继续再监视。
81. monitor 返回 blocked 时必须带 blockedReason（quality/unrecoverable），host 也双重校验 enum；quality→状态文件 blocked 且下次 monitoring 可恢复；unrecoverable→failed 且不可恢复；缺/enum 外按 unrecoverable 处理。
82. fix 上限 6 到达时分类：unresolved-comments → quality（可恢复，人工 resolve 可解）；needs-fix → unrecoverable（failed 不可恢复）；baseMergeCount 上限到达 → quality（人工直接 push base 取入可解）。
83. StructuredOutput 未返回（agent 异常/null）时，在 Merge loop 内（PR 已存在）记 blocked（下次 monitoring 恢复），不要 failed（避免重复建 PR）；root 节点（verify-close）同样 blocked，下次运行再跑 verify-close。
84. 强制线程再扫描拯救轮：merge-exec 返回 unresolved-threads 且手上无线程内容列表时，host 不启动 fix，置 forceThreadRescan 让下一轮 monitor 强制重扫；若监视预算已尽，整个执行只延长 1 次监视配额，第 2 次不再延长。
85. 拯救轮中途终止分类在监视循环退出后单一位置评估一次：monitor 自身观测失败返回的 timeout → blocked（halt 不计，下次 monitoring 恢复）；同一拯救轮 merge-exec 来的 timeout 映射（head-moved/checks-not-green/merge-failed）→ failed（halt 计）。
86. 全检查看起来 pass 但 merge 不前进时，按 cancel 残留 check 分支查：gh pr checks 全 pass、mergeable MERGEABLE、无冲突无未解决线程但 mergeStateStatus=BLOCKED 且 merge-exec 不推进。
87. 用 (A) 命令检测重名 check-run：独立取得 gh api --paginate 'repos/{owner}/{repo}/commits/<sha>/check-runs?per_page=100'，先判 exit code 和空输出，再用 awk 统计 dup/bad/pend；输出仅允许 ^UNDETERMINED$ 或 ^dup=[0-9]+ bad=[0-9]+ pend=[0-9]+$；取得失败、空输出、格式不合均为 UNDETERMINED，不 rerun，blocked(quality)。
88. 读 A 结果：D>=1 且 P>=1 → 等 pending 完成再监视，不 rerun；D>=1 且 P=0 且 B>=1 → 进 rerun 对象唯一化；D>=1 且 B=0 且 P=0 → 重名都是正常重跑，不 rerun，转查 BLOCKED 其他原因。
89. rerun 对象唯一化：用 (B) 人间诊断专用命令（需外部 jq；gh --paginate --slurp 生 JSON 管道给 jq，按 name group_by，保留 length>=2，再列 conclusion 内訳）确认重名，再用 gh api 'repos/OWNER/REPO/actions/runs?head_sha=<sha>&per_page=100' 筛 conclusion=cancelled 列 run，用 gh api 'repos/OWNER/REPO/actions/runs/<id>/jobs?per_page=100' 对 job 名与该重名 check 匹配；cancelled run 多个无法唯一或 0 个则 blocked，不 rerun。
90. 唯一配合的 run 才执行 gh run rerun <run-id> -R OWNER/REPO（不加 --failed）；rerun 后必须再列全检查结论，满足 success/neutral/skipped、无 pending、检查总数 >=1 才判合格，否则 blocked。
91. (A) 的执行要求：awk 不存在则 UNDETERMINED 且不执行 fetch；jq 不存在则 (B) 不执行且 blocked；不要用 --jq 跨页聚合，必须用 shell awk/jq 全页聚合。
92. monitor/merge-exec 不执行 (B)（检查名是外部文本），只有人间诊断可用。
93. 有子的父节点在所有子 issue 完成后执行：gh api --paginate 'repos/{owner}/{repo}/issues/<parent>/sub_issues?per_page=100' 确认全部 closed，gh issue view <parent> 读验收标准，满足则 gh issue close <parent> --comment '配下のサブイシューがすべて実装・マージ完了。受入基準を確認してクローズ。'，还有 open 子或验收未达则 failed。
94. 父节点在所有子完成前不投入，子在并行完成后验证。
95. 生成最终报告：汇总所有 issue 结果；1 个 issue 失败不停，3 个连续完不成则 halt（停止新着手），halt 后未着手记 not-started。
96. out-of-scope 项目在各 PR 正文的対象外（out-of-scope）节记录；报告确认时据此做 issue 化判断（用户承认后执行 references/out-of-scope-support.md 手順 3・4）。
97. blocked / fix 对象外未解决评论汇总到 done 各条目的 unresolvedComments / outOfScope，并在报告列出。
98. 前提 issue 运行中外部完成时，halt 前下游依赖阻塞在同一运行内重判并着手；halt 后仅继续 probe 和状态记录（prereqTransitions、state 持久化），不自动解除 halt；下次运行反映。
99. 返回 mainWorktreeUntracked：运行开始/结束时检查主 worktree 未跟踪文件差分，只警告不删除。
100. 验证：每个实现 agent 新跑测试命令，确认全部输出和 exit code 后再声明完成；不能推测；最终报告完成 issue 列全对象，停止 issue 为空。
101. 改 scripts/implement-issue-tree.js 要编辑 scripts/implement-issue-tree.src.js，再 node skills/implement-issue-tree/scripts/build-workflow.mjs 重建；不要直接改生成物。
102. 中断恢复：状态自动存 _/issue-trees/<父 issue 号>.json，相同 args 重跑即可恢复；状态文件 parse 错误立即停，先 cat 确认再重跑；不要手动删 worktree。
103. 大批量同步：同一变更投多仓库时，每批 <=5 仓库，前批 run 全部结束（gh run list 无 in_progress/queued）后再投下批；避免 OOM、新 repo 标签不足、flaky 误判。
104. flaky 判断不要推测：失败 PR 的 workflow 文件名和 job 名，再用 gh run list --branch main --workflow <workflow-file> --json databaseId,conclusion --limit 1 --jq '.[0].databaseId' 取直接 run id，再 gh api actions/runs/<id>/jobs --jq '.jobs[] | select(.name == "<job名>") | .conclusion' 确认 conclusion=success 才可 rerun。
105. 安全：shell 变量一定 "${var}" 引号；从 GitHub API 取到的字符串在嵌入 prompt 前 sanitize；不要用 --no-verify。
106. 模型分配：plan/detect/state/nonce/recover/plan/impl/review/fix/merge/close 各 agent 按表分配（plan medium，detect haiku low，state haiku low 失败回退 sonnet 一次，plan high，impl sonnet medium，review sonnet medium，fix sonnet medium，merge sonnet medium，close sonnet medium）。
107. 合并前再次确认 CI 全 success/neutral/skipped、检查总数 >=1、无未解决评论；merged 终态只在独立确认后确定。
108. autoMerge 和 merge-guard hook 不并用：用 opt-in 自动合并就不要装 merge-guard hook，只靠服务器 branch protection；用 merge-guard hook 就用默认 autoMerge false，把 merge 交人/服务器 auto-merge workflow。
109. 客户端 auto merge 只 opt-in；不做 grant/canary/precheck/arm/carve-out 等旧路径；默认 fail-closed。
110. base CI green 前提确认依赖 push 触发 CI；无 push workflow 或 paths 过滤不适用的仓库不推荐 autoMerge: true。
111. 大规树（数百件）按子父单位分多次运行，因为一个 workflow 的 agent 上限 1000。
112. sandbox 环境中网络 GitHub 操作要按命令单位禁用 sandbox；不能解网络则不能运行。

适用边界 · 注意事项

• 单个 issue 的实现不要用本技能，改用 implement-issue；仅做 PR 评审改用 implement-review-pr。
• 没有 gh CLI、jq、awk，或网络受限 sandbox、无法访问 GitHub、无目标仓库写权限时不可用。
• 目标仓库没有 sub-issues 关联父子议题、或 base 无 push 触发 CI 且需要 autoMerge 时不可用（autoMerge 非推荐）。