claw-guardirails-skill_skill

Overview

This skill enforces guarded execution when tasks may run shell commands, post channel messages, or call external APIs/actions that can mutate data or state. It provides three safe wrappers—safe_exec, safe_send, and safe_action—and a decision resolver to allow, deny, or require explicit approval for risky operations. Use this skill to standardize permissions, contextual metadata, and safe defaults before any side-effecting operation.

How this skill works

Before any potentially destructive operation, the skill routes requests through a guardrails resolver that returns allow, deny, or require_approval. Commands that touch the shell must use safe_exec with a narrow cwd and explicit args. Outbound messages use safe_send with channel context, and external APIs or side effects use safe_action with declared resources and operations. If require_approval is returned, the skill halts and surfaces an approval id and reason until explicit approval is provided.

When to use it

• Running shell or system commands from an agent where file, process, or environment changes might occur
• Sending outbound messages or posts to channels, chat systems, or notification endpoints
• Invoking external APIs or actions that can mutate databases, delete resources, or trigger workflows
• Performing operations that could be destructive without explicit human authorization
• Any situation where you need audit metadata, least-privilege context, and reversible-first behavior

Best practices

• Always call safe_exec, safe_send, or safe_action rather than raw exec/post/API clients
• Provide the narrowest cwd, explicit args, and avoid shell expansions in safe_exec inputs
• Include sender, channel, agent context and reason metadata for every safe_* call
• Prefer read-only or reversible operations first and propose reversible alternatives
• Respect the resolver decision: do not bypass deny or require_approval without explicit flow
• Supply explicit resources and operation descriptors for safe_action to aid auditing

Example use cases

• Run git status or a readonly repo scan via safe_exec before proposing a repository change
• Notify an ops channel of deployment status using safe_send with channelType and origin metadata
• Delete an email or record only through safe_action with resources listing the target and operation
• Pause a destructive pipeline step until require_approval returns and an approver issues /approve <id>
• Audit all outbound side effects by including agent and requestor context in every safe_* call