| name | workflow-forge-zh |
| description | 工作流提炼与生成技能:从零散经验/多轮对话/已有流程中提炼出结构化、可复用的工作流,或为新任务设计工作流。Use when: 总结工作流、提炼流程、生成SOP、设计工作流、流程优化、把经验变成流程、梳理步骤、生成skill工作流。不适用于执行具体工作流(执行请使用对应领域skill)。 |
| metadata | {"argument-hint":"说明需求,如\"帮我从这次实验过程提炼工作流\"\"为XX任务设计工作流\"\"优化这个流程\"\"把这段经验总结成可复用的SOP\""} |
工作流提炼与生成技能
Project structure gate / 文件树结构门禁
只要本工作流将初始化或重组项目,或新建、移动应用、服务、包、模块、页面、API、研究步骤、实验、流水线、测试、文档或多文件产物树,必须先使用 project-structure-architect。
- 开始前:读取适用的
AGENTS.md、PROJECT_STRUCTURE.md、.project-structure.yaml 和现有文件树,锁定项目类型、蓝图及唯一合理路径。
- 运行中:每次新增或移动文件前先判断职责、所有者、复用范围和对应测试;禁止同义目录、根目录堆放、跨层混放及无关重组。
- 阶段收口:纵向切片或阶段完成后检查结构漂移;新项目或重大重组更新结构文档,最终运行结构审计。出现
BLOCK 时停止结构性写入并先修正或询问用户。
纯内容编辑且目标路径已由用户或现有规范唯一确定时,可不重复调用。
技能目标
将零散经验、多轮对话记录、已有流程文档转化为结构化、可复用、可执行的工作流,或为新任务从零设计工作流。
Markdown 交付要求
- 使用本技能完成正式输出时,除聊天中的简要说明外,必须在当前工作区新建一个 Markdown 文档保存完整结果。
- 默认保存位置为当前工作区
skill-outputs/workflow-forge-zh/(与 artifact-curator-zh 按技能分子目录一致;根目录平铺为 legacy-flat 兼容)。若该子目录不存在须先创建。
- 默认文件名格式为
中文主题_YYYYMMDD_HHMMSS.md(置于上述目录下;文件名不再重复 skill 名);若主题不明确,使用 结果_YYYYMMDD_HHMMSS.md。
- Markdown 文档必须包含完整工作流、步骤说明、检查点、异常处理与可迁移建议。
- 若用户明确指定保存路径或文件名,以用户要求为准;若用户明确要求只在对话中回答,可跳过创建文件。
- 最终回复中要说明新建的 Markdown 文件路径(须含
skill-outputs/workflow-forge-zh/ 前缀),以及文件里包含的主要内容。
任务模式判定
| 模式 | 判定条件 | 核心目标 |
|---|
| A. 提炼工作流 | "从XX中提炼流程""总结这次经验""把做法固化下来" | 从已有材料中萃取可复用工作流 |
| B. 设计工作流 | "为XX设计流程""这个任务该怎么走""帮我规划步骤" | 为新任务从零设计结构化工作流 |
| C. 优化工作流 | "优化这个流程""哪里可以改""流程太长了" | 诊断瓶颈 + 精简/重组 |
| D. 转化为 Skill | "把这个工作流变成skill""生成SKILL.md" | 将工作流封装为标准 VS Code Copilot Skill |
条件参考路由
只有用户要求行业案例、优秀工作流、Prompt/Agent 指令参考,或外部参考能补足当前模式时,阶段性调用 contextual-reference-router:
- 模式 A:先忠实还原实际事件;完成还原后,外部参考只能作为独立改进建议,不能改写原始经验。
- 模式 B:明确目标后、逆向拆解前参考同类流程,形成 Reference Brief 再设计。
- 模式 C:先完成瓶颈诊断,再参考优秀模式提出改法,不能用外部模板替代真实问题。
- 模式 D:转化前优先参考对应产品官方 Skill/Agent 指令规范,再用高质量案例补充;Schema 和最终校验仍交给
skill-creator 或官方工具。
Reference Brief 只记录具体案例、采用/不采用规律、转译与访问/许可限制;完成后退出参考 Skill。用户禁止联网、只要求忠实提炼或已给完整规范时跳过。
模式A:提炼工作流
输入材料类型
- 多轮对话记录 / 聊天历史
- 实验笔记 / 操作日志
- 经验描述(口述/文字)
- 已有但混乱的流程文档
提炼4步法
第1步:事件序列还原
从材料中提取实际发生了什么,按时间/逻辑顺序排列:
[动作1] → [动作2] → [分支判断] → [动作3a/3b] → ...
第2步:模式识别
在事件序列中标注:
| 标注 | 含义 |
|---|
| 🔁 重复 | 多次出现的相同/相似操作 |
| 🔀 分支 | 根据条件走不同路径 |
| ⚠️ 踩坑 | 走了弯路或出了错 |
| ✅ 关键 | 不可省略的核心步骤 |
| ⏭️ 可跳过 | 特定场景才需要的步骤 |
第3步:抽象泛化
将具体操作提升为通用步骤:
- 具体值 → 参数(如 "epochs=100" → "设置训练轮次")
- 特定工具 → 工具类型(如 "用 matplotlib 画图" → "可视化结果")
- 踩坑点 → 检查项(如 "忘了归一化" → "数据预处理检查")
第4步:结构化输出
按标准格式输出工作流(见下方"工作流输出规范")。
模式B:设计工作流
设计5步法
- 明确目标:这个工作流要解决什么问题?最终产出是什么?
- 逆向拆解:从最终产出往回推——需要什么前置步骤?
- 正向验证:从头走一遍——每步的输入是否被前一步产出覆盖?
- 补充检查点:在容易出错的步骤后加入验证/检查
- 标注决策点:哪些步骤需要人工判断?标为分支节点
设计原则
- 最小可行:先设计最短路径,再考虑异常处理
- 单一职责:每步只做一件事
- 可验证:每步有明确的完成标准("做完什么算做完")
- 可跳过标注:非必须步骤标为
[可选]
模式C:优化工作流
诊断清单
| 问题类型 | 表现 | 优化手段 |
|---|
| 冗余步骤 | 多步做同一件事 | 合并 |
| 顺序不当 | 后面的信息前面才需要 | 调序 |
| 缺失检查 | 经常在某步出错 | 插入检查点 |
| 过度串行 | 步骤间无依赖但排成一条线 | 标注可并行 |
| 粒度不一 | 有的步骤5分钟,有的3天 | 拆分/合并使粒度均匀 |
| 分支遗漏 | 只考虑了happy path | 补充异常分支 |
输出格式
原工作流:[步骤数] 步
诊断发现:[N] 个问题
优化后:[步骤数] 步(减少/增加 X 步)
变更明细:
- [合并] 步骤3+4 → 新步骤3(理由:...)
- [新增] 步骤5后加检查点(理由:...)
- [删除] 步骤7(理由:...)
模式D:转化为 Skill
将工作流封装为标准 VS Code Copilot Skill 格式:
转化流程
- 确定 skill 名称(英文-连字符,如
data-pipeline-zh)
- 提取 description(<1024字符,含 Use when 触发词)
- 提取 argument-hint
- 将工作流步骤转化为 SKILL.md body 的模式/流程
- 提取约束条件
- 追加自我迭代模式
- 验证总行数 < 500
Skill 输出模板
---
name: [skill-name]
description: '[一句话描述]。Use when: [触发关键词列表]。不适用于:[排除场景]。'
argument-hint: '[用户该怎么调用的示例]'
---
# [技能标题]
## 技能目标
## 任务模式判定(如有多模式)
## [各模式/步骤详述]
## 约束
## 自我迭代模式
工作流输出规范
所有模式的最终工作流统一使用以下格式:
标准工作流模板
# [工作流名称]
> 一句话说明:解决什么问题,最终产出什么
## 前置条件
- [需要准备什么]
## 步骤
### Step 1: [步骤名]
- **做什么**:[具体操作]
- **输入**:[需要什么]
- **输出**:[产出什么]
- **完成标准**:[怎么判断这步做完了]
- **注意事项**:[容易踩的坑] ← 可选
### Step 2: [步骤名]
...
### [检查点] Step N 后验证
- [ ] [检查项1]
- [ ] [检查项2]
## 异常处理
| 异常场景 | 处理方式 |
|----------|----------|
## 产出物清单
- [ ] [最终产出1]
- [ ] [最终产出2]
## 参考依据 [触发 contextual-reference-router 时]
- 具体来源与案例:
- 采用/不采用规律:
- 当前工作流转译:
- 访问与许可限制:
格式规则
- 步骤编号连续,不跳号
- 每步有明确的输入/输出——下一步的输入必须在前面某步的输出中
- 检查点用
[检查点] 标注,插在容易出错的步骤之后
- 分支用缩进表示:
### Step 3: [判断条件]
- 若 A → Step 3a: ...
- 若 B → Step 3b: ...
- 可选步骤标注
[可选]
- 可并行步骤标注
[可并行]
通用约束
- 不编造步骤——提炼模式中所有步骤必须有材料支撑
- 不过度设计——优先最短路径,复杂分支按需添加
- 全文中文
- 工作流粒度一致——不出现"一步做完所有事"也不出现"每个鼠标点击一步"
自我迭代模式
触发条件
当用户在使用本技能后给出反馈(如"这部分不好用""输出格式需要改""多了/少了XX"),或主动说"优化这个skill"时,进入自我迭代模式。
迭代工作流
- 收集反馈:明确用户不满意的具体环节(哪个模式 / 哪个步骤 / 什么问题)
- 诊断根因:是规则缺失、规则冲突、粒度不够、还是场景未覆盖?
- 提出修改方案:列出拟修改的条目(原文 → 修改后),说明修改理由
- 用户确认:修改方案经用户确认后才执行
- 写入 SKILL.md:将修改直接应用到本技能文件
- 记录迭代日志:在
references/iteration-log.md 追加本次迭代记录
迭代日志格式
## [日期] 迭代 #N
- **触发反馈**:...
- **根因**:...
- **修改内容**:...
- **影响范围**:模式X / 步骤Y
迭代约束
- 不破坏现有模式结构——增量修改,不推倒重写
- 每次迭代只改一个关注点——不趁机大改
- 修改后 SKILL.md 总行数仍 < 500
- 重大结构变更(如新增/删除模式)必须用户明确同意