Document Co-authoring Workflow

Problem

Team documents such as PRDs, RFCs, and design records often depend on context scattered across chat, linked docs, and author memory. If a model drafts from an incomplete prompt, the result can miss assumptions, be hard for readers to follow, or have unbalanced structure. This skill turns collaborative writing into a repeatable process aimed at producing a document that still works when real readers use it.

How It Works

The workflow has three stages: context collection, polishing and structure, and reader testing.
- Context collection: start with document type, audience, intended impact, template, and constraints, then ask the user to dump background, discussions, alternatives, and organizational context. It can read shared docs, Slack, Teams, Google Drive, or other connected sources when available.
- Polishing and structure: create a placeholder scaffold for the full document, then iterate section by section. Each section starts with clarification questions, generates 5-20 candidate points for the user to keep, merge, or remove, then drafts and edits only the affected parts.
- Reader testing: simulate a fresh reader or subagent with no shared context, ask likely reader questions, check for ambiguity, wrong assumptions, and contradictions, and send weak sections back for polishing.

Boundaries

This is best for collaborative documents that need repeated refinement, such as PRDs, design docs, decision records, and proposals. It does not invent missing business facts or automatically verify evidence. If links, templates, or shared context are inaccessible, users may need to paste content or enable connectors. Before publication, the author should still verify facts, links, and technical details.