标题：你的 Claude Code 技能从不触发——问题可能不在技能本身
你的 Claude Code 技能从不生效——但这并不是技能本身的错。
我管理着一个开发团队，几个月来我们每天都在用 Claude Code。我给我们做了一组自定义技能——代码审查、调试流程、团队规范——而最让我意外的一个教训是：只要描述（description）写错了，技能正文写得再好也几乎派不上用场。
没人提醒过你的失败模式
大多数开发者第一次接触技能功能时，经历都差不多：兴奋地写下一个 200 行的 SKILL.md，把自己对代码审查的全部心得都码进去……然后呢，它一次都没触发过。一次都没有。于是他们得出结论：「技能根本没用」，又回到每次会话都手动重打同一段提示词的老路上。
其实技能多半没问题，是描述把它坑了。
描述是路由规则，不是文档
Claude 在一开始能看到的，只有技能描述这一部分。只有当描述和你的请求匹配上，完整的指令才会加载进来。所以描述不是宣传文案——它是一条路由规则，就得按路由规则来写。
对比一下这两个写法：
WEAK — reads nicely, never triggers
description : Helps with code quality and best practices.
STRONG — names the situations AND the phrasings
description : Security-first code review for Python/FastAPI. Trigger when the user asks to "review", "check", or "look at" code, pastes a function or endpoint, mentions a bug, or asks "what's wrong with this". Also trigger on short requests like "review this".
差别在于：强版本里装的是你实际会敲出来的词，包括那些偷懒的说法。没人会在深夜 11 点打出「请执行一次全面的质量评估」——他们只会写「review this」（也就是「看看这个」）这种短句。如果你的描述没覆盖这种两个词的偷懒版本，那你的技能在你大多数真实请求里都只能睡大觉。
帮我修好技能的三条规则
1. 列出你真正的触发短语。 翻翻聊天记录，看看你平时是怎么组织请求的。把这些原话原样写进描述里——「fix it」「what's wrong here」「check this」。用你真实的词汇，而不是你工作场合的词汇。
2. 点名具体对象，别只写动词。 比如「当用户粘贴 Python 代码时」「当出现堆栈跟踪（stack trace）时」「当有人分享 diff 时」。我有一半的请求根本不含任何动词——我就是直接把代码贴过去。
你的 Claude Code 技能从不触发——问题不在技能本身
描述必须能捕获那种情况。