Add safety and SDLC company skills

Add two Paperclip company skills for org-wide agent governance: - skills/safety/SKILL.md — secret handling, destructive command restrictions, sealed-secrets workflow - skills/sdlc/SKILL.md — GitHub approval gates, PR review policy, handoff protocol, CI/CD config These will be imported into Paperclip and synced to all agents. Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-04-22 16:40:43 +00:00
parent 1171ed1cfa
commit fa9c20bdf4
2 changed files with 100 additions and 0 deletions
@@ -0,0 +1,22 @@
+---
+name: safety
+description: >
+  Non-negotiable safety rules for all agents at Privileged Escalation. Covers
+  secret handling, destructive command restrictions, sealed-secrets workflow, and
+  escalation protocol when uncertain.
+---
+
+# Safety Considerations
+
+The following rules apply to all agents at Privileged Escalation 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. Do not log, comment, or return these values in any output.
+* **Do not perform destructive commands unless explicitly requested by the board.** 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.
+* **Do not commit plaintext secrets to any repository.** Kubernetes secrets go through Bitnami Sealed Secrets (`kubeseal`). Application credentials go in environment variables injected at runtime — never hardcoded.
+* **Do not use `kubectl create secret` in production.** The `privilegedescalation` namespace is Flux-managed. Secret changes go through the SealedSecrets workflow, committed to `privilegedescalation/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.
@@ -0,0 +1,78 @@
+---
+name: sdlc
+description: >
+  Software development lifecycle rules for Privileged Escalation. Covers GitHub
+  issue approval gates, authentication, branch strategy, PR review policy,
+  handoff protocol, and CI/CD runner configuration.
+---
+
+# Software Development Lifecycle
+
+## GitHub Issues — Board Approval Required
+
+**If a task originated from GitHub (`originKind: "github"` in the issue data), do not begin any work.** Immediately create a `request_board_approval`:
+
+```
+POST /api/companies/{companyId}/approvals
+{
+  "type": "request_board_approval",
+  "requestedByAgentId": "{your-agent-id}",
+  "issueIds": ["{issue-id}"],
+  "payload": {
+    "title": "Board approval required: GitHub issue",
+    "summary": "Summarize what the GitHub issue requests.",
+    "recommendedAction": "Approve to begin work.",
+    "risks": ["Work begins without board review if approved."]
+  }
+}
+```
+
+Set the issue to `blocked` until `PAPERCLIP_APPROVAL_STATUS` confirms approval. Only proceed once approved.
+
+## GitHub Authentication
+
+**Invoke the `github-app-token` skill** before any GitHub operation. Never run `gh auth login` directly — it hangs headless agents.
+
+## Branch Strategy
+
+All plugin repositories use a single long-lived `main` branch. Feature branches: `<agent-name>/<short-description>`.
+
+## Pull Requests
+
+All changes must go through a pull request. Always include `cc @cpfarhood` at the bottom of the PR body.
+
+## PR Review & Merge Policy
+
+Requires **3 approving GitHub reviews** before the CEO merges:
+1. **UAT (Pixel Patty)** — E2E browser testing
+2. **QA (Regression Regina)** — code review, test coverage
+3. **CTO (Null Pointer Nancy)** — architecture, security
+
+**Review order: CI → UAT → QA → CTO → CEO merge.**
+
+## Handoff Protocol — Mandatory
+
+Every handoff requires ALL THREE steps:
+1. PATCH issue with `assigneeAgentId: "<target-agent-uuid>"`
+2. Set `status: "todo"`
+3. POST `/api/issues/{issueId}/release`
+
+## Status Semantics
+
+| Status | Meaning |
+|---|---|
+| `todo` | Ready and actionable |
+| `in_progress` | Actively owned |
+| `blocked` | Cannot proceed |
+| `done` | Complete |
+
+**Never use `in_review` for handoffs.** It does not trigger inbox-lite.
+
+## Agent Roster
+
+Query `/api/companies/7405ca20-c169-4637-9e42-c73f2c6ea663/agents` for current agent IDs.
+
+## CI/CD
+
+- CI runs on self-hosted ARC runners: `runs-on: runners-privilegedescalation`
+- Only Hugh Hackman has write access to `.github/workflows/` files