安全边界声明

> 本流水线所有修改均通过人机对话执行，任何文件写入前需要用户确认。

Skill Factory — SKILL 自动化生产流水线

激活时必读（每次加载本 SKILL 时执行）

在执行任何用户指令之前，先读取同目录下的 EXPERIENCE.md。

读取规则：
- 只读其中的 EXP 条目（"见过 / 因此知道 / 现在会"三段）
- 不对用户显示读取过程，不复述经验内容
- 将经验作为隐式判断依据，直接影响本次执行决策
- 若 EXPERIENCE.md 不存在，跳过，继续正常执行

核心设计

当用户说"帮我创建一个 SKILL"或类似请求时，立即执行本流水线，禁止跳过任何阶段。

执行顺序（不可更改）：

Stage 0 → Stage 1 → Stage 2 → Stage 3 → Stage 4 → Stage 5

数据流（前一阶段输出 = 后一阶段输入，不可跳传）：

用户需求 ──▶ [1 需求挖掘] ──▶ SKILL.md草稿 ──▶ [2 两层审核] ──▶ 审核通过的提示词
                                                                        │
                                                                        ▼
        审计报告+修复建议 ◀── [4 审计修复] ◀── 完整SKILL包 ◀── [3 生成包]
                                    │
                                    ▼
                        [5 安装]（可选，需用户确认）

四技能分工（单一职责，不可混杂）：

> ⚠️ Stage 2 是两层串联，不可互相替代：
> - 第一层 prompt-auditor = 安全注入检测（越狱、系统信息泄露、AI 被利用的漏洞）
> - 第二层 内置逻辑 = 结构完整性与逻辑一致性（frontmatter 格式、步骤数、示例完整度）
>
> 注意：prompt-auditor 只管安全注入，不管结构审核——结构审核由本 SKILL 的内置逻辑负责。

门禁条件（每阶段必须满足才可进入下一阶段）：

关键原则：
- 数据驱动：前一阶段的输出是后一阶段的唯一输入
- 用户确认：所有关键决策点必须获得用户确认，禁止强制推进
- 不重复提问：Stage 1 只问缺口，不重复问已知信息
- 可追溯：每个 SKILL 的产出都能追踪到具体阶段与决策

> 📖 以上是完整可用的执行要点。ARCHITECTURE.md 为可选深读（含 ASCII 全景图、各技能详细输入输出与实现细节），正常执行本流水线不需要先读它。

禁止行为：
- 禁止跳过 Stage 1 的信号判断直接进入 Stage 2
- 禁止在用户未确认需求前进入下一步
- 禁止绕过 Stage 2 和 Stage 4 的审核
- 禁止在未获得用户确认前写入文件

Stage 0：检查依赖（必须首先执行）

立即执行以下检查：

1. 解析技能根目录：
   - 优先读取环境变量 WORKBUDDY_SKILLS_DIR
   - 未设置时使用：%USERPROFILE%\.workbuddy\skills\（Linux/macOS：~/.workbuddy/skills/）

2. 检查以下三个目录是否存在：
   - [根目录]\prompt-generator\
   - [根目录]\prompt-auditor\
   - [根目录]\skill-creator\
   - [根目录]\skill-auditor\

3. 如有缺失 → 列出缺失列表 → 立即停止，告知用户安装缺失技能后方可继续

4. 如全部存在 → 宣布"依赖检查通过，开始 Stage 1" → 输出阶段小结

阶段输出格式：

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
✅ Stage 0 完成 — 依赖检查通过
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
prompt-generator  ✓
prompt-auditor    ✓
skill-creator    ✓
skill-auditor    ✓
→ 开始 Stage 1
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Stage 1：需求挖掘（强制执行，禁止跳过）

核心原则：
- Stage 1 的主判断器是 prompt-generator，不再先跑硬编码六问
- 先判断信号是否足够；足够就直接生成草稿，不足才一次性补缺口
- 用户确认的是“需求理解摘要 + 草稿方向”；确认前不得进入 Stage 2

立即执行以下步骤：

第一步：把原始需求直接交给 prompt-generator

收到用户的 SKILL 需求后，立即激活 prompt-generator，直接传入原始用户描述，禁止先拆成固定问卷答案。

调用目标：
- 先做 signal check（信息密度判断）
- 再决定是“直接生成草稿”还是“列出缺口问题”
- 输出必须面向 SKILL 生产场景，而不是通用提示词场景

参数传递格式（JSON）：

{
  "mode": "skill-factory-stage1",
  "raw_request": "[用户原始需求原文]",
  "required_fields": [
    "task_name",
    "problem",
    "scenario",
    "input_spec",
    "output_spec",
    "script_needed",
    "constraints",
    "target_employee"
  ],
  "generation_rule": "signal-first",
  "output_target": "SKILL.md draft"
}

第二步：按 signal check 结果分支执行

分支 A：信号充足

如果 prompt-generator 判断信息已经足够：
- 直接生成 需求理解摘要 + SKILL.md 草稿
- 如存在合理推断，附上“默认假设清单”
- 不要为了问而再问一轮固定问题

分支 B：信号不足

如果 prompt-generator 判断信息不足：
- 输出“缺口问题清单”
- 由 skill-factory 一次性向用户发出所有关键缺口问题
- 等用户整体回答后，再次调用 prompt-generator 生成摘要与草稿

补问规则：
- 只问阻塞生成的核心缺口
- 不逐项盘问，不强制追加“还有别的吗”
- 除非仍有致命缺口，否则最多只允许 1 轮主补问 + 1 轮兜底补问

第三步：需求理解确认

拿到 prompt-generator 产出的摘要与草稿后，立即向用户展示：

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📋 Stage 1 需求理解确认
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SKILL 名称：[name]
要解决的问题：[problem]
触发场景：[scenario]
输入：[input]
输出：[output]
脚本需求：[yes/no + 说明]
目标员工：[employee name 或 无]
关键约束：[constraints 或 无]
默认假设：[无 / 假设列表]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
这是你想要的吗？确认后我进入 Stage 2 审核。

必须等待用户确认后，才能进入下一步。

如果用户要求调整：
- 留在 Stage 1
- 将用户反馈与原始需求一起重新交给 prompt-generator
- 生成更新后的摘要与草稿后，再次确认

第四步：确认 Stage 1 输出质量

prompt-generator 的 Stage 1 产物至少必须包含：
- frontmatter（name / description / version / dependencies）
- 任务目标
- 操作步骤（至少 3 步，每步有目标 + 执行内容 + 输出格式）
- 资源索引（如有脚本/references）
- 注意事项
- 使用示例（至少 1 个）

设计意图约束（2026-09-04 新增，硬要求）：
- SKILL.md 草稿对"为什么这样设计"的说明，必须包含「设计意图 + 与内容的对应关系」，并优先用文意/因果层面表达，禁止只列技术参数对齐表。
- 反例（不合格）：「C大调84BPM、24秒转Dm7-G7、配乐压低6dB」—— 这是工程参数清单，读者看不出设计理由。
- 正例（合格）：「文章通篇无阴影 → 用 C 大调全白键对应这份纯净；『偷偷地钻出来』是点状顽皮 → 用钟琴颗粒对应『钻』字」—— 把设计选择锚定到内容语义。
- 适用场景：凡涉及内容创作/配乐/文案/视觉设计类的 SKILL，Stage 1 草稿的"设计说明/注意事项/示例"段落必须满足此约束；纯工程类 SKILL 可放宽，但仍需说明关键参数选择的理由。

禁止跳过此步骤。禁止在关键缺口未补齐时强行生成并进入 Stage 2。

阶段输出格式：

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
✅ Stage 1 完成 — signal 判断 + 提示词草稿已生成
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
生成模式：[直接生成 / 补缺口后生成]
补问轮次：[0 / 1 / 2]
默认假设：[N] 项
步骤数：[N] 步
是否含示例：[是/否]
→ 开始 Stage 2 审核
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Stage 2：审核提示词（强制执行）

立即执行以下步骤：

> ⚠️ 说明：Stage 2 使用prompt-auditor + 内置审核逻辑对 SKILL.md 草稿进行两层检查。
>
> 分工说明：
> - 第一层（prompt-auditor）：检测提示词中的安全注入风险（越狱、系统信息泄露、AI 被利用的漏洞）
> - 第二层（内置逻辑）：检查 SKILL.md 的结构完整性和逻辑一致性（frontmatter 格式、步骤数量、示例完整度）
> - 两层检查维度不同，通力合作确保质量
> - Stage 4 的 skill-auditor 负责完整 SKILL 包的综合审计，包括代码逻辑、安全风险等

第一步：调用 prompt-auditor 进行安全审核

立即激活 prompt-auditor Skill，按以下规范传递参数：

参数传递格式（JSON）：

{
  "prompt_content": "[Stage 1 输出的 SKILL.md 草稿完整内容]",
  "check_level": "full",
  "output_format": "structured"
}

prompt-auditor 的预期输出：
- 安全漏洞检测报告（注入风险、越狱风险、信息泄露等）
- 逻辑完整性分析
- 风险评级（无风险 / 低风险 / 中风险 / 高风险 / 严重风险）
- 修复建议（具体可执行的修改方案）

第二步：处理 prompt-auditor 的审计结果

根据风险评级立即执行：

第三步：执行内置结构审核

1. 将 Stage 1 输出的 SKILL.md 草稿作为输入，执行以下四维度审核：

2. 根据审核结果立即执行：

禁止绕过审核环节。禁止跳过本阶段直接进入 Stage 3。禁止同时跳过 prompt-auditor 和结构审核。

阶段输出格式：

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
✅ Stage 2 完成 — 提示词审核通过
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
发现问题：[N] 个
P0：[N 个] | P1：[N 个] | P2：[N 个]
处理结果：[全部修复/回退重新生成]
最终状态：[通过 ✅ / 回退 🔄]
→ 开始 Stage 3 生成 SKILL 包
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Stage 3：生成 SKILL 包（强制执行）

立即执行以下步骤：

第一步：调用 skill-creator 生成 SKILL 包

立即激活 skill-creator Skill，按以下规范传递参数：

调用方式：以对话上下文激活 skill-creator，传入结构化参数

参数传递格式（JSON）：

{
  "skill_md_content": "[审核通过的 SKILL.md 完整内容]",
  "skill_name": "[SKILL 名称]",
  "script_needed": true/false,
  "references_files": ["[参考文档清单]"],
  "target_employee": "[员工绑定或 null]",
  "temp_base_dir": "[临时目录基路径]"
}

skill-creator 的预期输出：
- 完整目录结构（SKILL.md + EXPERIENCE.md + scripts/ + references/）
- EXPERIENCE.md 第一部分（3-5 条结构性经验，严格遵守三段格式）
- 临时目录位置报告

第二步：验证输出结构

接收 skill-creator 的输出后，检查以下内容：
- SKILL.md 已包含"激活时必读"段落（见下方强制插入格式）
- EXPERIENCE.md 已按规范生成
- scripts 目录（如需要）
- references 目录（如需要）

第三步：在 SKILL.md 开头强制插入激活读取指令

每个生成的 SKILL.md，在 ---（YAML front matter）结束后、正文第一行之前，必须包含以下固定段落：

## 激活时必读

每次被加载时，先读取同目录下的 `EXPERIENCE.md`。
读取后不对用户显示，直接将经验条目作为隐式判断依据影响执行。
若文件不存在，跳过继续执行。

禁止省略此段——没有这段，EXPERIENCE.md 永远不会被触发。

第四步：标准目录结构验证

生成的目录结构必须符合：

[skill-name]/
├── SKILL.md              # 核心提示词（已审核版本）
├── EXPERIENCE.md         # 结构性经验（与 SKILL.md 同步生成）
├── scripts/              # 如有脚本需求
│   └── [script].py
└── references/           # 参考文档
    └── [reference].md

第五步：EXPERIENCE.md 生成规范（强制）

EXPERIENCE.md 分两部分，Stage 3 只写第一部分：

第一部分：结构性经验（制作时写入，一次性）

基于当前 SKILL 的职能域，写入 3～5 条经验条目，每条必须严格遵守以下格式：

## EXP-[编号]：[简短标题]

**见过**：[具体场景——必须有人物/环境/数量，禁止泛化描述]
**因此知道**：[从那个场景推导出的认知——必须有推导过程，禁止直接跳结论]
**现在会**：[具体可执行行为——必须是动作，禁止写抽象原则]

写入护栏（违反则重写）：
- "见过"段必须包含具体情境（时间/场景/人/数量），不允许写"曾经见过有人…"这类无据可查的泛化
- "因此知道"段必须有明确的因果链，不允许直接跳到结论，禁止写"最佳实践是 XXX"
- "现在会"段必须是可被执行的动作，不允许写"保持谨慎""注意边界"等抽象原则
- 禁止凑条数：如果当前 SKILL 首次制作、还没有真实案例，可以少于 3 条（最少 1 条）；其余留给第二部分自然积累

第二部分：自然积累（使用过程中追加，Stage 3 不写）

留空占位符：

## 自然积累（使用中追加）

> 此部分在 SKILL 被实际使用后，由 AI 在任务结束时扫描判断是否追加。Stage 3 不写任何内容。

第六步：写入临时目录

将完整 SKILL 包写入：%WORKBUDDY_SKILLS_DIR%\temp\[skill-name]\
（Linux/macOS：$WORKBUDDY_SKILLS_DIR/temp/[skill-name]/）

阶段输出格式：

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
✅ Stage 3 完成 — SKILL 包已生成
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
位置：%WORKBUDDY_SKILLS_DIR%\temp\[skill-name]\
文件清单：
  - SKILL.md ✓（已包含"激活时必读"段落）
  - EXPERIENCE.md ✓（第一部分 3-5 条结构性经验 + 第二部分占位符）
  - scripts/[N 个脚本] ✓ / 无
  - references/[N 个文档] ✓ / 无
→ 开始 Stage 4 审计
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Stage 4：审计并修复（强制执行）

立即执行以下步骤：

第一步：调用 skill-auditor 审计 SKILL 包

立即激活 skill-auditor Skill，按以下规范传递参数：

调用方式：以对话上下文激活 skill-auditor，传入结构化参数

参数传递格式（JSON）：

{
  "skill_path": "[Stage 3 生成的 SKILL 包路径]",
  "audit_level": "full",
  "auto_fix": true,
  "report_format": "structured"
}

skill-auditor 的预期输出：
- 五步完整审计报告：
1. 结构验证（目录完整性、文件命名规范）
2. 代码逻辑分析（如有脚本：AST分析、复杂度、性能）
3. 安全扫描（注入风险、凭证隐私、危险函数）
4. 合规性检查（SKILL.md 规范、frontmatter 完整性）
5. 综合评分和优先级建议
- 自动修复执行结果
- 需要人工确认的修复项清单

第二步：处理审计反馈

根据 skill-auditor 的审计结果立即执行：

自动修复规则：
- skill-auditor 中标记为"自动修复"的项目，无需再次确认，直接应用
- skill-auditor 中标记为"需确认"的项目，必须获得用户确认后才能修复

第三步：输出审计报告并等待用户确认

按以下格式输出审计报告：

阶段输出格式：

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📊 Stage 4 审计报告
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
综合评级：[A/B/C/D/E]
质量评分：[N]/100
安全评分：[N]/100
规范评分：[N]/100
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
自动修复：[N] 项（已完成）
需确认项：[N] 项（见下方清单）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[需确认修复项清单...]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Stage 5：安装（可选，需用户确认）

立即执行以下步骤：

1. 询问用户：「审计完成，是否立即安装到技能目录？」

2. 用户确认后：
   - 将 SKILL 包从临时目录移动到正式目录：

   • 源：%WORKBUDDY_SKILLS_DIR%\temp\[skill-name]\
   • 目标：%WORKBUDDY_SKILLS_DIR%\[skill-name]\

3. 如 Stage 0 中指定了目标员工：
   - 更新 output/ai-office-visualization/agents/configs/[员工名].json
   - 在 skills 数组中追加新技能条目
   - 同步更新 bridge_server.py 路由规则中对应员工的 trigger_keywords

4. 安装后触发经验记录扫描（强制）：

安装完成后，立即问用户：

> 「SKILL 已安装。这次制作过程中，有没有让你觉得『幸亏我们确认了这个』或者『差点踩坑』的时刻？有的话告诉我，我会记录下来。」

处理规则：
- 用户描述了具体情况 → 提炼成一条 EXP 条目，追加到 EXPERIENCE.md 的第二部分（自然积累）
- 用户说"没有"或"还好" → 什么都不写，留空占位符原样保留
- 禁止把"顺利完成了流水线"当作经验追加——顺利完成不是经验，意外和缺陷才是
- 禁止凑条数：不要因为第一部分只写了 2 条就在这里凑造一条，宁缺毋滥

最终输出格式：

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🎉 SKILL 生产完成
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SKILL 名称：[name]
安装路径：%WORKBUDDY_SKILLS_DIR%\[name]\
绑定员工：[员工名 / 未绑定]
耗时：Stage1[Ns] → Stage2[Ns] → Stage3[Ns] → Stage4[Ns]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

异常处理

注意事项

1. 禁止跳过审核：Stage 2 和 Stage 4 是质量底线，不可绕过
2. 禁止强制推进：用户未确认前，禁止进入下一步
3. 禁止绕过 signal 判断：只有在信号足够或关键缺口补齐后，才能生成 SKILL 草稿并进入 Stage 2
4. 禁止硬编码路径：所有路径必须使用 %WORKBUDDY_SKILLS_DIR% 环境变量
5. 禁止忽略错误：P0 问题必须立即回退，不得继续
6. EXPERIENCE.md 写入护栏：Stage 3 只写第一部分（结构性经验），第二部分留空；Stage 5 安装后必须询问用户有没有值得记录的时刻，用户说没有就不写——禁止凑条数

使用示例

示例 1：完整流程（信号充足，直接生成）

用户输入：

帮我创建一个 SKILL，用来分析微信聊天记录，找出沟通问题和改进建议；输入是聊天导出文本，输出 Markdown 报告，给统统用，不需要脚本

流水线执行：

Stage 0: 依赖检查通过
Stage 1: 调用 prompt-generator 做 signal check
  → 判断：信息已足够
  → 直接生成 chat-analyzer SKILL.md 草稿 + 需求摘要
  → 用户确认摘要
Stage 2: 审核通过
Stage 3: 生成 chat-analyzer/ 目录
Stage 4: 审计通过，评级 B
Stage 5: 安装确认 → 用户确认 → 安装完成

示例 2：信号不足时的一次性补缺口

用户输入：

直接帮我做一个简历分析的 SKILL

正确回应：

> 「可以做，但现在还差几个会阻塞生成的关键信息，请一次性告诉我：
>
> 1. 这个 SKILL 主要分析什么类型的简历？
> 2. 输入是纯文本、PDF 还是结构化表格？
> 3. 你希望输出打分、修改建议，还是完整报告？
> 4. 是否需要脚本处理文件？
> 5. 绑定给哪个员工，还是不绑定？
>
> 你一起答完，我就直接给你 Stage 1 草稿。」