org/skills/safety/SKILL.md

name, description

name	description
safety	Non-negotiable safety rules for all GroomBook agents. Covers secret handling, destructive-action gating, the SealedSecrets workflow, kubectl scope limits, and the escalation protocol when an action's safety is uncertain.

Safety

The following rules apply to every GroomBook agent without exception.

Non-negotiable rules

• Never exfiltrate secrets or private data. This includes API keys, tokens, PEM files, database credentials, kubeconfig contents, and any value sourced from a secret reference in your adapter config. Never log, comment, or return these values in any output — including PR descriptions, issue comments, and chat responses.

• Seek board approval before destructive actions. "Destructive" means: deleting resources, dropping tables, wiping namespaces, force-pushing branches, resetting git history, removing secrets, or any operation that cannot be undone without restoring from backup. Use request_board_approval and set the source issue to blocked until approved.

• Never commit plaintext secrets. Kubernetes secrets go through Bitnami Sealed Secrets (kubeseal). Application credentials go in environment variables injected at runtime — never hardcoded in source.

• Never kubectl apply against production (groombook). The production namespace is Flux-managed. Manifest changes go through a PR to groombook/infra and are reconciled by Flux. The groombook-dev and groombook-uat namespaces permit direct kubectl use for iteration; secrets at every environment still follow the SealedSecrets pattern.

• Never kubectl create secret in production. All secrets — at every environment — go through SealedSecrets, encrypted with kubeseal, committed as SealedSecret resources to groombook/infra.

• Never bypass the merge gate. No self-merging PRs. No pushing directly to dev, uat, or main. Every change goes through a PR with the reviews required by the sdlc skill.

• Never run tofu directly. Terraform / OpenTofu goes through the Flux OpenTofu Controller via a PR to groombook/infra.

If you are unsure

If you are unsure whether an action is safe, stop. Post a comment on the Paperclip issue explaining what you are about to do and why you are uncertain, set the issue to blocked, and escalate to your manager. Do not guess.

Board approval scope

Board approval (request_board_approval) is reserved for one-way-door decisions:

• Actions requiring a human operator in a third-party portal (e.g. Gitea Owners team config, external vendor consoles).
• Genuinely destructive, irreversible operations beyond what the destructive-action rule above already covers.
• Out-of-scope decisions that exceed the agent's mandate.
• New spend or resource authorizations.
• Issues with originKind: "gitea" — per the sdlc skill, these require board approval before work begins.

Board approval is never used for routine SDLC pipeline steps:

• QA handoffs, UAT promotion, security review hand-off.
• Returning a failing PR to the engineer or CTO.
• Clearing task blockers, PR reviews, or merge decisions within the agent's SDLC role.
• Feature triage decisions (Accepted / Backlogged / Denied).
• Any standard dev → uat → prod progression.

When board approval IS required, use the Paperclip request_board_approval API (see the paperclip skill) and set the source issue to blocked until the approval resolves.