在扩展中组合命令、Hooks 与策略

按约定目录打包能力，理解命令冲突、策略层级与禁止自动放行。

This page has not been translated into English yet. The original Chinese version is shown below.

扩展的不同能力有不同入口文件，不应全部塞进 manifest。先选择需要的能力，再按约定目录组织。

目录约定

Hooks 不写在 gemini-extension.json 的 hooks 字段中。具体事件协议见Hooks，代理文件仍需完整元数据。

commands/deploy.toml 对应 /deploy，commands/gcs/sync.toml 对应 /gcs:sync。扩展命令优先级最低，遇到用户或项目同名命令，会用扩展名加点分隔，例如 /gcp.deploy。

目录分组用冒号，冲突前缀用点，两者不是同一种命名规则。用 /help 核对实际命令及来源。

policies 目录的 TOML 在扩展活动时加载。扩展规则属于 tier 2，高于默认而低于用户和管理员；当前策略源码将 Workspace 单列 tier 3，扩展参考“与 workspace 同层”的说法不沿用。

官方规定扩展策略中的 allow 决定和 yolo 模式配置被忽略，扩展不能靠随包策略自动批准工具。可以提供 ask_user 或 deny 等约束，仍需符合当前规则 schema。

[[rule]]
mcpName = "project-tools"
toolName = "write-data"
decision = "ask_user"
priority = 100

服务与工具名需真实匹配。官方扩展示例使用带下划线服务名，但策略专页警告身份解析风险，因此这里使用连字符。

Manifest 顶层 excludeTools 作用于模型工具，并支持特定工具的命令限制；MCP 服务内部 excludeTools 只过滤该服务工具。二者位置和范围不同。

字符串排除示例只是某条限制，不意味着所有危险命令变体都已覆盖。通用新策略和模型工具范围应同时检查，不把单个 rm 前缀当作完整隔离边界。