Collaborative Writing Workflow Protocol

This document defines the standard workflows for collaborative writing between Patrick and Asia, mediated by Claude. The goal is to allow both people to work independently and communicate effectively via structured handoffs, without requiring real-time coordination.

---

The Inbox System

Files

• 00-inbox/patrick-inbox.md — Patrick’s review queue
• 00-inbox/asia-inbox.md — Asia’s review queue

Inbox item format

Each item is a checklist entry. Claude adds items; the person marks them done.

Machine identity attribution

Every inbox item must include a source line identifying which Claude Code instance added it. Each machine’s ~/.claude/CLAUDE.md defines its identity.

Machine	Attribution line
Patrick’s Mac Mini	*Added by Claude Code on Patrick's Mac*
Patrick’s MacBook Pro	*Added by Claude Code on Patrick's MacBook Pro*
VPS (patrick user)	*Added by Claude Code on the VPS (patrick)*
VPS (asia user)	*Added by Claude Code on the VPS (asia)*
Asia’s Mac Mini	*Added by Claude Code on Asia's Mac Mini*
Asia’s M1 Laptop (Mac Mini)	*Added by Claude Code on Asia's M1 Laptop*
Asia’s MacBook Air	*Added by Claude Code on Asia's MacBook Air*

Inbox structure

Items are grouped under date headings (## YYYY-MM-DD), newest date at the top. Individual items are ### headings under their date. An HTML comment marks the insertion point:

## Open Items
<!-- ADD NEW ITEMS DIRECTLY BELOW THIS LINE -->

## 2026-03-19

### [ ] 21:45 ET | [Document name]: [What's needed]
*Added by Claude Code on [Machine Name]*

**Document:** [file](/path/to/file/)
**Requested action:** [Review / Approve / Decision needed / Confirm guideline update]
**Summary:** [3–5 bullets max — key changes or decisions, not a full diff]
**Open question (if any):** [One specific thing that needs a decision]
**Guidelines updates pending confirmation:** [if any]

---

### [ ] 14:00 ET | [Another item same day]
...

---

## 2026-03-18

### [ ] 10:00 ET | [Older item]
...

Adding a new item:

1. Find (or create) the ## YYYY-MM-DD heading for today’s date directly below the <!-- ADD NEW ITEMS DIRECTLY BELOW THIS LINE --> marker
2. Add the ### [ ] item under that date heading
3. If today’s date heading doesn’t exist yet, create it as the first ## after the marker (pushing older dates down)

Timestamps: All inbox items include the time of day in Eastern Time (ET). Use 24-hour format: 2026-03-03 21:45 ET.

Multi-machine tasks

When a task requires action on more than one machine, include a per-machine checklist inside the item. The top-level [ ] must not be marked [x] until every machine sub-item is checked off.

### [ ] HH:MM ET | Title

**Machines required:**
- [ ] Mac Mini
- [ ] M1 Laptop

**What to do:** ...

---

Rules:

• Claude checks off only the machine it completed the task on, never the top-level checkbox.
• The top-level checkbox is marked [x] only when the person confirms (or Claude confirms on their behalf) that all machines are done.
• If a machine sub-item is completed in a different session, that session’s Claude should check it off and, if all are now done, mark the top-level item complete and move it to Completed.

When to update inboxes

• After running the post-edit workflow on any document → update the reviewer’s inbox
• After flagging a guideline change that requires the other person’s confirmation → update their inbox
• After completing a review → mark the item done and clean it up (see below)

Completed item format

When an item is done, Claude removes the full item from the open section and adds a single-line summary to the Completed section at the bottom:

- YYYY-MM-DD HH:MM ET — [Brief description of what was done]. [Link](/path/to/relevant-file/)

The open section stays uncluttered. The completed section is a lightweight log, not a detailed archive.

Notification

For now: tell each other verbally. Patrick is setting up a Slack/Discord automation to trigger on inbox file changes — this will replace verbal notification once it’s live.

---

Workflow Patterns

Pattern A: Claude drafts → Asia revises → Patrick approves

Used for: session summaries, program copy, site content that Patrick initiates.

1. Claude generates draft (per relevant project guidelines and voice guides)
2. Asia edits directly in Obsidian — no constraint on how she edits; git tracks everything
3. Asia signals to Claude: “I’m done with [document], please run the post-edit workflow”
4. Claude runs the post-edit workflow (see below)
5. Claude creates an item in Patrick’s inbox
6. Patrick reviews and approves, or flags items for discussion

Pattern B: Asia writes → Claude checks → Patrick reviews

Used for: documents Asia initiates or owns, where Patrick needs to be informed or approve.

1. Asia writes
2. Asia signals to Claude: “I’m done with [document], please prepare it for Patrick’s review”
3. Claude reviews the document against voice guides and project guidelines; flags any issues to Asia
4. Asia confirms or adjusts
5. Claude creates an item in Patrick’s inbox with a brief summary

Pattern C: Patrick writes → Claude checks → Asia reviews

Used for: documents Patrick initiates where Asia needs to review for technical accuracy or completeness.

1. Patrick writes or directs Claude to draft
2. Patrick signals to Claude: “Please prepare this for Asia’s review”
3. Claude creates an item in Asia’s inbox with summary and any questions

Pattern D: Shared guideline change → both must confirm

Used for: any proposed change to VOICE-GUIDE-UNIFIED.md or VOICE-GUIDE-GOVERNANCE.md.

Per VOICE-GUIDE-GOVERNANCE.md: one person proposes, Claude drafts the change, the other confirms in their next session. Claude notes “pending [name]‘s confirmation” in the version history until both have confirmed.

---

Post-Edit Workflow

Trigger: Asia or Patrick says “I’m done with [document], please run the post-edit workflow.”

Steps:

1. Read the git diff to understand what changed between the Claude-generated version and the edited version
2. Resolve flagged items — anything marked in the document (e.g., red text, inline notes) or mentioned verbally
3. Check for typos and surface glitches — fix directly
4. Remove process notes from the document — editorial note blocks, inline flags, color markup added during editing
5. Evaluate patterns for guidelines capture — ask: does this edit reflect a pattern that Claude would miss in a future session without a written note? If yes, propose an addition to the relevant guidelines file. If no, skip. Do not bloat guidelines with one-off decisions.
   • Check project-specific guidelines (e.g., _session-summary-guidelines.md)
   • Check voice guides (VOICE-GUIDE-UNIFIED.md or personal guide)
   • Some edits belong in both; most belong in neither
6. Create an inbox item for the next reviewer (see format above)
7. Propose guidelines updates to the person who made the edits for confirmation before writing them

---

Guideline Capture Filter

Before adding anything to a guidelines file, ask:

• Would Claude make this mistake again in a future session without this note?
• Does this apply beyond this one document?
• Is it a pattern that recurred, or was flagged explicitly as a rule?

If yes to all three: capture it. If any answer is no: leave it out.

---

Version History

Version	Date	Change	Confirmed by
1.0	2026-03-03	Initial protocol created	Asia
1.1	2026-03-04	Added multi-machine task format and completion rules	Asia
1.2	2026-03-19	Restructured inbox format: date headings (##) with items as ###, newest-first, insertion marker, removed fragile TOC blocks	Patrick