1. 写清任务和可观察结果
用一句话描述任务,再写出证明完成的产物或行为。“改进项目”太宽泛;“审查这次拉取请求,并用文件位置指出安全敏感影响范围”才可测试。
如果结果无法观察,先不要安装。应先澄清决策或拆分任务。
- 一个任务、一个负责人、一个有限范围。
- 人工可以检查的结果。
- 明确停止条件与回滚。
2. 分配一个独立角色
选择缺失角色:发现、规划、生成、规则检查、审查或证据。比较承担同一角色的候选项,拒绝被不同品牌包装的职责重叠。
大型收藏会增加触发歧义和权限面。只有当前角色已经产出有用且可审查的结果,才加入下一个。
3. 检查完整来源
打开 SKILL.md 以及所有引用脚本、模板、可执行文件和外部服务,记录已审查仓库与版本。顶层文件很短,也可能把强大行为委托到其他位置。
工作流只属于一个仓库时优先项目安装;只有准备跨项目维护的共享行为才使用个人范围。
4. 让权限匹配第一次测试
列出文件读写、命令、浏览器控制、网络、凭据、发布和破坏性操作,移除第一次小任务不需要的访问。
兼容性与安装是两回事。Agent 能发现文件夹,不代表脚本、Hook、依赖或操作系统假设一定能运行。
5. 运行受控测试并记录证据
使用有代表性但不敏感的输入、可撤销环境、明确检查项和已知初始状态,记录 Skill 实际读取、写入、执行、联系和产出的内容。
一次成功只证明当前来源版本、Agent、环境和任务;来源、模型、依赖、权限或平台出现重要变化后应重新测试。
- 检查预期触发与无关任务不触发。
- 实际访问保持在约定边界。
- 产物通过命名的验收检查。
- 回滚恢复初始状态。
安装时就定义移除条件
采用前就写清移除条件:复审周期内未使用、与其他角色重复、来源变得不清、权限扩大、停止维护、产物质量下降,或被原生能力替代。
最好的组合不是选项最多,而是你仍能解释来源、触发、权限、产物和负责人的最小集合。