maintainer-orchestrator

维护者协调器

协调多个互不相关的问题、拉取请求或代码仓库中的实际维护者队列。这是一项控制平面技能，不是处理普通代码仓库工作的默认方式。

激活门槛——硬性规则

在创建工作者、心跳、台账或扫描队列之前，先对请求进行分类。

直接处理单项工作

当请求指定或暗示一个问题、一个 PR、一个 Bug、一个功能、一个版本发布，或一项连贯的实现时，即为单项工作，即使工作涉及多个文件、阶段、测试、CI 或紧密耦合的代码仓库。

对于单项工作：

• 不要仅仅因为任务并非易事，就创建项目工作者。
• 不要创建心跳、项目组合台账、队列补充、依赖项扫描、版本发布提案或广泛的代码仓库扫描。
• 在当前会话中继续工作，遵循代码仓库的常规技能和工作流（codex-first、维护者／审查／测试／发布技能，以及适用的代码仓库说明）。
• 普通的定向子 Agent 或 Codex 委派仍由这些常规技能规范；本协调器不会额外要求创建工作者。
• 如果此技能被误用于单项工作，请说明无需进入协调模式，并直接继续处理。绝不要仅为遵循此技能而中断正在进行的有效工作。

仍应直接处理的示例：

• 修复并合并一个问题；
• 修复一位贡献者的 PR；
• 跨应用和其依赖项追查一个故障；
• 发布一个版本；
• 在两个代码仓库中实现一项连贯的重构。

有界协调

仅当至少符合以下一项时，才使用协调模式：

• 用户要求处理多个互不相关的问题或 PR；
• 用户要求协调多个代码仓库或并行工作流；
• 用户要求队列、扫描、批处理、项目组合、维护者值班或持续分诊；
• 并行分配负责人和协调能显著改善对互不相关事项的处理。

编号任务列表并不自动构成协调队列：为实现同一目标而彼此关联的步骤仍属于单项工作。

持续项目组合监控

只有在用户明确要求持续／自主维护、监控、项目组合扫描或维护队列时，才启用心跳、定期监控、自动补充队列、广泛扫描所有者和持久化协调器日志。绝不能仅因调用了此技能就创建这些内容。

范围约定

激活时，记录明确的队列范围：

• 指定的代码仓库；
• 指定的问题／PR，或用户要求的发现范围；
• 是否可以在该范围之外发现事项；
• 监控是单次还是持续进行；
• 哪些公开操作已获授权。

除非用户要求持续维护队列或明确添加，否则不要将指定批次扩展到无关的代码仓库、依赖项更新、版本发布或待办事项清理。

仅针对广泛的项目组合发现：

• 扫描 steipete 和 openclaw，以及 Peter 是非合并提交作者多数的代码仓库；
• 排除已归档的代码仓库，以及 references/non-majority-repositories.md 中列出的代码仓库，除非用户明确指定；
• 不要擅自将 openclaw/openclaw 和 openclaw/clawhub 纳入项目组合队列补充；
• 对所有权不确定的情况，依据默认分支的贡献历史进行核实，而非依据代码仓库名称判断。

Worker 模型

在编排模式下，按需分配工作线程。

• 协调两个或更多独立事项时，优先为每个代码库使用一个专属的 Codex 应用项目线程。
• 复用该代码库的线程处理其限定队列，并按顺序处理同一代码库的事项，除非确实需要隔离。
• 不要为协调者自己的控制平面工作或单个范围明确的事项创建工作线程。
• 工作线程绝不创建或管理其他工作线程。层级止于根协调者 → 代码库工作线程。
• 协作子 Agent 是只读支持人员，可用于清点、独立分析、观察 CI/状态或协调核对。它们不负责实现、提交、推送、PR 修改、合并、发布、部署或实时验证。
• 如果没有项目线程机制，请在当前会话中使用常规代码库工作流，不要通过不必要的后台任务模拟工作线程层级。

进行受保护的工作之前，先核实工作线程的实际权限。提示词中的文字不会授予文件系统、网络、凭据或发布权限。

代码库保护

分配或修改代码库之前：

1. 记录 git status -sb、分支、上游、HEAD、暂存/未暂存/未跟踪状态，以及领先/落后数量。
2. 获取当前引用。在干净的默认分支上，执行快进拉取并确认代码库仍然干净。
3. 切勿仅为开始编排而切换、暂存、变基、重置、清理、删除或覆盖有未提交更改或非默认分支上的工作。
4. 保留并分类独有的本地工作、相关 PR，以及它是否已合并或已被取代。
5. 只有在无法安全保留或协调独有工作时，才暂停并请负责人决策。

在最终合并或发布操作之前，重复同步。

队列分类

对每个明确限定范围的事项，进行分类：

• 可自主处理 — 与需求明确匹配、可复现或有充分证据、实现范围明确，并且有可行的验证途径。
• 需要负责人决策 — 涉及重大的产品/安全/隐私/法律选择、破坏性处理独有工作、缺少必需的凭据/硬件、不可逆迁移，或缺少实时验证决策。
• 不计划处理 / 无效 — 有具体证据表明属于重复问题、已修复、不受支持、垃圾内容，或超出所请求的产品范围。

将贡献者的 PR 视为提案，而不是已接受的设计。重新还原症状和根本原因，检查当前行为及相关历史记录；如果存在更简洁且范围明确的修复方案，则重写实现。保留贡献者署名。

只要仍有安全的技术工作可做，就不要要求负责人选择。尽可能先完成实现、测试、审查和 CI，再处理该事项。

执行与公开操作门槛

私下调查、实现、本地测试和审查可由多个工作线程独立进行。

只有在并发修改会造成歧义或冲突时，才串行执行对外操作：

• 向同一代码库或同一分支系列推送；
• 创建/更新 PR、批准/重新运行工作流、最终同步、合并、发布或公开；
• 共用合并锁或有限的外部环境。

不要因为另一个工作流稍后到达公开操作门槛，就暂停已在进行中的连贯工作。让其推进到安全边界；在重叠情况解除之前，不要开始新的冲突性公开操作。

用户的调用仅授权明确限定范围的维护工作和所请求的公开操作流程。除非另有请求，否则不授权发布、版本号递增、标签、软件包发布、破坏性处理独有工作，或修改无关的外部系统。

监控

为每次外部等待指定一位负责人。

• 仓库工作者负责其专属的 CI/部署监视器。
• 使用仓库原生监视器，将范围限定为一个运行 ID 或提交 SHA，并采用有上限的退避策略。
• 根协调器依赖工作者状态和执行框架的完成通知；在有一致的监视器运行时，不重复轮询。
• 失败日志只获取一次，并重复使用。
• 仅在收到已报告的阻碍、反复无进展的失败、范围/仓库错误、破坏性或未经授权的操作、安全风险或重大设计偏差时介入。
• 不要在执行过程中重述任务或提高验证标准。

仅当用户明确要求持续关注项目组合/监控时，才创建定期心跳。单次批次依赖正常的任务通知，无需安排自动化任务。

合并标准

合并项目之前，除要求通过仓库自身的门禁外，还须满足：

• 复现问题症状或确认根本原因；
• 判断最佳修复方案和负责人边界；
• 提供有针对性的回归覆盖；
• 针对变更范围执行充分的更广泛检查；
• 当仓库或外部边界有要求时，提供构建/在线/E2E 验证；
• 完成最新的自动审查，且无已接受或可执行的审查意见；
• 精确提交对应的 CI 全部通过；
• 解决审查讨论串，并明确说明已知的验证缺口。

使用仓库原生的合并工作流。合并后，确认目标分支可访问该提交，同步可见的工作区，停止租约/监视器，并确保工作区干净。

指定队列完成后，不要自动继续维护依赖、处理其他问题或发布版本。只有用户明确要求持续队列时，才补充新任务。

OpenClaw 队列模式

仅当用户明确要求协调多个 openclaw/openclaw 项目时，才应用本节。单个 OpenClaw 问题或 PR 仍按仓库的正常维护者工作流直接处理。

• 阅读当前的 VISION.md、根目录和相关范围内的 AGENTS.md，以及相关的 OpenClaw 维护、测试和审查技能。
• 由根协调器负责分流和产品判断。
• 为选定的串行队列使用一个 OpenClaw 仓库工作者；不要为每个 PR 单独创建工作者。
• 优先处理外部反馈提出且符合 Vision 的稳定性、安全默认设置、安装设置、身份验证、安装、交付，以及范围明确的性能/测试基础设施工作。
• 选择通用队列候选项之前，实时验证贡献者权限。
• 合并时仅使用 scripts/pr 的审查、构件、准备、同步和合并命令。
• OpenClaw 的变更日志由发布流程生成；正常的问题/PR 工作不得编辑 CHANGELOG.md。
• 必须提供仓库要求的问题症状验证、托管 CI/Testbox、自动审查以及精确提交合并证据。

负责人决策

每次只询问一个准备好的决策。每份决策简报包括：

• 完整的规范 URL 和标题；
• 使用通俗语言说明行为及受影响的用户；
• 说明为何现在需要决策；
• 已完成的验证以及当前 CI/可合并状态；
• 重要的权衡、剩余风险和缺失证据；
• 协调者的建议；
• 明确的选项及其后果。

不要只给出 URL，也不要提出含糊的 land/delete 选项。提问前立即刷新项目和工作者状态。

发布

启动队列不代表获得发布授权。

只有当用户明确要求发布，或当前仓库的特定工作流已授予相关权限时，才进入发布规划/执行。遵循仓库的发布技能和不可变候选版本门禁。绝不能把普通队列任务完成擅自变成发布项目。

报告

对于范围明确的一批工作，只报告范围内的工作：

• 进行中 — 仓库、完整项目 URL、负责人/执行者、当前阶段。
• 已介入 — 确切风险及纠正措施。
• 需要负责人 — 一个已准备好的决策或访问权限阻碍。
• 已合并/已关闭 — 行为、证明、合并/关闭 URL、文件和 LOC、风险。
• 剩余 — 仅包含请求队列中的项目。

对于持续组合模式，可以使用简明台账和 ~/oss-orchestrator.md。一次性批次不得创建或维护该日志。

始终使用完整的 GitHub URL。报告有意义的进展，不要报告例行轮询。