需求到技能流水线

在 WorkBuddy 里开发新技能时，常常面临两个工程痛点：一是单个技能难以独立完成从需求拆解到发布后的持续优化；二是直接串联多个子技能容易导致状态混乱。这个工作流将「需求 → 证据 → 选项 → 落地 → 演进」的全链路整合到一个编排层，由 Agent 作为调度核心，驱动五个独立子技能协同工作。

核心机制：契约驱动的多智能体协作

WorkBuddy 本身没有「技能调用技能」的原语，本工作流通过落盘的交接文档作为通信契约，实现了子技能间的解耦：

• SPEC.md：作为解码器与构建器之间的契约。解码器在此阶段会强制产出「需求本质」与 3-5 个实现路径选项，明确停在这里等待人工拍板，而不是自动替用户决策。
• 两块看板：REQUIREMENTS.md 与 SOLUTIONS.md。在构建阶段自动打底，记录需求来源与技术决策，为后续评测优化提供持久化的持久记忆。
• _RECURRING.json：隐性需求回流清单。由对话矿工在本地离线分析历史对话产出，直接喂给优化管道作为改进依据。

关键步骤：验证与自动化边界

1. 解码与构建：接收自然语言需求，跑解码器生成规格文档。用户选定路径后，构建器以此为输入，产出包含 SKILL.md 和两块看板的三件套。
2. 验证循环（门控）：在产出后强制运行验证。包括实际 install 到临时目录验证「能装」，以及发布前的 dry-run 验证。需回答出口闸门两问：「什么情况会误导用户？」和「什么变量会让编排失效？」
3. 发布与对照：自动预填发布包参数，调用发布技能前显式询问用户是否发布。若构建成功，会调用脚本自动进行 GitHub 对照，寻找可借鉴的兄弟实现。
4. 评测优化闭环：取回线上评测分数（包括 TRACE 五维）后，先挖掘隐性需求，再驱动四阶段管道进行重写与重发。

适用边界与限制

• 依赖环境：首次使用需确保五个配套子技能均已安装。国内环境下 GitHub 搜索可能受限，此时会自动降级为本地扫描加网页搜索补遗，不会阻断主流程。
• 决策权归属：该流水线在选项阶段和发布阶段会强制暂停等待确认。虽然可注册为自动化运行，但涉及对外公开动作时，必须保留人工门控。
• 底层逻辑：强调工程纪律，拒绝 AI 自评质量。所有「构建完成」的结论必须由外部验证结果反推得出。