safety-guard

safety-guard 概览

safety-guard 的作用

safe-guard skill 为具有破坏性或高风险的 agent 操作增加一层保护。它最适合用来阻止危险命令、将写入限制在某个目录内，或者让自治 agent 在更少损坏生产环境、部署目标或活跃数据的前提下运行。

最适合的使用场景

如果你管理的是线上系统、让 coding agent 以全自动模式运行，或者经常处理迁移、基础设施变更、发布任务，就适合安装 safety-guard。当实际需求不只是“注意点”，而是“让不安全操作更难被执行”时，safety-guard skill 就很合适。

为什么它重要

它的核心价值在于工作流控制：这个 skill 会拦截强推、硬重置、破坏性删除、范围过大的系统清理等高风险命令，同时还能把编辑范围冻结在单一路径内。对于 safety-guard for Access Control 来说，这一点尤其有用：当模型拥有较宽的 repo 访问权限，但实际上只应该修改很小的范围时，它能有效收紧边界。

如何使用 safety-guard skill

安装并定位源文件

使用 repo 中展示的 safety-guard install 命令：
npx skills add affaan-m/everything-claude-code --skill safety-guard

先从 skills/safety-guard/SKILL.md 开始看。如果想最快理解，建议先读模式定义，再查看同一文件里链接的实现说明。

把模糊目标转成可执行提示词

safety-guard usage 这类用法最有效的前提，是把任务、风险等级和写入边界一起说清楚。好的输入会同时说明目标区域和你希望启用的护栏：

• “更新 billing API，但只允许写入 src/api/，并阻止破坏性命令。”
• “在受保护模式下运行，等我审查变更后再发布或部署。”
• “保护生产迁移工作，任何可能删除或重置状态的命令都先向我确认。”

先读会改变行为的部分

如果你想真正用好 safety-guard guide，重点看模式说明和解锁流程。repo 里最有价值的信息是三种保护模式、它监控的命令，以及精确的冻结语法。正是这些内容决定了这个 skill 在你的环境里是否真的能被执行和约束。

更容易得到好结果的工作流

当你主要想对危险命令做确认时，用 careful 模式。当你需要限制写入范围时，用 freeze 模式。当两种风险都存在时，用组合保护模式。如果任务范围很窄，就明确写出允许的目录；如果是运维类任务，就写清楚哪些具体命令或操作必须触发确认。

safety-guard skill 常见问题

safety-guard 只适合生产环境吗？

不是。它在生产环境里最有价值，但在 staging、共享 repo，以及本地自治运行中也很有帮助——因为误删、重置或发布在这些场景里同样可能造成高成本损失。

它和普通提示词有什么区别？

普通提示词依赖模型自己记住要谨慎。safety-guard skill 则把谨慎变成一套可重复执行的控制模式：它会监测高风险命令，阻止在允许树之外的写入，并把边界明确写出来。

safety-guard 适合新手吗？

适合，前提是目标简单：在 agent 编辑 repo 时保护仓库。新手最需要理解的是“基于确认的保护”和“基于目录的写入限制”之间的区别。

什么情况下不该用它？

不要把 safety-guard 当成代码审查、备份或环境权限的替代品。它是护栏，不是恢复方案。如果你的任务需要大范围、无约束的重构，freeze 模式可能会过于限制。

如何改进 safety-guard skill

给这个 skill 更清晰的边界

最有价值的改进，是把范围说明写得更明确。不要只说“注意安全”，而要说明什么必须保护、什么可以编辑、什么只能读取。输入越具体，误拦截就越少，来回沟通也越少。

说明你预期会出现的高风险操作

如果你的工作流里包含部署、发布、数据库变更或清理命令，最好一开始就说清楚。safety-guard skill 知道自己应该优先强化确认、冻结写入，还是两者都要兼顾时，调起来会更容易。

留意常见失败模式

最常见的失败模式，是冻结范围设得过大，连合理修改也被挡住。第二种是任务描述不够明确，导致 agent 不知道某个命令到底能不能执行。若第一次结果太严格，就收窄受保护路径；若太宽松，就补充明确的命令和路径限制。

在第一次运行后继续迭代

第一次执行后，调整时要看 agent 实际尝试做了什么，而不只是看它改了什么。如果它试图执行高风险命令，就在使用说明里扩大被拦截的模式；如果它跑出了预期范围，就收紧允许的目录。