在 PR 评审-修复-推送闭环中编排只读多…

需要在已有 PR/分支上集成 base、运行多只读 reviewer、修复发现、处理 review bots 并按仓库命令验证推送时使用。

适用场景

解决思路

1. 按顺序执行各阶段；只有 primary agent 拥有判断、编辑、修改工作区的命令、验证、Git、PR 变更和 bot 回复的责任。
2. 让 reviewer 仅作建议且严格只读：可检查文件、diff、历史、测试和现有输出，但不得修改文件或 Git/PR 状态；不得运行测试、构建、package scripts、generators 或任意仓库命令；不得委托实现。
3. 在每个 reviewer prompt 中包含只读边界：“Operate in read-only mode. You are advisory only. Never modify the workspace or Git/PR state, and never commit or push. Return findings and critique to the primary agent, who makes the final decision.”
4. 保留无关用户更改；绝不用 reset、自动 stashing、广泛 staging、历史重写或 checkpoint commits 清理 dirty tree。
5. 将日志视为观察性操作；如果失败，报告失败并继续安全 workflow；绝不为 telemetry 更改代码、判断、Git/PR 状态或 loop limits。
6. 将 scripts/review-run-log.mjs 视为不透明可执行文件；在此 workflow 中绝不读取其源码；调用其文档化命令并使用 templates、--help 和 Markdown references；仅当用户明确要求调试或修改 helper 时检查或修改其源码。
7. 读取 repository instructions 和适用的 implementation skills。
8. 记录 branch、status、target、remotes、upstream、PR state 和初始 dirty-state ownership boundary。
9. 在 push 前要求有命名的非 target branch；未经明确授权绝不重命名它或推送 default branch。
10. 使用用户的 review prompt；如果请求的 custom prompt 不可用，停止等待它；仅当未请求 custom prompt 时才读取 references/review-guidelines.md。
11. 解析此 skill 的目录并运行 node <skill-dir>/scripts/review-run-log.mjs templates 获取 canonical payloads，然后在 review work 前用 resolved cohort 和 limits 运行 start。
12. 将其 logPath 保留在 .context；追加 material transitions 和每次 reviewer invocation。
13. 仅当 helper 拒绝记录、logging 需要扩展或必须诊断 telemetry behavior 时读取 references/run-logging.md。
14. 一起检查 committed、staged、unstaged 和相关 untracked changes。
15. 优先使用 Conductor 的 workspace diff；否则检查 merge-base-to-HEAD diff、git diff HEAD、git status --short 和相关 untracked files。
16. 从 implementation 中排除无关用户工作。
17. 解析 PR 的实际 base branch 和 repository remote；没有 PR 时使用 repository configuration。
18. 显式 fetch 该 base，记录其 ref 和 SHA，不使用 git pull。
19. 如果 fetched SHA 不是 HEAD 的 ancestor，在正式 review 前集成它，默认用显式 merge。
20. 仅在需要或被要求时 rebase；未经授权绝不重写已发布历史。
21. 不要让预先存在的 staged changes 进入 merge commit。
22. 如果 dirty work 使 integration 不安全，停止。
23. 根据两个分支的意图、周围代码和测试解决冲突；对重要产品、UX、public API 或 architecture 选择请求输入。
24. 将集成后的树（包括冲突解决）作为 review target。
25. 如果 integration 在 review 开始后发生，使所有报告失效并对 cohort 重跑。
26. 首次 push 前，如果无 PR 且 bot phase 需要 PR，解决创建 PR 的权限；当权限缺失时，在 remote mutation 前停止。
27. 若用户未明确指定 reviewer count、model mix 和 reasoning levels，则每次 initial 和 remediation pass 使用默认 cohort：sol-1=gpt-5.6-sol/high；terra-1=gpt-5.6-terra/xhigh；luna-1=gpt-5.6-luna/max；luna-2=gpt-5.6-luna/xhigh；luna-3=gpt-5.6-luna/xhigh。
28. 对于 1 到 5 的数量，按上述顺序使用；对于另一个明确 mix，用 model tier 加从 1 开始的 ordinal 分配稳定 ID；当数量大于 5 且未指定 mix 时，要求提供 mix。
29. 将任务名从 sol-1 规范化为 sol_1，便于确定性发现。
30. 在 cohort 中保持 raw review prompt、target fingerprint、role boundary 和 service tier 相同；使用每个 reviewer 被分配的 reasoning level。
31. 超过并发限制时排队，不修改 target。
32. 不要向 reviewer 发送此 skill、任何 reference、helper commands、run-log details 或 primary conversation。
33. 给每个 reviewer 相同的 self-contained packet，仅包含 review task：raw user prompt（或 default criteria）、target SHA 和 workspace fingerprint、相关 scope/diff 或 paths、适用时的 conflict summary、read-only boundary，以及 required finding format（file、minimal line range、severity、scenario、rationale）。
34. 从 packet 中排除其他 reviewers 的 findings、primary 的结论、remediation decisions 和 telemetry instructions。
35. 用 fork_turns: "none"、其 self-contained packet 和请求的 model 与 reasoning level 启动每个 initial reviewer；不要 fork primary conversation。
36. 要求 runtime 暴露 exact applied controls 和 stable resumable handle。
37. 从 runtime evidence 验证 applied settings，而不只是 requested arguments。
38. 在 runtime 允许时并发启动；绝不使用 ephemeral reviewer。
39. control verification 失败会阻止 editing 并结束为 blocked；绝不把 requested arguments 单独当作验证。
40. 一旦 handle 可用就记录 reviewer_session_started，仅在持久化验证后记录 reviewer_session_controls_verified。
41. 仅当 runtime 暴露时，记录 completed-task durationMs。
42. 每 bounded wait（默认 30 秒）后运行 cohort watcher；它是最大 polling interval，不是 runtime floor，应立刻处理 completions：node scripts/review-run-log.mjs inspect-reviewers --log "$REVIEW_RUN_LOG" --stale-after-ms 120000 --soft-deadline-ms 600000 --hard-deadline-ms 1200000 --hard-deadline-ms-by-model '{"gpt-5.6-luna":1800000}' --record
43. soft deadline 是警告。默认 hard deadline 是 20 分钟；Luna reviewers 是 30 分钟。hard deadline 从当前 task_started 开始（缺失时从 session start 开始）。
44. 在把 reviewer 归类为 failed 前，检查其 exact persisted session；active、stalled 和一个 in_progress result 不算失败；watcher 不中断 workers。
45. 对 hard-exceeded reviewer，立即再次检查 exact session；如果仍 non-terminal，用 inspection 的 nativeHandle 调用 agents.interrupt_agent，绝不用其 persisted sessionId；用 agents.list_agents 确认它已停止；然后追加 reviewer_session_cancelled，包含 reviewer ID、persisted session ID、native handle、phase、reason 和 applied deadline。
46. 绝不用 broad kill、中断另一个 reviewer，或用 follow-up 探测 initial review。
47. 一次 fresh initial retry 可用不同 task name，如 sol_1_retry_1，但保留 reviewer ID sol-1。
48. 如果该 retry 也超过 hard deadline，标记该 reviewer 为 exhausted，并从 continuity 和 remediation 中排除。
49. 保留每个 completed review，并继续用这些 reviewers 推进 workflow；run 为 partial，但仅 timeout 不得阻止 editing 或丢弃 findings。
50. 仅当没有 initial reviewer 完成，或其他安全/完整性条件阻止继续时才 block。
51. hard-exceeded continuity session 在清理 exact handle 后遵循 full-cohort restart rule。
52. 对 missing 或 unreadable result，重试前检查 exact session：node scripts/review-run-log.mjs inspect-native-session --log "$REVIEW_RUN_LOG" --reviewer-id "$REVIEWER_ID" --stale-after-ms 120000
53. 恢复的 result 必须精确匹配一个 reviewer handle、repository、applied controls 和 completed final-answer event；使用其 recovered answer，但绝不记录 review body。
54. 仅在 inspection 显示 unavailable 后重试，并遵循上面的 hard-deadline cleanup。
55. 将 raw results 放在 run log 外；只记录简洁 observations 和 outcomes。
56. 在 fixes 前，创建 gitignored .context/reviewer-sessions.json ledger，包含 stable reviewer ID、requested/applied controls、reviewer handle、initial fingerprint 和 continuity state。
57. 绝不在此 ledger 中存储 credentials、prompts 或 review bodies。
58. 在 editing 前，用 original controls 和 read-only boundary resume 每个完成 initial review 的 session；仅要求 SESSION_CONTINUITY_OK。
59. 将 exhausted reviewers 记录为 excluded，而不是 resume 它们。
60. 可用时记录 completed-task duration。
61. 如果任何 required handshake 失败，丢弃所有报告并对 unchanged target 重启 full cohort 一次；第二次失败阻止 editing。
62. Remediation 仅使用 continuity-verified handles。
63. 解析用户请求的 cohort 或使用上述默认 cohort，并保持固定。
64. 如果 runtime 无法验证 exact requested/applied model、reasoning level 或 persistent handle，停止；绝不静默替换。
65. 给每个 reviewer 相同的 self-contained raw prompt、integrated target SHA 和 fingerprint、conflict summary 和 role boundary。
66. 不要暴露另一个 reviewer 的 findings 或 primary-agent conclusions。
67. 要求每个 finding 包含 file、minimal line range、severity、scenario 和 rationale。
68. 对 HEAD、staged/unstaged diffs、status 和相关 untracked contents 做 fingerprint。
69. 在所有 initial reports 和 continuity checks 期间保持 target 不变。
70. 尽可能并发启动并 queue 其余为不变。
71. 应用 launch、watchdog、recovery 和 hard-deadline cleanup 规则。
72. 使用 canonical fields 记录每次 launch、control verification、observation、cancellation 和 completed/failed pass。
73. 使用稳定 reviewer 和 finding IDs。
74. 仅当 runtime 暴露时记录 actual token usage 和 durationMs。
75. deadline handling 后，要求至少一个 completed initial review。
76. 在 editing 前对每个 completed reviewer 应用 continuity protocol；exhausted reviewer 不使其他 reviewer 无效。
77. 在 handshakes 后验证 target fingerprint。
78. 如果发生 unexpected mutation，检查 ownership，并对 stable target 重跑 full cohort 一次；重复不稳定是 blocker。
79. 按 defect 去重，同时保留 reporting reviewers/models。
80. 独立对照 current code、tests 和 conventions 检查每个 claim。
81. 将每个 finding 分类为 valid、duplicate、already_fixed_or_stale、false_positive、out_of_scope_user_change 或 needs_user_decision；记录其稳定 ID 和 disposition。
82. 修复每个 valid in-scope issue。
83. 实际可行时添加 focused regression coverage。
84. 运行 narrow checks。
85. self-review 整个 resulting diff。
86. 请求输入，而不是发明重要 product、UX、public API 或 architecture 决策。
87. 用其 original controls 和 read-only boundary resume 每个 continuity-verified session；未经用户授权绝不用 ephemeral 或 replacement session。
88. Freeze 并 fingerprint workspace。
89. 给每个 reviewer updated diff 加上 cumulative ledger，包含所有 findings、classifications、evidence、changes 或 rejection reasons、tests 和 prior pushback。
90. 询问 root causes 是否已修复、regressions 或相关 cases 是否仍存在、是否有一个 materially simpler bounded solution、tests 是否覆盖 failure，或被拒 findings 是否值得重新考虑。
91. Actionable pushback 必须指出 concrete failure mode、affected code 或 demonstrably better bounded alternative。
92. 独立判断每个 response。
93. 最多运行三个 remediation rounds，当所有 reviewers 认为 fixes 足够或剩余 objections 有 evidence-backed dispositions 时停止。
94. valid pushback 后增加 scope：round 1 聚焦 fix/call sites；round 2 相关 module boundaries/integration；round 3 subsystem invariants/design alternatives/coverage gaps。
95. 记录每次 pass，包括 no-finding passes 和 retries。
96. 每次 pass 后验证 fingerprint。
97. 如果 reviewer 修改了 state，primary agent 安全地仅恢复该影响，丢弃 report，并只读重试一次；第二次 mutation 是 blocker。
98. 仅 stage owned files 或 hunks，并检查 staged diff。
99. 按此顺序解决 final validation：显式用户命令；repository/CI instruction；否则使用 changed workspace 的 scripts，按 packageManager 或 lockfile 指定的 package manager。
100. 存在时运行 precommit，否则运行每个可用的 lint 和 test。
101. 对非 JavaScript 项目使用文档化 CI-equivalent checks；报告不可用 coverage，而不是发明命令。
102. 用 repository workflow commit。
103. 每次 push 前对 exact post-commit tree 运行 final validation。
104. 纳入 intended tool-generated changes，并在任何 mutation 后重跑。
105. 诊断 branch-caused failures，不修改无关工作；不 push 失败树。
106. 确认 ownership boundaries。
107. push 前立即在 .context 记录 PR number、UTC review-window timestamp 和 commit SHA；失败尝试后刷新。
108. push 时不重命名 branch，并确认 PR head 等于 verified SHA。
109. 解析并读取 repository 的 address-review-bots skill；不要硬编码另一个 workspace 的 path。
110. 确认 PR 仍 target recorded branch 和 SHA，并在支持时传入 push timestamp。
111. 等待该 SHA 上每个 requested bot。
112. 缺失 review 或 timeout 是 unknown，不是 clean；unexpected head change 需要 ownership reconciliation。
113. 分类每个 substantive observation。
114. 修复 valid actionable 和 low-risk cleanup findings。
115. self-review、commit、重跑 final validation 并 push。
116. 按 address-review-bots 重复，直到 clean、需要 decision、达到其 loop limit 或 checks timeout。
117. 始终尝试 finish，即使 blocked/failed run，使用 event-derived reviewers/findings 加上实际 bot、validation、status 和 SHA outcomes。
118. 当一个或多个 exhausted reviewers 被排除但剩余 completed reviewers 推进 workflow 时使用 partial；blocked 或 failed 仅保留给实际停止 run 的条件。
119. 使用 --collect-codex-usage；collection 是 per reviewer，因此 completed sessions 在另一个 worker 不可用时仍贡献 real tokens、cost 和 duration。
120. 当 reviewer 同时缺少 tokens 和 exact duration 时运行 diagnose-codex-usage。
121. 修复可恢复的 session 或 ledger mismatch，但不要仅为填充 telemetry 而重新启动 exhausted reviewer。
122. 仅当其 telemetry gate 通过时用 report 生成 usage section；否则省略生成的 table，并报告 excluded reviewer 加上 completed-reviewer coverage，不编造 values。
123. 将 model comparisons 视为 one-run observations。
124. 报告 applied cohort/controls、persistent sessions 和 continuity/retries、exhausted reviewers、log path 和 derived invocation/round/usage coverage、shared/unique findings 和 model comparison、base SHA/integration/conflicts、所有 finding dispositions、remediation rounds 和 disagreements、validation per push、commits/PR、bot-loop outcomes 和 remaining blockers。
125. report 拒绝 incomplete-telemetry cohort，所以仅在其成功后逐字追加其 table。
126. 不要添加 pricing 或 telemetry caveats；保持 Estimated cost 紧接 Total 之后，Agent time 最后，其后不放置任何内容。
127. 资源：需要默认 review criteria 时读 references/review-guidelines.md；需要 logger 故障排查、扩展和 metric semantics 时读 references/run-logging.md；使用 scripts/review-run-log.mjs 获取 canonical payloads、append-only log、metrics 和 final report。

适用边界 · 注意事项

• 不适用于没有支持多 reviewer 持久会话、可验证 applied controls 和 nativeHandle 的运行环境时；否则无法满足启动验证、恢复和中断要求。
• 不适用于 reviewer 必须能够修改文件、运行仓库命令或提交/推送的场景；本流程要求严格只读且由 primary agent 独占变更。
• 不适用于需要未经授权重写已发布历史、清理 dirty tree、推送 default branch 或让预先 staged changes 进入 merge commit 的场景。