Draft Response — Collaboration Protocol

This protocol governs how Patrick, Asia, and Claude Code collaborate on /draft-response. It describes the editorial-refinements loop that turns every response we edit together into retrievable context for future drafts. It is meant to evolve; Patrick and Asia can update it as the collaboration matures.

The core idea

Every time we draft a response, Claude Code starts from an initial inference and we refine it by layering in knowledge that wasn’t in the first cut: specific vocabulary, pedagogy nuance, boundary decisions, tonal adjustments. That editorial work is the richest teaching signal we produce. Without capture, it lives only in the finished reply; with capture, it becomes a corpus Claude Code can retrieve from on future runs.

The loop:

1. Retrieve — before drafting, Claude Code queries the vault index for prior responses and sidecars whose tags overlap with the current topic/context. Those files are loaded as context.
2. Draft — Claude Code produces an initial draft informed by voice guides, communications guide, thread history, and retrieved prior editorial context.
3. Refine — Patrick or Asia edit the draft, either by adding new information, correcting vocabulary, rebalancing tone, or changing structure. Each substantive change is a piece of editorial intelligence.
4. Capture — after the response is approved (or posted), Claude Code writes an Editorial refinements section into a durable file (a sidecar for forum replies, the contact-inquiry file for inquiries, the participant communications log for ongoing participant work). The section numbers each refinement and states the reasoning behind it (“don’t lead with anatomical terms the participant didn’t use,” “open with what they described, not with the mechanic behind it”).
5. Repeat — next time a topic with overlapping signal comes up, retrieval surfaces those captured refinements so the draft starts from a richer baseline.

What counts as a substantive editorial refinement

Worth capturing:

• Vocabulary or framing corrections (“don’t say ‘sit bones’ first; let her infer from the video”).
• Pedagogy adjustments (“the hip flexors aren’t passive at the balancing point; they actively pull the knees in to support suspension”).
• Tone rebalancing (“this is too coaching-ey; flatten it to observation”).
• Structural reorganization (“answer the direct question first, then give the principle”).
• Omissions corrected (“you forgot to mention the counter-dynamic of the legs pressing away”).
• Reuseable teaching frames (“the roll into flexion is a counter-dynamic, not a collapse”).

Not worth capturing:

• Typo fixes.
• Adding or removing an em dash (already a standing rule).
• Trivial word swaps with no reasoning behind them.
• Anything that only applies to that one person’s situation with no broader reuse value.

Rule of thumb: if Patrick or Asia could explain the change in one sentence that would help a future draft on a different but related topic, capture it. If the change is purely formatting or spelling, skip.

Where captured refinements live

Communication type	Where the Editorial refinements section lives
Forum reply on Practice Platform	Curated sidecar in 02-areas/practice-platform/community-forums-groups/primer-community/YYMMDD-slug-notes.md (or the relevant group subfolder).
Contact inquiry	The contact-inquiry file itself in 02-areas/communications/contact-inquiries/.
Participant communication (ongoing)	The participant communications log for the cohort (e.g., participant-communications-log.md inside the study group folder).
Vendor / collaborator	The communication thread file in 02-areas/communications/. If no file exists yet, create one in the appropriate subfolder.
Reference-response-worthy precedent	Additionally, an entry in 02-areas/communications/reference-responses/ with a link back to the full thread file.

In all cases, the section is a standing block with this shape:

## Editorial refinements

Captured for future cross-referencing.

**1. [Short name for the refinement].**
[One to three sentences: what changed, why, and the reusable teaching frame or principle behind it.]

**2. [Short name for the refinement].**
[...]

How retrieval works

Before drafting, Claude Code extracts signal from the request: lesson numbers, form names, segment references, dynamics (suspension, flexion, traction), topics (enrollment, deferral, certification), people named. It queries vault-index.db for files whose tags or wikilinks overlap with those signals, prioritizing:

1. Curated sidecars with Editorial refinements sections — highest-signal matches.
2. Prior synced forum topics on overlapping tags.
3. Prior contact-inquiry files from the same person or about the same topic.
4. Reference responses matching the communication type.
5. Lesson transcripts/summaries if a lesson is named.

It loads the top few matches as context before drafting. If a match is very close to the new topic, Claude Code will note that in the pre-draft confirmation so Patrick or Asia know what precedent is being drawn from.

Responsibilities

Patrick and Asia:

• When editing a draft, keep the reasoning visible when it’s non-obvious. A short sentence is enough (“no, we don’t say ‘sit bones’ first, let her infer from the video”). If the reasoning is obvious from the change itself (adding a missed mechanic, correcting a named form), no narration needed.
• If the draft is fundamentally off and you’d like a fresh pass rather than iterating, say so; a fresh pass from a corrected starting point often reads cleaner than patching over the first draft.
• When a refinement has broader reach than the current draft (a voice rule, a pedagogical principle, a workflow decision), mention that — Claude Code will both write it into the Editorial refinements section and save a memory so it takes effect across sessions.

Claude Code:

• Run the retrieval step before every substantive /draft-response run. Surface the most relevant prior editorial context in the pre-draft confirmation, named by topic (not just as a file path).
• After approval/posting, write the Editorial refinements section into the appropriate durable file. Number each refinement. State the reasoning, not just the change.
• If a refinement is reusable (voice, pedagogy, workflow), also save a memory file under memory/ so it travels across sessions.
• Do not write a sidecar or refinements section if the run produced no substantive editorial deltas (a one-line reply approved as-is is not worth a sidecar).

How this protocol evolves

This document is editable. If you find yourself repeatedly correcting the same pattern that isn’t captured here, add it. If retrieval starts surfacing matches that aren’t useful, update the ranking criteria. If a new communication type emerges that needs its own capture location, add it to the table.

When the protocol changes, commit with a clear message so the other collaborator sees the update on their next pull.

Related

• Claude Code Skills — Index
• Skill file: .claude/skills/draft-response/SKILL.md
• Communications guide: Communications Guide
• Example sidecars:
  • What moves the weight forward — curated notes
  • Keeping back foot in high-heel position — curated notes