--- name: skill-to-workflow description: > 将现有 Skill、Prompt、SOP 或 Agent 操作说明拆解为可执行、可监控、可重试的 Workflow 规格；识别真实节点、共享子工作流、工具调用、状态、分支、循环、 提示词、数据契约和验收方式。适用于用户要求把一个 Skill 转成工作流、节点图、 编排方案或 Workflow 实现规格时；不替代原 Skill 执行业务任务，也不在未要求时 绑定具体工作流平台或直接部署。 --- # Skill 转 Workflow 把一个面向 Agent 的 Skill 转换为可实现的 Workflow 规格。转换的目标不是照抄原文中的编号，而是恢复它的真实执行图，并让每个节点都具有明确责任、结构化输入输出、工具权限、停止条件和失败处理。 ## 输入与默认交付 - 输入可以是 Skill 目录、`SKILL.md`、Prompt、SOP、操作手册或用户描述的 Agent 流程。 - 用户指定目标平台时，使用该平台支持的节点、变量、分支和子工作流能力；未指定时输出平台无关规格，不猜测 Dify、Coze、n8n、LangGraph 等具体实现。 - 用户只要求概括时，先给阶段数、主链路和关键回路；用户要求设计或转换时，再给完整节点规格。 - 未明确要求实现、创建文件或部署时，只交付设计，不修改原 Skill，也不创建平台配置。 需要输出完整 Workflow 规格时，读取 [references/workflow-spec-template.md](references/workflow-spec-template.md)。 ## 开始前 1. 完整读取源 Skill 及其声明的必读 references；不要只根据 `SKILL.md` 的表层编号拆解。 2. 检查源 Skill 使用的 scripts、schema、模板、校验器和正式产物路径。只需读取会改变流程设计的资源。 3. 区分三类信息： - 业务语义与判断规则； - 执行机制与工具操作； - 输出格式与验收约束。 4. 记录原 Skill 的授权边界、隐私边界、禁止事项和不可破坏的事实来源。 5. 不执行源 Skill 的业务任务，除非用户同时要求运行或验证转换后的 Workflow。 ## 转换流程 ### 1. 建立源 Skill 契约 提取： - 触发条件与不适用范围； - 必需输入、可选输入和输入选择规则； - 最终产物及其消费者； - 事实来源、数据契约和质量门槛； - 禁止行为、权限限制和人工确认点； - 可复用历史产物与幂等要求。 这些约束必须在 Workflow 中找到承接位置，不能因拆节点而消失。 ### 2. 恢复真实执行图 不要把原文的“七步”机械转换成七个节点。先识别： - 批次级步骤与单对象循环； - 串行依赖和可并行任务； - 条件分支、回退、补充调研和重试； - 阻断失败、允许继续的部分完成和正常空结果； - 中间分析状态与正式交付物。 用一句主链路和必要的回路表示真实执行图，再决定节点数量。 ### 3. 划分节点 一个节点应完成一种稳定责任，并产生可验证的状态变化。满足任一条件时优先拆开： - 判断依据、工具权限或失败策略不同； - 结果需要单独缓存、复用、人工检查或重试； - 下游只依赖其中一部分输出； - 确定性处理与模型判断混在一起； - 一个节点同时在找事实、做业务判断、评分和写最终报告。 不要拆分纯粹的格式搬运、无法独立验收的思维碎片，或只会增加上下文传递成本的微小步骤。 ### 4. 给节点分类 为每个节点选择主要执行类型： - **确定性节点：**解析、清洗、计算、字段映射、文件生成、Schema 校验；优先使用代码或平台原生节点。 - **LLM 判断节点：**分类、推理、提炼、取舍和结构化写作；必须约束输入证据与输出 Schema。 - **工具节点：**搜索、网页读取、数据库查询、API 调用或文件解析；只授予本节点需要的工具。 - **人工节点：**需要业务授权、主观定案或高风险外部变更时使用。 - **路由节点：**根据显式状态或规则选择下一步，不承担额外业务分析。 能由确定性逻辑可靠完成的计算、组装和校验，不交给 LLM。 ### 5. 抽取共享能力子工作流 当两个或以上节点重复使用同一种外部机制，并且能够形成稳定输入输出契约时，将机制抽成共享子工作流。例如： - 搜索规划 → Web Search → URL 去重 → Web Open → 证据提取； - 文件解析 → 格式规范化 → 字段质量检查； - 结构化产物组装 → 构建 → 正式校验； - 通知发送、审批或外部系统写入。 分析节点只提交“需要回答什么”，共享子工作流负责“如何调用工具并返回材料”。共享的是获取或处理机制，不是不同节点的业务结论。 共享子工作流至少定义：请求类型、问题或目标、已知上下文、工具与来源偏好、预算、停止条件、返回数据、未解决问题、限制、缓存键和错误状态。 不要在以下情况强行抽象： - 只有工具名称相同，但输入语义、权限或失败风险完全不同； - 共用后会让子工作流直接替业务节点作结论； - 一次性操作没有稳定复用价值； - 抽象会隐藏人工授权或高风险副作用。 ### 6. 设计状态与数据契约 优先传递结构化状态，不把自然语言报告当作节点间接口。至少区分： - 原始输入； - 规范化输入； - 来源或证据账本； - 中间判断与置信度； - 限制和未解决问题； - 正式产物； - 运行状态与错误。 推荐基础状态为 `complete | partial | failed`，但应按业务语义补充 `skipped`、`needs_human` 或其他状态。正常空结果不能误判为失败。 每个节点的输出只能包含下游需要的数据。Workflow 内部字段在生成正式产物前必须过滤，不得污染原 Skill 的正式 Schema。 ### 7. 设计提示词 采用“共享约束 + 节点任务”的提示词结构： - 共享 System Prompt 保存事实边界、来源规则、禁止事项、表达与结构化输出要求； - 节点 Prompt 只说明本节点目标、输入变量、判断顺序、输出字段和停止条件； - 工具调用策略放在工具节点或共享子工作流，不让每个业务节点重复维护； - 输出使用 JSON Schema 或平台结构化输出，不依赖模型自觉遵守自然语言格式。 提示词必须说明：哪些是事实、哪些允许有限推断、证据不足如何处理、不得新增什么、何时停止。评分节点只能消费已建立的证据，不应重新搜索并引入新事实。 ### 8. 设计分支、循环与失败处理 每个回路都定义： - 触发条件； - 回到哪个节点； - 允许补充或修改哪些字段； - 最大次数、时间或成本预算； - 停止后是 `partial`、`failed` 还是转人工。 区分： - 技术失败：超时、解析失败、API 错误； - 数据失败：缺必需字段、Schema 不合法； - 证据不足：允许部分完成或转人工； - 业务冲突：保留冲突并按规则降置信度； - 高风险操作：执行前请求授权，不用自动重试绕过审批。 ### 9. 把生成与验收确定性化 如果源 Skill 已有构建器、校验器或唯一事实源，Workflow 必须继续使用。推荐结构： ```text 中间分析状态 → 标准事实源组装 → Schema 校验 → 确定性生成交付物 → 正式校验器 ``` 校验失败时优先修正标准事实源并重新生成，不让 LLM 直接分别修改多个派生产物。无法依据现有证据修复时，路由回真正缺失信息的上游节点。 ### 10. 交付并做覆盖检查 完整规格至少说明： - 主链路、节点数量和节点图； - 每个节点的目标、类型、输入、输出、工具、提示词和验收； - 共享子工作流及请求/响应契约； - 状态、缓存、来源、分支、回路和重试； - 正式产物、构建方式和端到端完成条件； - 从源 Skill 到 Workflow 节点的规则覆盖表。 最后逐条核对源 Skill 的必需步骤、核心边界和完成检查，确保没有规则只存在于原文、却在 Workflow 中无人承接。 ## 关键设计原则 - 节点数由稳定责任和状态边界决定，不由源文档的标题数量决定。 - 共享工具机制可以抽象，业务判断不能因工具复用而被混合。 - 搜索、读取和证据提取负责提供材料；分析节点负责形成领域结论。 - 先建立事实和任务，再评分或决策；不要让模型边搜索边凭印象评分。 - 中间状态可以丰富，正式数据契约必须保持干净和兼容。 - 可观测性不是额外报告：节点状态、来源、限制、重试原因和产物路径应成为运行状态的一部分。 - 没有用户授权时，设计 Workflow 不等于执行、部署或触发外部副作用。