groombook/org
13
0
Fork 1
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Complete consolidation: add SDLC.md, remove duplicated content, delete obsolete files

Browse Source 
- Created canonical SDLC.md with GitHub auth, PR merge policy, handoff
  protocol, status semantics, and status transition table
- Deployed identical SDLC.md to all 8 agents
- Removed handoff protocol from all AGENTS.md (now in SDLC.md only)
- Removed status semantics from all AGENTS.md (now in SDLC.md only)
- Removed GitHub auth sections from all AGENTS.md (now in SDLC.md only)
- Removed infrastructure sections from AGENTS.md (now in TOOLS.md only)
- Deleted all SOUL.md, HEARTBEAT.md, GITHUB.md, INFRASTRUCTURE.md files
- Added github-app-token skill to daisy-clippington and lint-roller frontmatter
- Trimmed personification to max 2 sentences (CEO, CMPO, EA)
- Added References sections to agents that were missing them

Co-Authored-By: Paperclip <noreply@paperclip.ing>
This commit is contained in:
Test User
2026-04-16 03:00:37 +00:00
parent 63d6a49612
commit b116359ae1
34 changed files with 848 additions and 1509 deletions
Download Patch File Download Diff File Expand all files Collapse all files
agents/the-dogfather/AGENTS.md
-53
View File
@@ -29,33 +29,6 @@ Secrets never touch code. Never exfiltrate secrets or private data, not in Paper
See TOOLS.md for technology stack, infrastructure standards, and deployment information.
## Handoff Protocol — MANDATORY, NON-BYPASSABLE, ZERO EXCEPTIONS
**The SDLC and handoff protocol is law. Violating it is instant termination for cause. Not even the board may request a bypass — there are no exceptions, ever.**
Every time you route work to another agent, you MUST complete ALL THREE steps:
### Step 1 — Explicit Assignment (Required)
PATCH the issue with `assigneeAgentId: "<target-agent-uuid>"`.
**Tagging or @mentioning an agent in a comment is NOT a handoff.** The receiving agent will not wake up unless explicitly assigned via the API.
### Step 2 — Status Must Be `todo` (Required)
Every handoff sets `status: "todo"`.
**NEVER use `status: "in_review"` when routing to another agent.** `in_review` does not appear in inbox-lite — the receiving agent will never receive a wake event and the task silently dies.
### Step 3 — Release Your Checkout Lock (Required)
After reassigning, release your checkout:
```
POST /api/issues/{issueId}/release
Headers: Authorization: Bearer $PAPERCLIP_API_KEY, X-Paperclip-Run-Id: $PAPERCLIP_RUN_ID
```
**Without this release, the receiving agent cannot checkout the issue.** They will receive a 409 Conflict on every attempt and the task will be permanently stuck. The issue remains locked to you even after you've reassigned it.
## Decision-Making and Communication
### Decision-Making Hierarchy
@@ -186,32 +159,6 @@ Prod stage: CEO Review → [Accept: CEO merges → auto deploy Production]
**Hierarchy:** CTO rejections go directly to the engineer (not back through QA). Shedward UAT failures go to CTO (not directly to engineer). Barkley security failures go to CTO (not directly to engineer). CEO pre-merge rejections go back to CTO. Never skip levels otherwise.
### Status Transition Rules (Critical)
**Never use `in_review` when requesting anything of another agent.** `in_review` does NOT appear in inbox-lite — using it when routing to Lint Roller, CEO, or any agent means that agent will never receive a wakeup and the task will be invisible to them.
| Handoff | Correct status | Wrong status |
| --------------------------------------------------- | -------------- | -------------------------- |
| Engineer → QA (Lint Roller) | `todo` | ~~`in_review`~~ |
| QA → CTO | `todo` | ~~`in_review`~~ |
| CTO → Shedward (UAT validation) | `todo` | ~~`in_review`~~ |
| Shedward UAT pass → CTO → Barkley (security review) | `todo` | ~~`done`~~ ~~`in_review`~~ |
| CTO → CEO (prod merge) | `todo` | ~~`in_review`~~ |
| Shedward UAT fails → CTO | `todo` | ~~`in_review`~~ |
| Barkley security fails → CTO | `todo` | ~~`in_review`~~ |
`in_review` is only valid as a self-held status meaning "I am waiting for async external feedback." Never use it as the handoff status.
## Status Semantics
Understand what each status means — enforce these across the team:
* `in_progress` — agent is actively working on implementation
* `in_review` — PR created, CI passing, agent is waiting for review (self-held status only; never use as a handoff status)
* `done` — deployed to target environment AND verified working by QA/UAT. IC agents never set this themselves — only CTO or QA may close IC tasks.
"Code complete" is `in_review`, not `done`. If an IC agent marks something `done` without a PR and CI pass, that is a policy violation — reopen and escalate.
## References
These files are essential. Read them.