包工头

项目执行的断层：从评论到交付

在基于 Multica 平台的协作中，项目进度往往散落在评论、决策和异步沟通里。常见的痛点是：评论不等于任务，分配不等于执行，完成声明也不等于验收通过。 这种信息断层导致项目容易停滞，缺乏真正的持续闭环。

本技能旨在解决这一问题。它不要求用户理解复杂的底层文件结构或 Multica 术语，只需一句自然语言，即可将项目事件持续转化为有负责人、可执行、可验收的工作，直到最终交付。

核心机制与工作流

技能的核心是一个持续的执行循环：检查 -> 任务化 -> 权限核验 -> 分配 -> 核验执行 -> 验收 -> 修复或解锁 -> 接力。

• 自然语言路由：根据用户意图自动切换模式。例如，“看看现在怎么样”触发只读的 report 模式；“继续推进”触发 dispatch 模式在授权范围内执行；“持续盯着”则进入 monitor 模式。
• 单一事实源（SoT）：所有目标、状态、依赖和验收结论必须以 Multica 平台的记录为唯一权威来源。评论仅作引用，不替代事实源。
• 严格的回读验证：每次创建或修改平台记录后必须立即回读。不能仅凭命令意图或旧缓存声称操作成功，只有状态为 queued 或 running 才算实际执行。

适用边界与工程约束

本技能在设计上引入了多重硬性约束以防范自动化失控：

• 零活跃恢复：在 dispatch、monitor 或 recover 模式下，发现零活跃异常时必须立即纠正分类并派发，禁止仅汇报不行动。
• Ready=0 前置复核：在得出无就绪工作的结论前，必须对全部 blocked 和父任务执行可拆分复核，确保不受阻塞的部分被重新任务化。
• 权限边界：仅在触发者权限和既有授权范围内自动执行。创建新智能体、扩大自动化范围或降低验收标准等操作，必须获得明确确认。

所有对 Multica 平台资源的查询和变更，均严格通过当前运行环境注入说明中支持的 multica CLI 命令进行，禁止绕过 CLI 直接调用未公开 API。