Super Skill Creator (中文版)

目的

此Skill帮助创建可靠、可维护、可测试的 Agent Skill。

使用此Skill将用户的粗略工作流、领域专长或现有的 SKILL.md 转化为生产质量的Skill包，具备清晰的触发逻辑、执行工作流、可复用的 references、故障处理、质量检查和eval cases。

一个好的Skill不仅仅是一个提示词。一个好的Skill是另一个 Agent 的操作手册。

核心原则

在创建或改进Skill时，需要优化以下方面：

1. 清晰的触发机制
2. 明确的任务边界
3. 可重复的执行
4. 显式的决策规则
5. 安全且最小化的工具使用
6. 显式的故障处理
7. 可测试的输出质量
8. 可维护的 references 和可复用资产

优先使用清晰的操作指令，而非宽泛的角色描述。

避免模糊的指令，例如"保持专业"、"适当处理"、"自行判断"或"尽力做到最好"，除非后面跟有具体的评判标准。

工作流

除非用户明确要求更狭窄的任务，否则按顺序遵循此工作流。

第1步：理解Skill目标

确定：

• 目标用户
• Skill应执行的任务
• 正在被捕获的重复性工作流
• 预期的输出
• 业务或运营价值
• 不应使用此Skill的场景

如果用户未提供足够的细节，推断出合理的初稿并明确标注假设。仅当缺失的信息会实质性地改变 Skill 设计时才提出追问。不追问的判断标准：缺失信息是否会改变工作流的步骤数量、分支数量或输出格式。

第2步：收集具体的使用示例

请求或生成 3 到 5 个能触发此Skill的典型用户请求。

对每个示例，确定：

• 用户意图
• 必需的输入
• 可选的输入
• 预期的输出
• 所需的工具
• 可能的故障情况
• 糟糕的回答应该是什么样

如果用户没有提供示例，则生成合理的示例并将其标注为假设。

第3步：定义触发契约

编写Skill描述作为主要的触发机制。

描述必须包含：

• Skill的用途
• 何时使用
• 重要的相邻用例
• 用户请求中可能出现的的关键短语或上下文

不要依赖正文中的"何时使用"部分来实现触发。正文只有在Skill已被触发后才可能被加载。

第4步：设计Skill架构

读取 references/skill-architecture.md，对其 10 层架构逐层判断当前 Skill 需要什么：

10 层过检后，决定文件结构：

• 仅有 SKILL.md
• references/ 用于可复用的领域规则、示例、评分标准或长篇幅指导
• scripts/ 用于每次写代码会重写的确定性操作
• assets/ 用于模板、样板文件、示例文件、风格指南或可复用的项目结构

使用此规则：

• 执行关键指令放在 SKILL.md 中
• 长篇幅稳定的知识放在 references/ 中
• 可重复的计算或转换放在 scripts/ 中
• 可复用的模板或源文件放在 assets/ 中

第5步：编写操作工作流

创建另一个 Agent 可以执行的逐步工作流。

读取 references/skill-utility-rubric.md 维度2（可执行具体性），在编写时实时执行"陌生人测试"：对每条指令判断——一个不了解该领域的 Agent 能否不追问就执行？如果指令包含"适当"、"根据情况"、"合理选择"等需要判断力的短语，须紧跟具体的判断标准，否则重写。

工作流必须包含：

• 输入检查
• 任务拆解
• 工具使用决策
• 决策分支
• 输出组装
• 最终质量检查

当顺序重要时使用编号步骤。
当顺序不重要时使用列表项。

第6步：编码失败机制与高风险动作黑名单

先读取 references/failure-modes.md，对照其中的 11 种常见故障模式，识别当前 Skill 工作流中可能出现的故障类型。再读取 references/skill-utility-rubric.md 维度1（失败机制编码）的通过/不通过标准，确保后续编码命中根因而非表象。

对工作流中每个关键步骤，提取三类信息，并按风险优先级排序。

失败机制（Failure Mechanism）：
- 该步骤的典型失败是什么（不是"可能失败"，而是"失败时 Agent 具体在做/没做什么"）
- 失败的根因机制（如"主机引擎不评估公式字符串"而非"公式可能出错"）
- 该失败在什么条件下触发
- 每条失败机制须能在 references/failure-modes.md 中找到对应的故障类型编号

风险评级（Risk Rating）：
对每条失败机制，用两个维度评级：

综合风险 = 两个维度中取较高者。评级规则：
- H/H 或 H/M → 优先级 1（必须编码到黑名单）
- M/M 或 H/L → 优先级 2（必须编码对策）
- L/L 或 M/L → 优先级 3（标注即可）

输出表格须按优先级从高到低排列。

可执行对策（Actionable Remedy）：
- 针对每个失败机制，给出步骤级的具体对策
- 对策必须引用领域对象或工具（如"用 Python 预计算静态值再回写"而非"确保计算正确"）

高风险动作黑名单（High-Risk Action Blacklist）：
- 仅收录综合风险为 H 的失败机制对应的操作
- 格式："禁止在 [条件] 下执行 [具体操作]"（如"禁止在未验证列类型前对整列执行数值运算"）
- 每条黑名单条目必须附带禁止原因（一句话）
- 编码完成后，用 references/skill-utility-rubric.md 维度3的检查方法验证：每条禁止是否包含触发条件 + 具体被禁止的操作 + 禁止原因

输出格式：

| 步骤 | 失败机制 | 根因 | 触发条件 | 严重度 | 发生频率 | 优先级 | 对策 | 黑名单 |
|------|----------|------|----------|--------|----------|--------|------|--------|

表格按优先级从 1（最高）到 3（最低）排序。优先级 1 的行，黑名单列必须非空。

第7步：添加可靠性设计

读取 references/reliability-patterns.md，对以下 7 个模式逐一检查当前 Skill 是否已覆盖。每个模式对应下方一个子项：

对每个Skill，定义：

• 必需的输入（参考模式2的四种输入分类）
• 输入缺失时的行为（参考模式2）
• 输入模糊时的行为（参考模式2）
• 工具故障时的行为（参考模式3：优雅降级）
• 不安全请求时的行为（参考模式4：停止条件）
• 超出范围时的行为（参考模式7：显式边界）
• 停止条件（参考模式4）
• 升级或用户更新规则（参考模式5）

Skill不应在未标注的情况下推断用户输入或上下文。

当Skill做出假设时，必须标注出来。

当Skill无法完成完整任务时，必须产出最安全的部分结果，并说明缺少了什么（参考模式3：优雅降级的四步流程）。

第8步：添加质量门槛

定义Skill输出必须满足的具体标准。

质量门槛应包括：

• 必需的章节
• 准确性要求
• 格式要求
• 完整性要求
• 禁止的行为
• 不可接受输出的示例

第9步：创建eval cases 和触发测试

读取 references/eval-design.md，按其四维检查模型和两层判定机制设计 eval cases。

9a. eval cases

创建至少 6 个 eval cases：

1. 正常路径
2. 最小输入
3. 模糊输入
4. 缺少关键数据
5. 工具或 reference 不可用
6. 超出范围请求
7. 对抗性或安全风险请求（如适用）
8. 效用对比：同一任务在有 Skill 和无 Skill 下的执行质量对比。通过标准：有 Skill 时输出质量 ≥ 无 Skill 时。若出现退化，说明 Skill 引入了负迁移，需回到第6步检查失败机制编码是否误导了消费方。
9. 回归用例：来自之前部署的实际失败案例（如有历史失败记录则纳入，无则跳过并标注"暂无历史失败记录"）

每个 eval case 必须包含以下 7 个字段（对应 eval-design.md 的格式）：

- 名称：[描述性测试名称]
- 维度：[Outcome / Process / Style / Efficiency — 至少包含 Outcome 和 Process]
- 用户请求：[用户可能使用的确切措辞]
- 预期行为：[Skill 应该做什么]
- 确定性检查：[可用代码判定的通过标准，如文件存在、关键字匹配、数量统计]
- 语义判定 rubric：[需要 LLM 打分的标准，每条 0 或 1 分，定义通过线]
- 失败迹象：[失败的执行应该是什么样]

9b. 触发测试

参照 references/eval-design.md 的触发测试格式和 references/description-trigger-guide.md 的检查清单，生成触发测试 CSV：

id,should_trigger,prompt
trigger-01,true,"[应该触发此 Skill 的用户请求]"
trigger-02,true,"[另一种触发措辞]"
...
trigger-10,false,"[不应触发但容易混淆的相邻请求]"

要求：
- 至少 10 条，其中 should_trigger=true 和 =false 各不少于 5 条
- =false 条目须是与本 Skill 相邻但不该触发的场景（如本 Skill 是"创建 Skill"，则"帮我写一封邮件"应为 false）
- 每条须能验证第3步写的 description 是否精准

第10步：审查技术写作质量与效用维度

执行 references/self-editing-protocol.md 中定义的四轮 self-editing 审查协议，外加第五轮效用维度检查：

第一轮：用词检查。 扫描模糊词并替换为可衡量的标准。

第二轮：Style guide 对标。 检查术语一致性、任务导向标题、段落聚焦和结构，以 references/technical-writing-rules.md 作为 style guide。

第三轮：Agent 初次阅读审查。 从第一次看到这份文档的 Agent 视角重新通读。执行复述测试：如果任何指令可以被复述为两种不同的意思，则该指令有歧义。

第四轮：Eval cases 回查。 对于第9步中的每个 eval case，验证 Skill 中是否明确说明了如何处理。补充遗漏的处理逻辑，重复直到所有 eval cases 都被覆盖。

第五轮：效用维度检查。 使用 references/skill-utility-rubric.md 中的三维准则逐条审查 Skill：
1. 失败机制编码：Skill 是否识别了 Agent 在该领域为何失败？识别的是根因而非表象？
2. 可执行具体性：指导是否步骤级具体，引用了领域对象和工具？能否直接转化为动作？
3. 高风险动作黑名单：是否明确禁止了特定的有害行为模式？每条禁止是否有原因说明？

五轮均无遗留问题后，Skill 才算完成。

第11步：打包结果

交付Skill时，提供：

• 建议的文件夹结构
• 最终的 SKILL.md
• 建议的 references/ 文件
• 建议的 scripts/ 文件（如有）
• 建议的 assets/ 文件（如有）
• eval cases（含 7 字段完整格式）
• 触发测试 CSV
• 已知假设
• 建议的下一次迭代

Reference 使用

本 Skill 自身执行时需要读取的 references（按步骤绑定）：

产出物中建议消费方使用的 references（作为新 Skill 包的参考结构，不强制）：

不要将长长的外部材料复制到 references 中。总结原则并将其改编为可操作的规则。

输出格式

在创建新的高级Skill时，按以下结构输出结果：

1. Skill设计摘要
2. 假设
3. 文件夹结构
4. SKILL.md
5. 建议的 references
6. 建议的 scripts/assets
7. eval cases（含确定性检查和语义判定 rubric）
8. 触发测试 CSV
9. 质量检查清单
10. 下一次迭代建议

在审查现有Skill时，按以下结构输出：

1. 总体诊断
2. 触发描述问题
3. 工作流问题
4. 可靠性缺口
5. Reference/script/assets 机会
6. 安全或工具使用风险
7. 具体的重写建议
8. 修订后的 SKILL.md（如需要）

质量门槛

已完成的Skill只有在以下条件满足时才可接受：

• 描述可以在不依赖正文内容的情况下触发Skill
• 目的用一段话说明了做什么、为谁做、什么场景不用
• 范围明确
• 工作流可执行
• 决策规则具体
• 故障处理已定义
• 输出格式已指定
• 至少存在 5 个 eval cases，每个包含 7 字段（名称、维度、用户请求、预期行为、确定性检查、语义判定 rubric、失败迹象）
• 触发测试 CSV 至少 10 条（true/false 各不少于 5 条）
• Skill避免使用模糊、不可测试的语言
• Skill不要求不必要的工具、权限、密钥或网络访问

已完成的Skill在以下情况下不可接受：

• 仅描述角色设定
• 依赖宽泛的专业知识但没有工作流
• 缺少输入缺失时的行为
• 缺少停止条件
• 将重要的触发规则隐藏在正文中
• 告诉 Agent 运行不安全或未经说明的命令
• 无法用具体示例测试

Skill成熟度等级

在评估或设计Skill时，将其成熟度分类：

Super-skill-creator-zh 的目标是最低 Level 3；对于高价值或复杂任务，目标为 Level 4。