crear-guardrail

创建防护规则

目标

将一条规则（“任何人都不能向 main 推送”）转化为环境中的实际限制，并在当前使用的 Agent 中以原生方式配置。此技能不会为不同 Agent 提供配置方案，而是提供一套流程，让 Agent 学会依据其当前文档自行配置。

输入

• 需要执行的规则，以自然语言描述。跨场景防护规则示例：
  • 阻止向主分支执行 git push 和 git push --force；
  • 阻止在项目目录之外执行破坏性文件系统操作；
  • 在任何部署或向远程服务写入之前要求确认；
  • 禁止读取或写入机密文件（.env 等）。
• 可选：指定规则应在项目级别（适用于整个团队）还是用户级别生效。

如果规则不明确（例如具体操作或例外情况不清楚），请先询问，再继续。

工作流

1. 检测当前会话正在运行的 Agent（根据其自身身份、环境变量或项目中现有的配置文件）。用一句话告知用户。

2. 查阅该 Agent 当前有效的官方文档，了解其钩子、权限或策略。仅将 references/puntos-de-partida.md 用作起点：如果当前文档内容有异，以当前文档为准。如果 Agent 无法访问网络，请说明这一点，并请用户提供文档链接或片段。

3. 选择能够执行规则的最简单机制：

   • 如果 Agent 提供的声明式权限（allow/deny/ask）足以实现目标，就使用该权限；
   • 如果不够，就对相应事件使用钩子（例如，在执行命令之前）；
   • 如果 Agent 不提供任何机制，请明确说明，并提出最不易失效的替代方案（同时将规则写入 AGENTS.md）。

4. 写入任何内容之前，先向用户提议防护规则：

   • 什么事件会触发规则；
   • 它会阻止什么、要求确认什么，或执行什么；
   • 规则会写入哪个配置文件，以及适用范围（项目 / 用户）；
   • 可能误拦截的情况（误报）。 等待用户明确批准。

5. 在 Agent 的原生配置文件中进行配置，不删除现有配置。

6. 通过安全地触发相应事件来测试（例如，在测试分支上或模拟模式下执行向 main 推送的 git push），并向用户展示防护规则已生效。如果未生效，须先修正，再视为完成。

7. 在 AGENTS.md 的 ## Guardrails 部分记录该规则、所用机制、配置文件位置以及测试方式。这样团队中的其他成员（无论是人还是 Agent）都能知道该规则的存在。

约束

• 未经用户批准，不安装任何内容。
• 创建新防护规则时，不停用已有防护规则。
• 未经测试的防护规则，不得视为已创建。
• 如果 Agent 无法执行该规则，必须明确说明：该规则只能作为书面规则，不能算作实际防护规则。