/document
Called by team.md router when action is `document`. Creates any document type: PRD, guide, runbook, architecture doc, etc.
$ npx -y skills add coco-research/coco --agent claude-codeHow it fires
How this command gets triggered: by you, by Claude, or both.
- Fires itselfClaude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/document
Context preview
What this command does when you run it.
Called by team.md router when action is `document`. Creates any document type: PRD, guide, runbook, architecture doc, etc.
Command definition
document.md/team document — Documentation Pipeline
> Called by team.md router when action is `document`. > Creates any document type: PRD, guide, runbook, architecture doc, etc.
Role Selection Bias
| Layer | Preferred Roles | Count | |-------|----------------|-------| | L1 | business-analyst, technical-analyst | 2 | | L2 | senior-pm, technical-writer, confluence-specialist (if Confluence target) | 2-3 | | L3 | doc-quality, grammar-editor, standards-reviewer | 3 | | L4 | principal-pm | 1 |
Document Type Detection
Parse scope to detect document type:
- "PRD" / "requirements" → senior-pm as L2 lead, use prd-generator from toolkit
- "architecture" / "design doc" → this action WRITES UP an architecture for an audience;
it does not decide one. Put technical-writer + solution-architect in L2. Add architecture-reviewer and domain-accuracy to the L3 roster, because the default roster of doc-quality, grammar-editor, and standards-reviewer checks structure, tone, and template conformance only — none of them can tell whether the architecture being described is technically sound. If `.arch/index.json` is absent, offer `/team arch build` first, so the document rests on a validated component map rather than an improvised one. For a formal published document, prefer /util:create-architecture-documentation, which produces C4, arc42, ADR, PlantUML, and Structurizr output.
- "runbook" / "playbook" → sre-devops in L2
- "API docs" → technical-writer + senior-backend-eng in L2
- "onboarding" / "guide" → technical-writer + ux-researcher in L1
- "DR plan" → sre-devops + senior-cloud-architect in L2, use /pmstudio-dr from toolkit
- "IRP" / "incident" → sre-devops in L2, use /pmstudio-irp from toolkit
- Default → technical-writer lead in L2
Pipeline Customization
Layer 1: Context Gathering
L1 agents collect:
- Existing documentation on the topic
- Source material (code, configs, meeting notes)
- Stakeholder requirements for the document
- Template requirements (consulting format, Confluence structure, etc.)
Layer 2: Document Creation
- **Mode:** `default` (creates documents but doesn't modify code)
- Primary author (role depends on document type) writes the document
- Secondary roles contribute specialized sections
**Toolkit integration:**
- Check team:toolkit.md for the relevant document type
- If a PM Studio skill is recommended → invoke it, then L3 reviews the output
- Apply all quality notes from previous runs
- If toolkit says "skip tool" for this case → write directly
Layer 3: Quality Review (Heavy)
This is where the document gets polished:
- **doc-quality** → Structure, completeness, flow
- **grammar-editor** → Tone, grammar, readability, consulting voice
- **standards-reviewer** → Template conformance, formatting
L3 is intentionally heavy for document actions because document quality directly impacts stakeholder perception.
Layer 4: Final Polish
Principal reviews for:
- Does this serve the audience?
- Is the core message clear?
- What should be cut?
- Is this ready for distribution?
GSD Integration
When `.planning/` exists, documents reference phase context from ROADMAP.md. PRDs align with GSD requirements.
Read more
/team document — Documentation Pipeline
> Called by team.md router when action is `document`. > Creates any document type: PRD, guide, runbook, architecture doc, etc.
Role Selection Bias
| Layer | Preferred Roles | Count | |-------|----------------|-------| | L1 | business-analyst, technical-analyst | 2 | | L2 | senior-pm, technical-writer, confluence-specialist (if Confluence target) | 2-3 | | L3 | doc-quality, grammar-editor, standards-reviewer | 3 | | L4 | principal-pm | 1 |
Document Type Detection
Parse scope to detect document type:
- "PRD" / "requirements" → senior-pm as L2 lead, use prd-generator from toolkit
- "architecture" / "design doc" → this action WRITES UP an architecture for an audience;
it does not decide one. Put technical-writer + solution-architect in L2. Add architecture-reviewer and domain-accuracy to the L3 roster, because the default roster of doc-quality, grammar-editor, and standards-reviewer checks structure, tone, and template conformance only — none of them can tell whether the architecture being described is technically sound. If `.arch/index.json` is absent, offer `/team arch build` first, so the document rests on a validated component map rather than an improvised one. For a formal published document, prefer /util:create-architecture-documentation, which produces C4, arc42, ADR, PlantUML, and Structurizr output.
- "runbook" / "playbook" → sre-devops in L2
- "API docs" → technical-writer + senior-backend-eng in L2
- "onboarding" / "guide" → technical-writer + ux-researcher in L1
- "DR plan" → sre-devops + senior-cloud-architect in L2, use /pmstudio-dr from toolkit
- "IRP" / "incident" → sre-devops in L2, use /pmstudio-irp from toolkit
- Default → technical-writer lead in L2
Pipeline Customization
Layer 1: Context Gathering
L1 agents collect:
- Existing documentation on the topic
- Source material (code, configs, meeting notes)
- Stakeholder requirements for the document
- Template requirements (consulting format, Confluence structure, etc.)
Layer 2: Document Creation
- **Mode:** `default` (creates documents but doesn't modify code)
- Primary author (role depends on document type) writes the document
- Secondary roles contribute specialized sections
**Toolkit integration:**
- Check team:toolkit.md for the relevant document type
- If a PM Studio skill is recommended → invoke it, then L3 reviews the output
- Apply all quality notes from previous runs
- If toolkit says "skip tool" for this case → write directly
Layer 3: Quality Review (Heavy)
This is where the document gets polished:
- **doc-quality** → Structure, completeness, flow
- **grammar-editor** → Tone, grammar, readability, consulting voice
- **standards-reviewer** → Template conformance, formatting
L3 is intentionally heavy for document actions because document quality directly impacts stakeholder perception.
Layer 4: Final Polish
Principal reviews for:
- Does this serve the audience?
- Is the core message clear?
- What should be cut?
- Is this ready for distribution?
GSD Integration
When `.planning/` exists, documents reference phase context from ROADMAP.md. PRDs align with GSD requirements.
Meet Coco. A superintelligent agent framework powered by an advisory board of 389 world-class minds. Scale your AI assistant into a complete engineering department with 142 skills, 277 commands, and persistent state. Universal compatibility. Local privacy. Free and open source.
Repo: coco-research/coco
Other commands on coco.
- /mermaid
Build beautiful Mermaid diagrams using beautiful-mermaid. Covers all 6 diagram types, theming, SVG/ASCII output, and CoCo Platform integration.
Open command - /read
Show latest emails from a specific person. Usage: /email-read alice
Open command - /reply
Draft a reply to a specific email. Usage: /email-reply Project Phase 2 Contract Data
Open command - /save
Save matching emails to a project folder for sync processing. Usage: /email-save alice to emails/
Open command - /search
Search emails by subject keywords. Usage: /email-search github webhook
Open command - /summary
AI summary of today's emails — key decisions, action items, meetings. No arguments needed.
Open command

