workflow-forge-zh

name	workflow-forge-zh
description	工作流提炼与生成技能：从零散经验/多轮对话/已有流程中提炼出结构化、可复用的工作流，或为新任务设计工作流。Use when: 总结工作流、提炼流程、生成SOP、设计工作流、流程优化、把经验变成流程、梳理步骤、生成skill工作流。不适用于执行具体工作流（执行请使用对应领域skill）。
metadata	{"argument-hint":"说明需求，如\"帮我从这次实验过程提炼工作流\"\"为XX任务设计工作流\"\"优化这个流程\"\"把这段经验总结成可复用的SOP\""}

工作流提炼与生成技能

Project structure gate / 文件树结构门禁

只要本工作流将初始化或重组项目，或新建、移动应用、服务、包、模块、页面、API、研究步骤、实验、流水线、测试、文档或多文件产物树，必须先使用 project-structure-architect。

1. 开始前：读取适用的 AGENTS.md、PROJECT_STRUCTURE.md、.project-structure.yaml 和现有文件树，锁定项目类型、蓝图及唯一合理路径。
2. 运行中：每次新增或移动文件前先判断职责、所有者、复用范围和对应测试；禁止同义目录、根目录堆放、跨层混放及无关重组。
3. 阶段收口：纵向切片或阶段完成后检查结构漂移；新项目或重大重组更新结构文档，最终运行结构审计。出现 BLOCK 时停止结构性写入并先修正或询问用户。

纯内容编辑且目标路径已由用户或现有规范唯一确定时，可不重复调用。

技能目标

将零散经验、多轮对话记录、已有流程文档转化为结构化、可复用、可执行的工作流，或为新任务从零设计工作流。

Markdown 交付要求

1. 使用本技能完成正式输出时，除聊天中的简要说明外，必须在当前工作区新建一个 Markdown 文档保存完整结果。
2. 默认保存位置为当前工作区 skill-outputs/workflow-forge-zh/（与 artifact-curator-zh 按技能分子目录一致；根目录平铺为 legacy-flat 兼容）。若该子目录不存在须先创建。
3. 默认文件名格式为 中文主题_YYYYMMDD_HHMMSS.md（置于上述目录下；文件名不再重复 skill 名）；若主题不明确，使用 结果_YYYYMMDD_HHMMSS.md。
4. Markdown 文档必须包含完整工作流、步骤说明、检查点、异常处理与可迁移建议。
5. 若用户明确指定保存路径或文件名，以用户要求为准；若用户明确要求只在对话中回答，可跳过创建文件。
6. 最终回复中要说明新建的 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步法

1. 明确目标：这个工作流要解决什么问题？最终产出是什么？
2. 逆向拆解：从最终产出往回推——需要什么前置步骤？
3. 正向验证：从头走一遍——每步的输入是否被前一步产出覆盖？
4. 补充检查点：在容易出错的步骤后加入验证/检查
5. 标注决策点：哪些步骤需要人工判断？标为分支节点

设计原则

• 最小可行：先设计最短路径，再考虑异常处理
• 单一职责：每步只做一件事
• 可验证：每步有明确的完成标准（"做完什么算做完"）
• 可跳过标注：非必须步骤标为 [可选]

---

模式C：优化工作流

诊断清单

问题类型	表现	优化手段
冗余步骤	多步做同一件事	合并
顺序不当	后面的信息前面才需要	调序
缺失检查	经常在某步出错	插入检查点
过度串行	步骤间无依赖但排成一条线	标注可并行
粒度不一	有的步骤5分钟，有的3天	拆分/合并使粒度均匀
分支遗漏	只考虑了happy path	补充异常分支

输出格式

原工作流：[步骤数] 步
诊断发现：[N] 个问题
优化后：[步骤数] 步（减少/增加 X 步）

变更明细：
- [合并] 步骤3+4 → 新步骤3（理由：...）
- [新增] 步骤5后加检查点（理由：...）
- [删除] 步骤7（理由：...）

---

模式D：转化为 Skill

将工作流封装为标准 VS Code Copilot Skill 格式：

转化流程

1. 确定 skill 名称（英文-连字符，如 data-pipeline-zh）
2. 提取 description（<1024字符，含 Use when 触发词）
3. 提取 argument-hint
4. 将工作流步骤转化为 SKILL.md body 的模式/流程
5. 提取约束条件
6. 追加自我迭代模式
7. 验证总行数 < 500

Skill 输出模板

---
name: [skill-name]
description: '[一句话描述]。Use when: [触发关键词列表]。不适用于：[排除场景]。'
argument-hint: '[用户该怎么调用的示例]'
---

# [技能标题]
## 技能目标
## 任务模式判定（如有多模式）
## [各模式/步骤详述]
## 约束
## 自我迭代模式

---

工作流输出规范

所有模式的最终工作流统一使用以下格式：

标准工作流模板

# [工作流名称]

> 一句话说明：解决什么问题，最终产出什么

## 前置条件
- [需要准备什么]

## 步骤

### Step 1: [步骤名]
- **做什么**：[具体操作]
- **输入**：[需要什么]
- **输出**：[产出什么]
- **完成标准**：[怎么判断这步做完了]
- **注意事项**：[容易踩的坑]  ← 可选

### Step 2: [步骤名]
...

### [检查点] Step N 后验证
- [ ] [检查项1]
- [ ] [检查项2]

## 异常处理
| 异常场景 | 处理方式 |
|----------|----------|

## 产出物清单
- [ ] [最终产出1]
- [ ] [最终产出2]

## 参考依据 [触发 contextual-reference-router 时]
- 具体来源与案例：
- 采用/不采用规律：
- 当前工作流转译：
- 访问与许可限制：

格式规则

1. 步骤编号连续，不跳号
2. 每步有明确的输入/输出——下一步的输入必须在前面某步的输出中
3. 检查点用 [检查点] 标注，插在容易出错的步骤之后
4. 分支用缩进表示：

### Step 3: [判断条件]
  - 若 A → Step 3a: ...
  - 若 B → Step 3b: ...

5. 可选步骤标注 [可选]
6. 可并行步骤标注 [可并行]

---

通用约束

1. 不编造步骤——提炼模式中所有步骤必须有材料支撑
2. 不过度设计——优先最短路径，复杂分支按需添加
3. 全文中文
4. 工作流粒度一致——不出现"一步做完所有事"也不出现"每个鼠标点击一步"

---

自我迭代模式

触发条件

当用户在使用本技能后给出反馈（如"这部分不好用""输出格式需要改""多了/少了XX"），或主动说"优化这个skill"时，进入自我迭代模式。

迭代工作流

1. 收集反馈：明确用户不满意的具体环节（哪个模式 / 哪个步骤 / 什么问题）
2. 诊断根因：是规则缺失、规则冲突、粒度不够、还是场景未覆盖？
3. 提出修改方案：列出拟修改的条目（原文 → 修改后），说明修改理由
4. 用户确认：修改方案经用户确认后才执行
5. 写入 SKILL.md：将修改直接应用到本技能文件
6. 记录迭代日志：在 references/iteration-log.md 追加本次迭代记录

迭代日志格式

## [日期] 迭代 #N

- **触发反馈**：...
- **根因**：...
- **修改内容**：...
- **影响范围**：模式X / 步骤Y

迭代约束

• 不破坏现有模式结构——增量修改，不推倒重写
• 每次迭代只改一个关注点——不趁机大改
• 修改后 SKILL.md 总行数仍 < 500
• 重大结构变更（如新增/删除模式）必须用户明确同意