Skill.md
Tool Permission System
每个能改文件、跑命令、调外部 API 的 agent，迟早都要回答同一个问题：这次工具调用，该自动放行、该问用户、还是该直接拒绝？如果把这个判断散落在各个工具代码里，安全策略会越积越乱，也没人说得清边界在哪。这个 skill 把它收敛成一条权限流水线——每次工具调用执行前都走同一条管道，它是唯一决定 allow / ask / deny 的地方。
核心架构
流水线的顺序是刻意设计的，从最硬的拦截到最宽松的默认逐层短路：
| 层 | 作用 |
|---|---|
| deny rules | 硬否决，立即拒绝 |
| ask rules | 强制确认，绕过模式也跳不过 |
checkPermissions() | 工具自身的特定逻辑 |
| safetyCheck | 危险路径（.git/、.claude/、shell 配置）弹框，免疫 bypass |
| bypass 模式 | 快速通过，立即允许 |
| allow rules | 白名单，立即允许 |
| 默认 | passthrough → 询问用户 |
决策只有三种行为：allow、deny、ask。不要发明新状态。
分层规则来源
规则按作用域分层，优先级从高到低：policySettings（企业管理员，不可覆盖）→ userSettings → projectSettings → localSettings → cliArg → command → session。关键在于，冲突由行为顺序裁决：管道先查所有来源的 deny，再查 ask，最后才查 allow——所以企业的强制规则永远压得过用户的白名单。
适用场景
当你要构建或审查这些能力时使用：
- 工具调用的 allow / ask / deny 决策
- 跨项目 / 用户 / 企业多作用域的规则配置
- 工具级
checkPermissions()接口设计 - 不可绕过的危险操作护栏（safetyCheck）
- Hook 系统的配置格式与生命周期
- 无人值守 / CI 场景的自动 deny 与 AI 分类器 circuit breaker
如何使用
- 先实现
hasPermission(tool, input, context)，按上面的顺序短路返回。 - 为每个工具实现
checkPermissions()，处理工具特定规则和危险路径。 - 用 settings.json 配置分层规则与 hooks；无人值守场景叠加
dontAsk外层包装。
边界
这个 skill 只负责权限决策的设计与实现，不负责具体工具的业务逻辑、确认弹框的 UI、用户身份认证，也不涉及 AI 分类器的具体 prompt 工程。