Add safety and SDLC company skills #53
@@ -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
|
||||
Reference in New Issue
Block a user