1. *常见失败模式*。模型在你的项目里反复犯的错，比如用废弃 API、漏 import、选错库、看着对但跑不通的代码。把这些坑和正确做法写进去，模型就不用每次都重新踩一遍。
2. *项目约定*。维护者觉得理所当然但模型不知道的事：推荐用哪个 API、代码风格偏好、目录结构规范、测试要求。模型能生成"能跑"的代码，但不一定符合项目习惯。
3. *决策指导*。什么时候用 A 不用 B，什么场景该走哪条路。这类信息最值钱，因为文档通常只说"可以这样做"，不说"什么时候应该这样做"。

*有立场*。直接告诉模型推荐方案，不要列一堆选项让它自己选。明确的"推荐这个、不推荐那个"比给一堆等权重选项效果好得多，模型不会纠结该选哪个。

*给理由*。说"别用这个 API"不如说"这个 API 已废弃，新版本用 XX 替代"。模型遇到 skill 没覆盖到的情况时，理由能帮它推断出正确做法。光给结论不给原因，模型在边界场景下还是会乱来。

*只覆盖痛点*。不要试图把所有文档塞进 skill。只写模型反复出错的点，写清楚怎么做就行。信息越精简，模型越容易抓住重点。