创建工作流
工作流是一个可复用的过程单元，它把“用户想做什么”转化为“先做什么、再做什么、每一步用什么工具、产生什么结果”。本技能指导你从用户的需求出发，最终生成一份符合 docs/workflow/index.md 规范的 WORKFLOW.md。
创建前请先阅读规范：docs/workflow/index.md（三级渐进式披露、图-步骤一一对应、过程规则、工具调用约定）。
何时使用
- 用户要求“创建一个工作流 / 流程 / 标准化流程”
- 用户描述了一个多步骤任务，希望将其固化为自动执行的流程
- 用户要求修改或改进现有工作流
- 用户在会话中执行了可复用的多步骤操作，并表示“把这个流程固化下来”
创建流程
阶段 1：理解意图
先进行访谈，不要急于写文件：
- 解决什么任务？给任务类起个名字（例如“代码审查”、“发布说明”）。
- 触发场景：用户何时会使用它？收集触发词（中文 + 英文）。
- 输入和输出：需要哪些输入（文件/目录/字符串）？产生什么（文件/报告）？
- 现有步骤：用户是否已有习惯的流程？从会话历史中提取工具调用序列、修正项以及输入/输出格式。
- 边界和规则：哪些事情绝对不能做？产出物放在哪里？如何处理失败？
在进入下一阶段前，使用 ask_user 填补缺失信息。
阶段 2：设计流程图
使用 Mermaid 绘制执行流程图，遵循图-步骤对应规则（规范 5.2.1 节）：
- 每个节点必须有一个匹配的步骤段落；每个步骤在图中必须出现一次
- 节点名称与步骤名称完全一致，且全局唯一（
step-N前缀不必出现在节点中） - 判断节点使用菱形
{}，也必须有一个步骤段落，并使用Branch声明每个分支的去向 - 并行步骤（分散）在图中作为一个节点
- 图必须完整：开始、分支、结束
在编写步骤之前，先向用户展示图表并确认。
阶段 3：编写 WORKFLOW.md
在 <workspace>/workflows/<name>/ 下创建目录和文件：
- 元数据头（一级元数据）：
name：kebab-case 格式，与目录名一致，仅使用小写字母、数字和连字符description：功能 + 使用时机 + 触发词（中英文），决定触发频率inputs/outputs：显式声明，标记为必需version/tags：可选
- 概述：一段话说明它做什么、何时使用、产生什么
- 流程图：与阶段 2 一致的 Mermaid 图
- 步骤：每个步骤一个
### <id>: <name>段落，包含属性：Tools/Input/Depends on/Action/Check（判断节点添加Branch，可选when） - 过程规则：顺序约束、数据依赖、验证关卡、副作用约束、最终状态检查
- 工具调用约定：优先使用内置工具，脚本作为后备方案，多读少写，路径约定
渐进式披露：将长表格放在
REFERENCES.md中，确定性逻辑放在scripts/中，主体内容保持精简（<500 行）。
阶段 4：自检与验证
编写完成后，对照规范检查：
- 图-步骤一一对应：图中没有“孤儿”节点，段落中没有“孤儿”步骤
- 节点名称唯一且与步骤名称匹配
- 每个步骤都有具体、可判断的
Check（例如“文件存在且非空”，而不是“确认成功”） - 工具名称准确（
read_file/exec，而不是“查看文件”） inputs/outputs与步骤引用一致- 规则涵盖失败处理（重试/回滚/询问用户）
- 元数据头的
description包含功能和触发词
使用 workflow_list 确认新工作流已被发现，使用 workflow_get <name> 验证其可读性。
阶段 5：交付
告知用户：
- 工作流名称和路径
- 触发场景（什么措辞会触发它）
- 流程概述（多少步骤、判断/并行情况）
- 可选：建议 2-3 个真实的测试请求以验证其工作正常
修改现有工作流
- 先使用
workflow_get <name>读取当前内容 - 保持元数据头中的
name和目录名不变 - 遵循同一规范进行修改；编辑后执行阶段 4 的自检
注意事项
- 只写入工作区
workflows/，切勿修改内置的只读工作流；工作区中同名的工作流会覆盖内置版本 - 一个工作流解决一类任务，不要堆砌无关的流程
- 步骤数保持在 3–8 个；超出则拆分或引用子流程
- 切勿编写恶意或误导性指令；规则必须可审计