闭环工作流引擎

要解决什么问题

多 Agent 或「工人」接任务时，常见问题是：群聊里只回「收到」、任务挂在 inbox 却没有任何 Commit/PR，评审与负责人无法从仓库里核对进度。本技能把一次任务约束成可审计的闭环：每个动作都要落到 Issue、Commit、PR 或 worklog 上，而不是停留在对话层。

工作流如何运转

触发来源包括：inbox 中带 task 标签的待办、群聊 @ 提及（方案或 Code Review）、CEO/总裁令广播，以及按 当前小时 % 7 决定的轮值工人窗口（轮值者需在约 30 分钟内产出第一个 commit）。

阶段划分清晰：

• Phase 1 收信与理解：拉取 pending 任务，解析类型/优先级/截止时间，识别 CNB/Gitee 仓库；在群里确认收到并陈述理解，禁止单句敷衍。
• Phase 2 方案讨论：给出影响范围、步骤与预期产出；P0 可不等待反馈直接执行。
• Phase 3 编码与提交：建 feature 分支、改代码、本地验证，git commit 消息格式为 [worker-id] 简述 (#issue号) 并 push。
• Phase 4 PR 与合并：写清做了什么/为什么/测试结果，通知群聊，合并后清分支。
• Phase 5 汇报与日志：群聊汇报含 PR 链接或 commit hash，更新 worklog.md，inbox 标记 done。

技能内还定义了工人与 cnbll/npc-* 仓库的映射表，以及 scripts/closed-loop-worker.py 作为执行器，对接群聊与 Inbox 的 HTTP API、CNB Git/API。

适用边界

• 面向 CNB（cnb.cool） 生态与既定工人—仓库映射；换平台需自行改关联逻辑。
• 强制规则要求：禁止空 PR、至少 1 个有意义 commit；超时未完成会降级 performance_score。
• 码灵（maling）在映射表中但未列入 % 7 轮值序列，轮值职责以文档中的 7 位工人为准。