4.1 KiB
4.1 KiB
Collaboration Playbook
This is the high-level operating pattern behind the minion workflow.
Core Idea
Keep the repo as the durable source of coordination truth.
- mail is for actionable request/response/verdict packets
- chat is for PM summaries, continuity, and operator-facing recap
- plans are for formal scope and gates
- role files define responsibilities
- runtime truth is validated separately from commit history
- handoffs must be commit-backed; push is required whenever the next owner is on a different computer
Mailbox-First Coordination
Use a mailbox-style packet model for primary minion communication.
minions/mail/is the primary coordination surface- one packet thread gets one packet directory
- one owned message gets one owned file
- sender writes
request.md - recipient writes
response.md - gate owner writes
verdict.mdwhen needed PMmirrors outcomes into shared state docs and same-day chat summary
minions/chat/ is still durable, but it is no longer the default multi-writer
request/response surface.
See docs/project/mailbox-collaboration-model.md for the full operating model.
Rollout posture:
- existing in-flight legacy chat packets may finish where they started
- all new follow-up packets should open in
minions/mail/ PMshould leave transition notes in legacy packets during staged rollout
Recommended Lifecycle
PMopens a mailbox packet or plan packetAMreviews architecture/design when work changes system boundaries, data flow, major dependencies, or overall design directionSMreviews architecture foundations and risk posture when the work changes trust boundaries or security exposureCMresponds with findings or implementation inside the approved architectureOM-Test/OMverifies deployed/runtime truth when relevant and reports runtime-design mismatchesPMaccepts, rejects, or narrows the next stepOperatorreviews live results and raises human concerns
PM-Owned Onboarding
Before normal execution cadence, PM runs onboarding with the Operator and captures decisions in docs/operator-onboarding-checklist.md.
Onboarding should explicitly set:
- who fills the
AMrole and how architecture decisions will be captured - the default handoff sync mode for each role:
commit-onlyorcommit-and-push - where the vendored template snapshot will live (recommended
.minions-template/) - who owns downstream template upgrades (default
PM) - whether escalation response clocks are enabled for this project
- how
CHANGELOG.md,ROADMAP.md, andTODO.mdwill be maintained - project-specific guardrail additions beyond template defaults
Onboarding should use docs/downstream-onboarding-playbook.md, not a blind
repo copy.
- vendor an export-ready template snapshot into
.minions-template/with.git/anddo-not-exportfiles excluded - export the live operating files using
docs/export-manifest.md - manually merge
INIT.md,MEMORY.md,docs/operator-onboarding-checklist.md, andminion-version.md - commit the vendored snapshot and exported live state together as the initial baseline
Downstream Upgrades
Use PM as the default owner for downstream template upgrades.
- onboarding should establish
.minions-template/first; upgrades depend on that baseline - keep the approved export-ready template snapshot in
.minions-template/ - stage the incoming export-ready template in a temporary path such as
.minions-template.next/ - compare old template, new template, and live downstream files before changing production minion docs
- use
docs/export-manifest.mdto decide whether each file is replaced, manually merged, or left downstream-owned - update the downstream base template version only after the live files and vendored snapshot both match the approved upgrade
Common Failure Modes This Prevents
- code merged but not deployed
- deployed but not actually running
- architecture drifting without an explicit owner
- PM approving commit history instead of runtime truth
- packet discussion being lost or overwritten between sessions
- role boundaries blurring under pressure