crear-guardrail

Create guardrail

Goal

Turn a rule ("nobody pushes to main") into a real limit of the environment, configured natively in the agent being used. The skill does not bring recipes per agent: it brings the procedure so that the agent learns to configure itself with its current documentation.

Input

• The rule to enforce, in natural language. Examples of cross-cutting guardrails:
  • block git push to the main branch and git push --force;
  • block destructive commands on the filesystem outside the project;
  • ask for confirmation before any deploy or write against a remote service;
  • prevent reading or writing secret files (.env and similar).
• Optional: whether it should apply at the project level (the whole team) or the user level.

If the rule is not clear (what action, what exception), ask before continuing.

Workflow

1. Detect which agent is running this session (by its own identity, environment variables or configuration files present in the project). State it to the user in one line.

2. Check the current official documentation of that agent about hooks, permissions or policies. Use references/puntos-de-partida.md only as a starting point: if the current documentation differs, the current documentation wins. If the agent does not have web access, say so and ask the user for the link or the documentation snippet.

3. Choose the simplest mechanism that enforces the rule:

   • if the agent has declarative permissions (allow/deny/ask) that are enough, use that;
   • if that is not enough, use a hook on the corresponding event (e.g. before running a command);
   • if the agent does not offer any mechanism, state it explicitly and propose the least fragile alternative (and also leave the rule written in AGENTS.md).

4. Propose the guardrail to the user before writing anything:

   • what event triggers it;
   • what it blocks, asks to confirm or executes;
   • in which configuration file it goes and with what scope (project / user);
   • what it could block by mistake (false positives). Wait for explicit approval.

5. Configure it in the agent's native file, without deleting existing configuration.

6. Test it by triggering the event safely (e.g. a git push to main on a test branch or in simulation mode) and show the user that the guardrail acted. If it did not act, it is fixed before considering it done.

7. Record it in AGENTS.md, section ## Guardrails: the rule, the mechanism, the file where it lives and how it was tested. This way the rest of the team (human or agent) knows it exists.

Constraints

• Nothing is installed that the user has not approved.
• Existing guardrails are not disabled to create a new one.
• A guardrail that has not been tested is not considered created.
• If the agent does not allow enforcing the rule, it is stated: the rule remains a written rule, not a false guardrail.