privilegedescalation/org
Archived
12
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity

feat(skills): align with cross-org review

Browse Source 
- safety: drop tools section (moved to sdlc), add explicit kubectl-prod
  ban, add no-tofu-direct rule, drop the merge-gate cross-reference into
  a separate bullet
- sdlc: add Phase 0 product-analysis intake (CMPO Pawla as gate); add
  scheduled penetration testing program (Barkley owns); standardize
  authentication to Better-Auth + Google + Apple + Authentik; add
  canonical tools section (moved from safety) including ghcr.io/groombook
  registry standard; reorganize PR review sections to match the cross-org
  pattern (named SDLC pipeline phases)
This commit is contained in:
Chris Farhood
2026-05-03 19:50:22 -04:00
parent d496a67eae
commit 93e70e6d66
2 changed files with 118 additions and 66 deletions
Download Patch File Download Diff File Expand all files Collapse all files
skills/safety/SKILL.md
+6 -13
View File
@@ -2,9 +2,8 @@
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.
destructive-action gating, the SealedSecrets workflow, kubectl scope limits,
and the escalation protocol when an action's safety is uncertain.
---
# Safety
@@ -19,19 +18,13 @@ The following rules apply to every GroomBook agent without exception.
* **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 `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.
## 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.
* **Never run `tofu` directly.** Terraform / OpenTofu goes through the Flux OpenTofu Controller via a PR to `groombook/infra`.
## If you are unsure