gog-safety_skill

Overview

This skill builds and deploys safety-profiled gogcli binaries that remove commands at compile time so disabled operations cannot be invoked at runtime. It provides L1 (draft-only), L2 (collaborate), and L3 (standard write) profiles and tooling to build, verify, deploy, and roll back safe binaries. Use it when you need an agent-facing gog with restricted permissions and provable command removal.

How this skill works

The build scripts consume a YAML safety profile that marks individual commands true/false. The generator emits Go source for only enabled commands and compiles a binary tagged with a -safe version suffix so removed commands are not present in the final artifact. Deploy scripts back up the existing gog, install the new binary, and optionally run verification checks that blocked commands are absent and allowed commands work.

When to use it

• Deploying gog for an AI agent with restricted permissions
• Isolating drafting and inbox organization from send/write capabilities (L1)
• Providing collaborative but non-sending access for assistants (L2)
• Granting full write access while blocking dangerous admin ops (L3)
• Setting up reproducible, auditable command removal for compliance or audit reviews

Best practices

• Choose the least-permissive profile that still enables required workflows (principle of least privilege).
• Verify the deployed binary shows the -safe suffix and run allow/block command checks immediately after deployment.
• Keep custom YAML profiles in version control and document why each command is enabled or disabled.
• Use the provided rollback command in automated deployment pipelines to ensure fast recovery.
• Test edge cases such as filter forwarding and sharing behaviors before granting profiles to production agents.

Example use cases

• Create an L1 binary for an assistant that drafts email and organizes inboxes but cannot send or forward messages.
• Build an L2 binary for human-in-the-loop workflows where the agent can comment and collaborate but still cannot transmit messages.
• Deploy an L3 binary for trusted automation that needs write access but must not perform dangerous admin operations.
• Cross-compile an L1 binary for ARM64 hosts (e.g., Graviton instances) when deploying agent runtimes to cloud VMs.
• Run verification after remote deployment to confirm blocked commands return help/failure and allowed commands function as expected.