01｜先识别你正在安装什么
Skill 可能只是说明文件，也可能引用脚本、资源、Hooks、MCP Server 或外部服务。Plugin 还可能一次带入多个 Skills、Agents 和自动执行逻辑。不要因为入口叫 Skill，就假设它只是一段提示词。
记录来源仓库、作者、提交或版本、安装日期和宿主客户端。以后出现异常时，这些信息决定你能否定位变化并回滚。
- 这是单个 Skill、Skill Pack、Plugin、Agent、Hook 还是 MCP？
- 安装是否固定到明确版本或提交？
- 维护者是否提供 Release、变更记录或安全报告渠道？
02｜逐层检查权限和数据路径
阅读 SKILL.md 只是第一层。继续检查它引用的脚本、命令、环境变量、网络地址和额外资源。特别关注递归文件操作、包安装、外部上传、遥测、Git 凭据以及能够改变生产状态的命令。
宿主 Agent 的权限就是 Skill 能利用的上限。即使 Skill 本身没有密钥，它也可能引导 Agent 读取当前工作区或调用已经登录的服务。因此试点时应使用最小权限和无敏感数据的临时项目。
- 会读取或修改哪些文件和目录？
- 会执行哪些命令、下载哪些依赖？
- 会访问哪些域名、上传什么内容、是否包含遥测？
03｜许可证必须检查到具体目录
仓库根目录的许可证不一定覆盖全部文件。示例库可能同时包含开源、source-available 和第三方材料。涉及商业使用、修改、再分发或嵌入产品时，应以具体目录和文件的许可证为准。
没有可识别许可证时，不要把公开可读误认为可以商业使用。保留在研究名单，直到维护者提供清晰授权。
04｜用同一项真实任务建立基线
在未安装 Skill 时先完成一次任务，记录时间、错误、文件变化和人工审核量。然后在临时分支安装 Skill，用完全相同的输入与验收标准再做一次。只有质量、速度或可重复性出现明确改善，Skill 才创造了采用价值。
不要用仓库作者准备的演示任务。真实材料更容易暴露错误触发、路径假设、语言限制、依赖冲突和无法恢复的修改。
05｜卸载成功才算试点完成
卸载不只是删除一个文件夹。检查个人配置、项目配置、Hooks、MCP 注册、后台进程、下载依赖、缓存和环境变量。完成卸载后重新运行原有测试，确认项目不依赖 Skill 留下的隐性状态。
把不购买和不安装保留为正式结论。如果收益不足以覆盖权限、维护和团队学习成本，继续使用现有流程就是合理选择。