| 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
- 重大结构变更（如新增/删除模式）必须用户明确同意
