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