| verified | true |
| lastVerifiedAt | "2026-03-05T00:00:00.000Z" |
| name | doc-coauthoring |
| description | Collaborative document creation via a structured three-stage workflow. Use for writing specs, PRDs, design docs, proposals, RFCs, and any long-form document where quality and clarity matter. Brainstorms 5-20 options per section, builds iteratively, and tests with reader sub-agents. |
| version | 1.0.0 |
| model | sonnet |
| invoked_by | both |
| user_invocable | true |
| tools | ["Read","Write","Edit","Bash","Glob","Grep","Task"] |
| agents | ["technical-writer","developer"] |
| category | writing |
| tags | ["documentation","writing","collaboration","prd","spec","proposal","rfc","design-doc"] |
| aliases | ["collaborative-writing","doc-writing","document-creation"] |
| best_practices | ["Ask clarifying questions before writing a single word","Brainstorm 5-20 options per section then curate the best","Use str_replace for targeted edits โ never reprint entire documents","Test with reader sub-agents before declaring complete","Scaffold the full document early with placeholders","Preserve authorial voice and preferences across sections"] |
| error_handling | strict |
| streaming | supported |
| source | builtin |
| trust_score | 100 |
| provenance_sha | e765802e9e6abdd1 |
Doc Co-Authoring Workflow
"Thoroughness here prevents confusion when actual stakeholders read the document."
Overview
This skill guides collaborative document creation through three structured stages: context gathering, iterative section refinement, and reader testing. The goal is to transfer the author's full intent into a document that works for readers who lack that context.
When to Invoke
Triggers for this skill:
- "Write a doc" / "Draft a proposal" / "Create a spec"
- Product Requirements Document (PRD)
- Design document / Technical spec
- RFC (Request for Comments)
- Project proposal / Business case
- Meeting agenda or summary doc
- Onboarding guide or runbook
Do not use for: short single-purpose outputs (emails, commit messages, code comments). Those are better handled inline.
Three-Stage Workflow
Stage 1: Context Gathering
Close knowledge gaps before writing anything.
Ask clarifying questions:
- What type of document is this? (PRD, design doc, proposal, RFC, runbook...)
- Who is the audience? (engineers, executives, customers, mixed...)
- What decisions should readers be able to make after reading this?
- What are the hard constraints? (length, format, deadline, approval process)
- What prior context does the author have that readers won't?
Accept info-dumps:
If the user provides a brain dump, meeting notes, or links to existing docs โ absorb everything. Extract the key requirements, constraints, and decisions already made.
Meta-context check:
- Are there existing templates or style guides to follow?
- Is there a prior version of this document?
- Are there related documents readers will cross-reference?
Stage 1 output: A clear scope statement: "We are writing a [type] for [audience] that enables [decision/action]. The document is [scope]."
Stage 2: Section-by-Section Refinement
Build the document iteratively, one section at a time.
Scaffold first:
Create a full document outline with placeholder sections immediately. This gives the author a map of where we're going and lets them see the overall structure before committing to any section.
# [Document Title]
## Overview
[placeholder โ will cover: purpose, scope, key decisions]
## Background
[placeholder โ will cover: context, motivation, prior art]
## Proposal
[placeholder โ will cover: what we're building, why this approach]
## Alternatives Considered
[placeholder โ will cover: what we ruled out and why]
## Implementation Plan
[placeholder โ will cover: phases, timeline, dependencies]
## Open Questions
[placeholder โ will cover: unresolved decisions needing input]
