技能编排交付

要解决的问题

把复杂任务交给 Agent 时，常见失败并不发生在执行阶段，而是发生在「开工前」和「交付时」：需求没对齐就动手，agent 反复确认拖慢节奏；做完才发现漏了验收点，只能返工重来；交付时不说清默认了什么、没做什么，用户得自己翻输出反推。@user_11d2869f/compound-orchestrator（技能编排交付）针对的就是这三处断点。

核心能力

架构是 ROUTER + Skill 仓库：ROUTER 负责解析任务、拆解子任务、匹配技能、聚合输出，技能来自 ~/.workbuddy/skills/ 下已装的 SKILL.md，必要时按需从技能市场搜索安装。

v2.0 的七步闭环里，两个闸门是关键：

• Step 0 交代闸门：先查复利库和上下文再提问，把需要用户拍板的决策点压缩到 ≤4 个一次问完，产出任务书和逐条可打勾的验收标准。用户说「按默认」即视为对齐。
• Step 6 交付闸门：交付物附带验收对照表、假设声明、已知限制三件套，用户不用自己找答案。
• 中间是 Step 1–4 拆解子任务、匹配技能、按 depends_on 依赖编排执行（无依赖可并行）、聚合输出。
• Step 5 验收自检逐条对照验收标准，不合格不自我豁免，交给 Loop Engineer 回灌反馈自返工，上限 3 次；仍不过则输出当前最佳结果并说明差距。
• 通过后写入 compound_interest/task_skill_memory.json，记录技能组合和 decision_prefs（决策偏好），下次同类任务优先复用历史方案。

适用边界

• 仅复杂任务走完整流程：单个动作、无跨技能依赖的简单需求直接做，不逐条过闸门，避免过度流程化。
• 入口有分工：需求没交代清楚时先转调研大师，编排执行中发现需求不清要停下来问，不硬猜。
• 常用技能组合只是示例，实际匹配由 ROUTER 依据已装技能和市场搜索动态决定。
• 复利记忆依赖历史库质量，早期案例少时复用收益有限。