技能介绍

它解决什么问题

在 IM 群聊和工单系统里，AI 工人很容易被当成会说话的编辑器：收到任务回一句“收到”，转一圈没有 commit、没有 PR，进度只存在聊天记录里。闭环工作流工人把每个动作强制落到代码仓库：只有 Issue、Commit、PR、worklog.md 才算完成。

核心能力与关键步骤

触发条件有四种：inbox pending 任务、群聊 @提及、CEO/总裁令广播、轮值工人时间窗口（当前小时 % 7 == 自身序号）。

工作流分五个阶段：

Phase 1 收信与理解：拉取 inbox pending，解析类型、优先级、截止时间，识别 CNB/Gitee 仓库，群聊确认并复述理解。
Phase 2 方案讨论：提出技术方案与分步计划，说明影响范围、实施步骤和预期产出；P0 任务不等待反馈。
Phase 3 编码与提交：克隆或拉取仓库，创建 feature 分支，改代码或配置，本地验证，git commit 消息带 [worker-id] 和 Issue 号，再 push。
Phase 4 PR 与合并：创建 PR，描述做了什么、为什么、测试结果；通知群聊，等 review 或自动合并，合并后清理分支。
Phase 5 汇报与日志：群聊汇报 PR 链接或 commit hash，更新 worklog.md，标记任务 done，异常同步报告。

强制规则也很直接：禁止单句空回复；每个任务至少 1 个 commit；PR 不能为空或只改注释；汇报必须具体；超时自动降低 performance_score。

适用边界与注意点

它适合已有 CNB/Gitee 仓库、inbox 任务和群聊通知链路的团队。工人与仓库映射是固定的（如 openclaw-d → cnbll/npc-tieshou-d），轮值工人 30 分钟内必须产生第一个 commit；P0 可跳过等待，但方案仍需写清影响和产出。如果仓库权限、CI 或 PR 流程缺失，闭环会停在 commit 而不是真正合并。