name: skill-creator description: “创建或改进技能的指南。在构建新技能或评估现有技能时使用。”
创建或改进能够用平台未提供的项目特定知识来扩展代理功能的技能。
何时使用
- 从头开始构建新技能时
- 评估或改进现有技能时
- 当技能未触发或产生不良结果时
- 当用户要求创建斜杠命令时
何时不使用
- 对于一次性指令（直接告诉代理即可）
- 当平台已处理该功能时（不要重述系统提示行为）
- 当任务过于狭窄无法复用时（技能应适用于多种情况）
使用示例
/skill-creator
/skill-creator (改进问答技能)
/skill-creator (创建新的部署技能)
核心原则
代理本身已足够智能。 仅添加它不具备的上下文。将每个段落标记为 专家（代理不知道：保留）、激活（代理知道但简短提醒有帮助：如果简短则保留）或 冗余（代理肯定知道：删除）。目标：>70% 专家内容，<10% 冗余内容。
描述即触发器。 前言中的 description 字段决定技能何时激活。将“何时使用”放在那里，而不是正文中。要具体：
# 不好
description: "在任何对话开始时使用"
# 好
description: "在编写代码后、提交前，或当 CI 可能失败时使用"
匹配自由度与脆弱性。 狭窄且有悬崖的桥梁需要护栏（精确命令）。开阔的田野允许多种路线（原则和启发式方法）。
技能解剖结构
结构良好的技能包含以下部分：
| 部分 | 目的 |
|---|---|
| 前言 | 名称、描述（触发器）、允许的工具 |
| 执行前检查 | 执行前的预检 |
| 何时使用 | 正面触发器 |
| 何时不使用 | 负面触发器（防止误用） |
| 使用示例 | 调用模式 |
| 流程/执行 | 做什么（命令、步骤） |
| 好/坏示例 | 展示期望与不期望的输出 |
| 质量检查清单 | 在报告完成前进行验证 |
并非每个技能都需要所有部分。短技能（< 30 行）可以跳过检查清单。复杂技能应包含所有部分。
技能结构
技能名称/
├── SKILL.md (必需：前言 + 指令)
├── scripts/ (可选：确定性的、可复用的代码)
├── references/ (可选：按需加载到上下文中)
└── assets/ (可选：用于输出，不加载)
保持 SKILL.md 在 100 行以内。将详细的参考资料移到单独的文件中，并描述何时读取它们。
不应包含的内容
- 系统提示已提供的指导
- 人格角色扮演（“你是一个专家……”）
- 能力列表（“精通 X, Y, Z……”）
- README、CHANGELOG 或辅助文档
- 引用不存在的文件
- 内容很好但描述模糊：它永远不会触发
工作流模式
顺序型：预先概述步骤：
1. 检查格式 (`gofmt -l .`)
2. 运行 linter (`golangci-lint run`)
3. 运行测试 (`go test ./...`)
4. 报告结果
条件型：指导通过决策点：
1. 确定变更类型：
**新功能？** -> 运行完整审计
**仅文档？** -> 跳过检查
输出模式
模板：当一致性重要时提供结构：
运行检查后，报告：
1. **结果**：通过或失败
2. **失败项**：什么失败了以及如何修复
3. **涉及的文件**：修改过的文件列表
示例：当风格重要时展示输入/输出对：
好：运行了 `make audit` -> "所有检查通过"
坏："现在应该通过了"（未运行任何检查）
示例比描述更能清晰地传达风格。好/坏对特别有效；它们设定了边界而不显得死板。
试金石测试
在最终确定技能之前：
- 平台是否已经做了这件事？不要重述。
- 它是否抑制了 AI 的判断？这是越狱，不是技能。
- 所有引用的文件都存在吗？修复或删除幽灵引用。
- 是否在 100 行以内？如果不是，拆分成参考资料。
- 描述是否具体？缩小触发范围。
- 专家会说“这包含了需要多年才能学到的知识”吗？如果不是，那很可能是冗余的。
- 它有示例吗？没有示例，执行质量会随时间下降。
流程
- 理解需求：这个技能解决什么问题？它是否频繁到足以证明创建一个技能是合理的？
- 检查现有技能：搜索
.claude/skills/以避免重复或找到要扩展的技能 - 起草技能：从前言和核心内容开始；标记段落（专家/激活/冗余）
- 添加示例：为输出质量提供好/坏对
- 运行试金石测试：验证以上所有 7 点
- 如果值得作为模板：也在
internal/assets/claude/skills/中创建版本，以便随ctx init部署