feat(skills): add sdlc, safety, and coding-standards org skills

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.

skills/safety/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: safety
+description: >
+  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_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 use `kubectl create secret` in production.** The `groombook` and `groombook-uat` namespaces are Flux-managed. Secret changes go through the SealedSecrets workflow, committed to `groombook/infra`. The `groombook-dev` namespace 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`, or `main`. Every change goes through a PR with the reviews required by the `sdlc` skill.
+
+## 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.