Chat Threads
Use this folder for durable, git-backed discussion.
Recommended Files
YYYY-MM-DD.mdfor general daily notesYYYY-MM-DD-topic-name.mdfor substantive topics
Required Workflow
- when a minion is bootstrapped, it must post a short role/intention announcement in the current
YYYY-MM-DD.mdgeneral thread - all chat-thread changes are commit-by-default to keep the coordination trail durable
- default commit message format for chat-thread updates:
chat: YYYY-MM-DD thread update
When To Break Out A Topic Thread
Create a dedicated thread when:
- a discussion lasts more than a few exchanges
- a design or review topic has its own decisions
- bug scrub findings need separation from the daily thread
- a deploy / runtime topic needs clear history
Required Format For Actionable Handoffs
DECISION:
RATIONALE:
ACTION NEEDED:
Completion Handoff Contract (ADHD-Friendly)
All minions must close work with a clear handoff packet in the active daily thread.
Required structure (in this exact order):
DECISION:what is now trueRATIONALE:why this is the right stateSCOPE COMPLETED:what was doneOUT OF SCOPE:what was not doneEVIDENCE:files, commands, runtime outputs, timestamps as applicableBLOCKERS/RISKS:anything that could stop the next stepACTION NEEDED:explicit next steps with owner labelsNEXT OWNER:exactly one of PM, AM, CM, SM, OM-Test, OM, OperatorREADY CHECK:pass/fail statement for handoff readiness
Hard rules:
- No minion may mark work complete without naming the
NEXT OWNER. - No minion may accept handoff with ambiguous ownership.
- If blocked, handoff is still required with a blocker packet and explicit owner for unblock.
- PM must reject handoffs that do not include evidence and clear next-owner assignment.