技能编排与工作流路由

要解决什么问题

在 harness 体系里往往同时挂着十几个 skill：有人知道该用哪一个，更多人面对的是「该用哪些、按什么顺序跑」。把 13 个 skill 当成每次必跑的清单，会浪费上下文；跳过 project-intake 直接 bootstrap，骨架又容易和真实项目对不上。本技能解决的是路由与编排：在主对话里做决策逻辑，而不是把编排当成可委派、等结果的执行任务。

核心机制

组合优先于单点精通：先判定用户目标属于哪条标准工作流，再给出 skill 名单与顺序，并说明可省略项。

五条工作流覆盖常见场景：

• Workflow 1（Greenfield）：project-intake → bootstrap → repo-map →（可选）architecture-boundaries + golden-principles
• Workflow 2（日常功能）：可选 exec-plans → 实现 → verification-loop → commit-gate
• Workflow 3（代码质量）：golden-principles →（可选）architecture-boundaries → 验证与提交门禁
• Workflow 4（扩展 harness）：authoring →（可选）bootstrap → repo-map
• Workflow 5（提示词）：单独跑 prompt-optimizer

路由采用三层决策：项目阶段（新/已有/扩展 harness）→ 任务类型（功能、质量、提示词等）→ 具体 skill 匹配与执行顺序。目标含糊时先澄清再路由；多工作流并存时拆子目标，并参照交接表（如 intake 卡片进 bootstrap、exec-plans 产物进 verification-loop）确认上游交付物完整。

适用边界与硬约束

• 用户已明确「用 X skill」：直接执行，不要强行编排。
• 单 skill、简单任务：不必加编排开销。
• 用户问的是某个 skill 的用法，而非组合方式：直接回答用法。
• Workflow 1 不得跳过 project-intake；风格问题与结构问题要分清：golden-principles 与 architecture-boundaries 不要混用。
• 小项目可按省略指南减掉 architecture-boundaries、exec-plans 等；文档类改动可弱化自动化验证步骤。