工作流编排智能体

这个技能要解决的问题

当你把多个技能挂到一个 agent 上之后，常见的失败模式是：所有技能被当成平铺的命令列表，用户一句「帮我做点什么」，agent 就在构思、写代码、修 bug 之间来回横跳，主线丢失，最后交付一堆不连贯的产物。Workflow Agent 把开发周期固定在 Idea -> Sharpen -> Plan -> Build -> Upkeep -> Ship 这条主线上，每次只做当前阶段的一个操作，而不是把技能当命令随手触发。

它如何工作

• 阶段路由：除非用户明确点名某个技能，否则按固定顺序走 Idea、Sharpen、Plan、Build、Upkeep。只有模糊想法时留在 Idea，用 grilling 做结构化提问、grill-me 做直接追问、grill-with-docs 在提问时沉淀文档；方向有了但方案、边界、验收标准仍模糊时进入 Sharpen，可用 prototype 用一次丢弃式实验替代空泛讨论；需要固化为可执行材料时进入 Plan，用 to-prd 生成 PRD、to-issues 拆成可独立执行的 issue；上下文足够时进入 Build，用 implement、tdd 或 diagnosing-bugs；落地后的架构调整、合并冲突与交接走 Upkeep。
• 触发方式：区分 auto（识别到调试、TDD、triage 等匹配场景时自动触发）与 /cmd（用户点名某个产物或技能时触发）。
• 运行循环：定位当前阶段 → 一句话说明下一步操作 → 加载对应技能 → 产出该阶段的具体产物（方向澄清、PRD、issue、代码变更、架构笔记、handoff 等）→ 根据产物决定下一阶段。
• 完成判定：每个阶段都有明确出口，例如 Build 完成意味着实现已落地且相关验证已运行，或明确报告了缺口。

适用边界与注意点

• 不要遍历执行图中的所有技能，只选当前最有用的一步。
• 不要把产品层面的模糊性过早转成实现任务；上下文足够时停止追问；PRD 规模的想法要先拆成 issue 再动手。
• 没有具体产物或明确阻塞原因时，不要宣称工作流已完成。
• 用户点名的技能不可用时，简要说明并退回最接近的流程步骤继续，而不是中断整个会话。