Skill 的局限和常见坑
分清安装与执行，处理项目规则冲突，用实际产物判断 Skill 是否有用。
安装成功不等于任务成功
Skill 通常包含说明、参考资料，也可能带脚本。安装器把这些文件放好，并不代表 Python 包、系统程序、字体、账号和 API 都准备好了。
首次使用选一个小任务，要求返回目标文件，再检查内容。生成 PPT 后打开看排版；上传公众号后确认草稿；部署后访问实际地址。每一步对应不同结果。
全局目录放太多
客户端通常先读取技能名称和描述，再按需加载正文。装得越多，候选越多，也越容易遇到描述相近或规则重叠。
项目专属知识放项目目录；全局只保留反复使用的能力。定期查看是否重复或失效，不用按“一个月没用”自动删除，也不用凑安装数量。
通用计划、调试、评审等流程是否值得安装，见 通用流程 Skill。
Skill 不能保证方法正确
先检查它补充了什么：独有资料、运行脚本、稳定模板，还是只换了一种提示词写法。输出更长、步骤更多，都不能证明结果更好。
把同一份输入分别交给直接提示词和 Skill，比较准确性、可用性、时间和修订量。对自己的工作没有改善，就无需常驻。
流程过长或过于强制
把能独立完成的任务分开。正文说明默认流程，细节放参考文件；出现缺失输入、依赖失败时停止对应步骤并说明原因。
“必须执行”写在正文里仍依赖模型遵循。需要可靠拦截时，用客户端支持的 Hook、权限控制或确定性脚本，并确认配置实际生效。
与项目规则冲突
例如项目要求只提交本次修改，而某个 Skill 要求 git add -A。先指出冲突，遵循当前项目约束，再修订 Skill。
Skill 无法通过自称“覆盖项目设置”获得更高权限。不要在多个文件重复维护同一套规范。
更新覆盖本地修改
自己修改过的 Skill 先保存到 Git 或备份。更新时明确项目或全局范围，看差异后再运行样例。锁文件能记录来源，不应当被当成精确恢复历史版本的保证。
具体命令见 npx skills 指南。
来源与数据使用
阅读源码，确认它会读哪些文件、向哪些服务传数据，以及是否需要这些操作。联网 OCR、云端生图等任务可能合理使用外部 API；是否合理取决于任务和数据处理方式，不能用“文档 Skill 一律不能联网”判断。
官方来源、下载量和自动扫描能帮助筛选，但实际脚本、依赖和权限仍要与任务对应。