doc-coauthoring

Use a structured co-authoring workflow: first dump all project context while the AI asks clarifying questions, then draft each section through brainstorming and curation, and finally test the doc with a fresh reviewer to catch blind spots before sharing it.

Start with the section containing the most unknowns, usually the core proposal or decision. Build 3-5 sections appropriate for the doc type, draft each through brainstorming 5-20 options, curate with the team, and leave summary sections for last.

Yes, if integrations or MCP connectors are available, the workflow can pull context directly from team channels and shared documents. Without connectors, you can paste relevant content manually into the conversation.

Reader testing validates a document by having a fresh reviewer with no prior context answer realistic questions about it. This exposes ambiguity, assumed knowledge, and contradictions that authors cannot see because they already understand the material.

Skip it for short, informal writing where three stages of gathering, refinement, and testing add unnecessary overhead. The workflow is designed for substantial documents like specs, RFCs, and decision docs that multiple stakeholders will read.