$ man context-wiki/skills

技能是一个 Markdown 文件，记录你如何做某件事。用纯英语写一次。Claude 每次都照做。/deploy 技能知道如何在三个网站上暂存、提交、推送和验证部署。/finalcopy 技能知道你的语音指南、平台规则和反套话过滤器。/tracker 技能知道如何扫描 Git 提交、计算内容数量、计算输出分数并生成仪表板图像。技能是可移植的知识。它们将部落知识转化为可执行的自动化。

模式

Joe Rhew 完美地用了这个类比。技能就像一口铸铁锅。你没有做什么特别的事。你只是在做饭。但每次使用铸铁锅时，它都会变得更有味道。一个你打磨了 20 次的技能比你第一天写的那个要好得多。而且你从未专门安排时间去改进它。你只是使用它，发现一个边界情况，修复那个边界情况，技能就变得更好了。 我的 /deploy 技能开始时只有 10 行：暂存、提交、推送。现在它处理提交消息生成、三个站点的构建验证、错误恢复和部署后确认。我从未安排时间去改进它。我只是部署了 50 次，修复了出现的问题。

专业技巧

标准操作流程是为人类编写的，让他们一步一步跟着做。它们会过时。人们会跳步骤。没人去更新它们。技能完全取代了 SOP。你不再写一个让人类阅读并遵循（会出错）的文档，而是写一个代理执行（不会出错）的技能。技能集 SOP、执行者和质量检查于一个文件之中。 我的仓库中有 40 多个技能。/deploy、/tracker、/finalcopy、/substackpost、/partneronboard、/webreveal、/heyreach-export、/linkedin-recon、/daily-tracker。每个我重复超过两次的工作流都变成技能。每个我使用超过五次的技能都得到优化。结果是一个运行我整个 GTM 运作的自动化库。

模式

一个 SKILL.md 文件需要五样东西： 1. 触发描述。什么激活这个技能？斜杠命令、关键词、短语。 2. 上下文需求。代理在执行前需要什么文件、数据或状态？明确列出它们。 3. 分步指令。用纯英语编写。编号步骤。足够清晰，使一个没有先前对话上下文的新代理也能遵循。 4. 输出预期。成功是什么样的？一个已部署的网站？一个生成的文件？一个已发布的草稿？ 5. 边界情况处理。什么可能出错？端口冲突、构建失败、数据缺失。代理应如何恢复？ 如果你的技能文件缺少其中任何一项，代理就会即兴发挥。而即兴发挥就是出问题的地方。

反模式

一个写着"部署网站"的技能文件不是技能。它是一个愿望。真正的技能会说：检查未暂存的更改、暂存所有修改的文件、从 diff 生成提交消息、用该消息提交、推送到 origin main、等待 Vercel 构建完成、检查所有三个部署 URL、确认 200 状态码、并报告结果。模糊的技能产生不一致的结果。具体的技能产生可靠的结果。编写技能时就像在为一个从未见过你代码库的承包商做入职培训。因为这正是每个新代理会话的真实情况。