这个 skill-creator 来自 Anthropic 的 skills 仓库，用于创建、修改和评估技能。它把“写一段很长的提示词”拆成几个具体问题：什么时候应该启用、需要哪些输入、输出应该是什么，以及怎样知道新规则比旧做法更好。适合把已经重复做过的工作整理成可维护的流程。
安装与首次调用
本文整理的是 Anthropic anthropics/skills 仓库中的 skill-creator。在 Claude Code 中，Anthropic 当前文档推荐安装独立的官方 skill-creator 插件；它收录的 SKILL.md 与该仓库的同名文件目前内容一致。在项目目录启动 Claude Code 后，在 Claude Code 输入框中输入：
/plugin install skill-creator@claude-plugins-official
这个命令会打开插件详情，核对名称后选择安装范围并完成安装；它不是系统终端里的 Shell 命令。如果提示找不到 claude-plugins-official marketplace，先在同一个输入框输入 /plugin marketplace add anthropics/claude-plugins-official，再重试安装命令。安装摘要若提示重新加载插件，按界面提示操作；确认已激活后输入 /，检查插件提供的 skill-creator 是否出现在技能列表。已有 example-skills@anthropic-agent-skills 的读者可先检查是否已提供同名技能，不必为这篇说明重复安装。
随后在同一项目会话里明确说“使用 skill-creator”，再提供文件或任务。下面的提示词是可修改的首次输入示例。安装只加入技能说明与资源，不会替你准备输入资料，也不代表本机已有完整评估所需的执行环境。若找不到技能，先检查安装摘要、插件是否启用与当前会话是否已加载，再继续排查任务输出。
先带来一个能检查的任务
使用 skill-creator，把每周客户访谈整理成行动清单的流程做成 Skill。
输入是访谈 Markdown，输出要包含问题、证据摘录、负责人和待确认项。
不能把客户猜测写成已验证事实，也不能补造负责人。
先问清触发范围，再起草 SKILL.md；用三份不同访谈检验，不只用当前这份。
提供过去做得好和做得不好的例子，明确产物格式和不能出现的行为。技能会先澄清边界，再写 name、description 和正文。描述决定什么时候容易被发现，应同时说明做什么与何时使用；正文则负责步骤、判断和资源入口。
如果流程需要模板、参考资料或重复脚本，应放在对应资源目录，并让主文件说明何时读取。不要把所有背景硬塞进 SKILL.md，也不要为了一个样例不断追加只有它才需要的例外。结构清晰比堆叠“必须”“绝不能”更利于后来维护。
用相同任务比较新旧做法
第一轮可以选两到三个真实提示词：正常输入、材料缺失、格式不一致各一个。创建新技能时，对比使用技能与不使用技能；改进现有技能时，先保留旧版本，再比较同一输入下的结果。验收可以检查字段是否齐全、证据是否对应原文、未提供的信息是否被正确留空，主观写作质量则交给人阅读。
官方流程会把结果按迭代和案例保存，结合定量检查与人工反馈查看。不要只看总通过率，还要看每个失败样例和它的执行过程：可能是规则不清楚，也可能只是测试题没有区分度。改动后跑同一组任务，并增加没见过的新样例，避免把技能只调成某三份文件的答案模板。
描述触发优化属于后续阶段，它使用应触发与不应触发的查询来检查边界；相近但不该启用的任务比完全无关的问题更有价值。相关脚本需要对应 CLI 和模型调用环境，不是所有聊天界面都能直接执行。没有这些能力时仍可起草和人工试用，但不要把它描述成完成了独立基线评估。
交付时保留技能目录、测试输入、评估反馈和安装说明。以后修改时尽量保留同一技能名称，记录变化原因，让使用者知道这次改善的是哪一类行为，而不是只收到一个没有上下文的“升级版”。
先测是否会在正确时机触发
新技能不要只拿一条完美示例测试。准备三类真实请求：明显应该使用它、相近但不该使用它、需要使用但材料不全。对同一输入保存未启用技能的基线和启用后的结果，再比较是否多完成了关键步骤、有无擅自补造信息。这样才能分清“说明写得漂亮”和“实际帮助完成任务”。
若失败是没有触发，先改技能描述中的适用时机和边界；若已经触发却做错，修改正文步骤或支持资料。每轮只改一类问题并重跑同一组样例，再加入新的样例防止过拟合。交付目录里最好保留样例输入、期望检查项和失败记录，下一次更新才知道是否真的进步。
控制正文和附属资料的分工
技能描述负责告诉 Agent 何时进入，正文负责给出最短可靠流程；长列表、模板与示例可放在相邻参考文件里，让 Agent 需要时再读。若正文塞满所有边界情况，真正执行前就会消耗大量上下文，关键步骤反而不醒目。修改时先看失败轨迹：是没找到参考文件、顺序误解，还是规则自相矛盾。针对失败点调整文件组织，比无差别增加“必须遵守”更有效。
触发分数异常时看事件轨迹
评估器给出 0% 召回率时，不必立刻把描述改得更宽。一份 20 条查询的公开测试发现，旧版脚本可能因为模型先调用 Bash、Glob 等工具，就在真正的 Skill 调用出现前判定失败。先打开运行轨迹，核对模型是否实际加载了技能，再调整触发描述；改完还要用同一组正例与近似负例复测。