review-fix-address-bots

审查、修复并处理机器人

按顺序执行以下阶段。只有主 Agent 负责判断、编辑、会修改工作区的命令、验证、Git、PR 变更和机器人回复。

不变量

• 审查者仅提供建议，并且必须严格只读。他们可以检查文件、差异、历史记录、测试和现有输出，但不得修改文件或 Git/PR 状态；不得运行测试、构建、软件包脚本、生成器或任意仓库命令；也不得委派实现工作。
• 在每条审查者提示词中都包含以下边界：“以只读模式操作。你仅提供建议。绝不修改工作区或 Git/PR 状态，也绝不提交或推送。将发现和批评意见返回给主 Agent，由主 Agent 做最终决定。”
• 保留无关的用户变更。绝不使用 reset、自动暂存、广泛暂存、重写历史或检查点提交来清理脏工作树。
• 日志记录仅用于观察。如果记录失败，报告失败并继续安全工作流；绝不因遥测而更改代码、判断、Git/PR 状态或循环限制。
• 将 scripts/review-run-log.mjs 视为不透明的可执行文件。在此工作流中绝不读取其源代码。调用其文档说明的命令，并使用 templates、--help 和 Markdown 参考文档；只有用户明确要求调试或修改该辅助工具时，才检查或更改其源代码。

1. 准备集成后的目标

1. 阅读仓库说明和适用的实现技能。记录分支、状态、目标、远程仓库、上游、PR 状态以及初始脏状态的归属边界。推送前必须有一个命名的非目标分支；未经明确授权，绝不重命名分支或推送默认分支。
2. 使用用户提供的审查提示词。如果用户要求的自定义提示词不可用，则停止并索取该提示词。仅当用户未要求提示词时，才阅读 references/review-guidelines.md。
3. 解析此技能的目录，并运行 node <skill-dir>/scripts/review-run-log.mjs templates 获取标准载荷，然后使用已解析的评审组和限制运行 start，再开始审查。将其 logPath 保存在 .context 中；记录重要状态转换和每次审查者调用。仅当辅助工具拒绝记录、需要扩展日志功能或必须诊断遥测行为时，才阅读 references/run-logging.md。
4. 一并检查已提交、已暂存、未暂存和相关的未跟踪变更。优先使用 Conductor 的工作区差异；否则检查从合并基点到 HEAD 的差异、git diff HEAD、git status --short 和相关的未跟踪文件。将无关的用户工作排除在实现之外。
5. 确定 PR 实际使用的基分支和仓库远程；如果没有 PR，则使用仓库配置。显式获取该基分支，并记录其引用和 SHA；不要使用 git pull。如果获取到的 SHA 不是 HEAD 的祖先，则在正式审查前集成它；默认使用显式合并。仅在有要求或确有必要时才变基，未经授权绝不重写已发布的历史记录。
6. 不要让预先暂存的变更进入合并提交。如果脏工作会使集成不安全，则停止。根据两个分支的意图、周边代码和测试解决冲突；涉及重要的产品、UX、公共 API 或架构选择时，请求意见。集成后的工作树（包括冲突解决结果）即为审查目标。如果在审查开始后进行集成，则所有报告均失效，必须重新运行整组审查。
7. 首次推送前，如果机器人阶段需要创建 PR，则确认是否有权创建 PR。未获得授权时，在执行远程变更之前停止。

Reviewer 会话

明确遵循用户指定的 Reviewer 数量、模型组合和推理等级。否则，每次初始审查和修复审查都使用以下默认 Reviewer 组：

Reviewer ID	模型	推理等级
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

数量为 1 到 5 时，按上述顺序使用。对于其他明确指定的组合，使用模型层级加从 1 开始的序号分配稳定 ID。如果数量超过 5，但组合信息不明确，则询问用户要使用何种组合。将任务名称从 sol-1 规范化为 sol_1，以便进行确定性发现。对整个 Reviewer 组使用相同的原始审查提示词、目标指纹、角色边界和服务层级；每位 Reviewer 使用其指定的推理等级。达到并发限制时排队，不得编辑目标内容。

数据包

不得向 Reviewer 发送此技能、任何参考资料、辅助命令、运行日志详情或主对话内容。提供给每位 Reviewer 的数据包必须相同且自包含，且仅包含审查任务：原始用户提示词（或默认标准）、目标 SHA 和工作区指纹、相关范围／差异或路径（如适用的）冲突摘要、只读边界，以及所需的发现格式（文件、最小行范围、严重程度、场景、理由）。排除其他 Reviewer 的发现、主审查者的结论、修复决定和遥测说明。

启动与验证

使用 fork_turns: "none" 启动每位初始 Reviewer，并提供其自包含的数据包以及指定的模型和推理等级；不得分叉主对话。要求运行时公开确切的已应用控制项以及稳定的可恢复句柄。根据运行时证据验证已应用的设置，而非仅凭请求参数验证。

在运行时允许的情况下并发启动。不得使用临时 Reviewer。控制项验证失败时，必须阻止编辑并以 blocked 状态结束；绝不能将请求参数本身视为验证结果。句柄可用时立即记录 reviewer_session_started；只有在持久化验证完成后，才记录 reviewer_session_controls_verified。仅当运行时公开了已完成任务的 durationMs 时，才记录该值。

观察、恢复并清理停滞的工作线程

每次有界等待后（默认为 30 秒），运行队列监视器。这是最长轮询间隔，而非运行时长下限：任务完成后立即处理。

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

软截止时间只是警告。默认硬截止时间为 20 分钟；Luna 审核者的硬截止时间为 30 分钟。硬截止时间从当前的 task_started（若不存在，则从会话开始时）起算。在将审核者判定为失败之前，请检查其确切的持久化会话。active、stalled 和单个 in_progress 结果不代表失败。监视器不会中断工作线程。

对于超过硬截止时间的审核者，请立即再次检查确切会话。如果会话仍未进入终止状态，请使用检查结果中的 nativeHandle 调用 agents.interrupt_agent，绝不要使用其持久化的 sessionId；使用 agents.list_agents 确认其已停止；然后追加记录 reviewer_session_cancelled，其中包含审核者 ID、持久化会话 ID、原生句柄、阶段、原因和所应用的截止时间。绝不要使用宽泛的终止操作、打断其他审核者，或对初始审核进行后续探测。一次新的初始重试可以使用不同的任务名称，例如 sol_1_retry_1，但仍保留审核者 ID sol-1。

如果该重试也超过硬截止时间，则将审核者标记为已耗尽，并将其排除在连续性验证和修复之外。保留每一份已完成的审核，并使用这些审核者继续工作流；本次运行状态为 partial，但仅超时不得阻止编辑或丢弃其发现。仅当没有任何初始审核完成，或其他安全或完整性条件阻止继续时，才应阻止后续操作。超过硬截止时间的连续性会话在清理确切句柄后，须遵循完整队列重启规则。

如果结果缺失或无法读取，请在重试前检查确切会话：

node scripts/review-run-log.mjs inspect-native-session --log "$REVIEW_RUN_LOG" --reviewer-id "$REVIEWER_ID" --stale-after-ms 120000

恢复的结果必须与恰好一个审核者句柄、仓库、所应用的控制措施以及已完成的最终回答事件完全匹配。使用恢复出的回答，但绝不记录审核正文。只有在检查结果为 unavailable 后才重试，并遵循上述硬截止时间清理流程。将原始结果保存在运行日志之外；只记录简明的观察和结果。

保持会话连续性

修复前，创建一个被 git 忽略的 .context/reviewer-sessions.json 账本，其中包含稳定的审核者 ID、请求及已应用的控制措施、审核者句柄、初始指纹和连续性状态。绝不存储凭据、提示词或审核正文。编辑前，使用原始控制措施和只读边界恢复每个已完成初始审核的会话；只要求 SESSION_CONTINUITY_OK。将已耗尽的审核者记录为排除，不要恢复其会话。若有可用信息，则记录已完成任务的耗时。如果任何必需的握手失败，则丢弃所有报告，并针对未变更的目标重新启动完整队列一次；第二次失败则阻止编辑。修复只能使用已通过连续性验证的句柄。

2. 独立开展初始审查

1. 解析用户要求的评审组，或采用上述默认评审组，并保持不变。如果运行时无法验证所要求/实际使用的精确模型、推理级别或持久句柄，则停止；绝不悄悄替换。
2. 向每位审查者提供相同的自包含原始提示词、集成后的目标 SHA 和指纹、冲突摘要及角色边界。不得透露其他审查者的发现或主 Agent 的结论。要求每条发现都包含文件、最小行范围、严重程度、场景和理由。
3. 对 HEAD、暂存/未暂存差异、状态及相关未跟踪内容生成指纹。在所有初始报告和连续性检查完成前，保持目标不变。尽可能并行启动，其余审查按原样排队。遵守上述启动、看门狗、恢复和硬性截止时间清理规则。
4. 使用上述规范字段记录每次启动、控制验证、观察、取消，以及已完成或失败的审查轮次。使用稳定的审查者 ID 和发现 ID。仅在实际提供时记录实际 token 用量和 durationMs。
5. 处理截止时间后，要求至少有一轮初始审查已完成。编辑前，对每位已完成审查的审查者执行上述连续性协议；某位审查者耗尽额度不影响其他审查者。
6. 握手完成后验证目标指纹。如果发生意外变更，检查归属并针对稳定目标重新运行一次完整评审组。反复不稳定属于阻塞问题。

3. 验证发现并修复

1. 按缺陷去重，同时保留报告该问题的审查者/模型。根据当前代码、测试和惯例独立核查每项主张。
2. 将每项发现分类为 valid、duplicate、already_fixed_or_stale、false_positive、out_of_scope_user_change 或 needs_user_decision；记录其稳定 ID 和处置结果。
3. 修复所有有效且范围内的问题，条件允许时添加有针对性的回归测试，运行范围较窄的检查，并对最终差异进行自审。对于重大的产品、UX、公共 API 或架构决策，应征求意见，而不是擅自决定。

4. 针对修复恢复审查

使用原有控制和只读边界，恢复每个已通过连续性验证的会话。未经用户授权，绝不使用临时或替换会话。

1. 冻结工作区并生成指纹。向每位审查者提供更新后的差异，以及涵盖所有发现、分类、证据、变更或拒绝理由、测试和先前异议的累积台账。
2. 询问根本原因是否已修复、是否仍存在回归或相关情况、是否有实质上更简单且范围明确的方案、测试是否覆盖故障，以及是否应重新考虑被拒绝的发现。可执行的异议必须指出具体故障模式、受影响代码，或经证明更优且范围明确的替代方案。
3. 独立评估每项回复。最多进行三轮修复；当所有审查者都认为修复充分，或剩余异议已有证据支持的处置结果时停止。有效异议出现后，应逐轮扩大审查范围：第 1 轮检查针对性修复/调用点，第 2 轮检查相关模块边界/集成，第 3 轮检查子系统不变量/设计替代方案/覆盖缺口。
4. 记录每轮审查，包括无发现的轮次和重试。每轮结束后验证指纹。如果审查者修改了状态，主 Agent 应安全地仅还原该影响、丢弃报告，并以只读方式重试一次；再次发生修改即为阻塞问题。

5. 验证、提交并推送

1. 仅暂存自己负责的文件或代码块，并检查暂存区差异。
2. 按以下顺序进行最终验证：用户明确指定的命令；仓库/CI 指令；否则，使用 packageManager 或锁文件指定的包管理器运行已更改工作区的脚本。若存在 precommit，则运行它；否则运行所有可用的 lint 和 test。对于非 JavaScript 项目，使用文档中说明的 CI 等效检查；若某些覆盖范围不可用，应如实报告，而不要自行编造命令。
3. 按照仓库工作流提交，然后在每次推送前，针对提交后的确切代码树运行最终验证。纳入预期的工具生成更改，并在任何修改后重新运行验证。诊断由分支导致的失败，但不要修改无关工作；不要推送未通过验证的代码树。
4. 确认所有权边界。推送前立即在 .context 中记录 PR 编号、UTC 审查窗口时间戳和提交 SHA；若推送失败，则更新记录。推送时不要重命名分支，并确认 PR head 与已验证的 SHA 一致。

6. 完成审查机器人闭环

1. 查找并阅读仓库的 address-review-bots 技能；不要硬编码其他工作区的路径。确认 PR 仍以记录的分支和 SHA 为目标，并在支持时传入推送时间戳。
2. 等待该 SHA 上所有已请求的机器人完成审查。缺少审查结果或超时应视为未知，而非通过；head 意外变更时，必须重新核对所有权。
3. 对每条实质性意见进行分类，修复有效、可操作且风险较低的清理问题，进行自我审查、提交、重新运行最终验证并推送。按照 address-review-bots 重复此流程，直到审查通过、需要做出决定、达到循环次数上限或检查超时。

完成并报告

无论运行受阻还是失败，都必须尝试执行 finish，并使用从事件中得出的审查者/发现，以及实际的机器人、验证、状态和 SHA 结果。若排除了一名或多名已耗尽的审查者，但其余已完成的审查者仍完成了工作流，则使用 partial；只有确实导致流程停止时，才使用 blocked 或 failed。使用 --collect-codex-usage；用量按审查者分别收集，因此即使另一名工作者不可用，已完成的会话仍会计入实际 token、成本和耗时。

当某位审查者既没有 token 数，也没有精确耗时时，运行 diagnose-codex-usage。修复可恢复的会话或账本不匹配，但不要仅为补全遥测数据而重新启动已耗尽的审查者。只有通过遥测门槛时，才使用 report 生成用量部分。否则，省略生成的表格，并报告被排除的审查者以及已完成审查者的覆盖情况，不要编造数值。将模型比较视为单次运行的观察结果。

报告已应用的审查者群组/控制项、持久会话与连续性/重试情况、已耗尽的审查者、日志路径及推导出的调用/轮次/用量覆盖情况、共有/独有发现和模型比较、基础 SHA/集成/冲突、所有发现的处理结果、修复轮次和分歧、每次推送的验证结果、提交/PR、机器人闭环结果以及剩余阻碍。report 会拒绝遥测数据不完整的审查者群组；只有成功后才能原样附上其表格。不要添加定价或遥测方面的注意事项。将 Estimated cost 紧接在 Total 之后，并将 Agent time 放在最后；其后不得添加任何内容。

资源

• references/review-guidelines.md：默认审查标准。
• references/run-logging.md：日志记录器故障排查、扩展和指标语义。
• scripts/review-run-log.mjs：规范载荷、只追加日志、指标和最终报告。