Chris Farhood
4b32e84c03
Mirrors the privilegedescalation/org pattern: extract company-wide policy that was previously inlined in each agent's AGENTS.md into three shared skills. Agents will reference these via one-line invocation reminders in their Wake additions section.
2.6 KiB
name, description
| name | description |
|---|---|
| safety | Non-negotiable safety rules for all GroomBook agents. Covers secret handling, destructive-action gating, the SealedSecrets workflow, the tools we use vs. the ones we don't, 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_approvaland set the source issue toblockeduntil 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 use
kubectl create secretin production. Thegroombookandgroombook-uatnamespaces are Flux-managed. Secret changes go through the SealedSecrets workflow, committed togroombook/infra. Thegroombook-devnamespace permits direct kubectl use for iteration but secrets there should also follow the same pattern when they reflect anything sensitive. -
Never bypass the merge gate. No self-merging PRs. No pushing directly to
dev,uat, ormain. Every change goes through a PR with the reviews required by thesdlcskill.
Tools (canonical, not alternatives)
- Secret management: Bitnami Sealed Secrets Controller — no plain Kubernetes secrets.
- Database: CloudNativePG Operator (Postgres) — no SQLite, MariaDB, or MySQL.
- Cache / pub-sub: DragonflyDB Operator — no Redis.
- Dependency updates: Mend Renovate — no Dependabot.
- Container registry:
ghcr.io— no Docker Hub for first-party images.
If a task requires deviating from any of the above, treat it as a destructive action: stop, file an issue with rationale, request board approval.
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.