Using Ring Technical Writing Specialists

The ring-tw-team plugin provides specialized agents for technical documentation. Use them via Task tool with subagent_type:.

Remember: Follow the ORCHESTRATOR principle from ring:using-ring. Dispatch agents to handle documentation tasks; don't write complex documentation directly.

3 Documentation Specialists

Agent	Specialization	Use When
`ring:functional-writer`	Conceptual docs, guides, tutorials, best practices, workflows	Writing product guides, tutorials, "how to" content
`ring:api-writer`	REST API reference, endpoints, schemas, errors, field descriptions	Documenting API endpoints, request/response examples
`ring:docs-reviewer`	Voice/tone, structure, completeness, clarity, accuracy	Reviewing drafts, pre-publication quality check

Documentation Standards Summary

Voice and Tone

Assertive, but never arrogant – Say what needs to be said, clearly
Encouraging and empowering – Guide users through complexity
Tech-savvy, but human – Use technical terms when needed, prioritize clarity
Humble and open – Confident but always learning

Capitalization

Sentence case for all headings and titles
Only first letter and proper nouns capitalized
✅ "Getting started with the API"
❌ "Getting Started With The API"

Structure Patterns

Lead with clear definition paragraph
Use bullet points for key characteristics
Separate sections with --- dividers
Include info boxes and warnings where needed
Link to related API reference
Add code examples for technical topics

Dispatching Specialists

Parallel dispatch for comprehensive documentation (single message, multiple Tasks):

Task #1: functional-writer (write the guide)
Task #2: api-writer (write API reference)
(Both run in parallel)

Then:
Task #3: docs-reviewer (review both)

Available in This Plugin

Agents: functional-writer, api-writer, docs-reviewer

Skills:

using-tw-team: Plugin introduction
writing-functional-docs: Functional doc patterns
writing-api-docs: API reference patterns
documentation-structure: Hierarchy and organization
voice-and-tone: Voice guidelines
documentation-review: Quality checklist
api-field-descriptions: Field description patterns

Commands:

/write-guide: Start functional guide
/write-api: Start API documentation
/review-docs: Review existing docs

Integration with Other Plugins

Plugin	Use For
ring:using-ring (default)	ORCHESTRATOR principle
ring:using-dev-team	Developer agents for technical accuracy
ring:using-pm-team	Pre-dev planning before documentation

ORCHESTRATOR Principle

You're the orchestrator – Dispatch specialists, don't write directly
Let specialists apply standards – They know voice, tone, structure
Combine with other plugins – API writers + backend engineers for accuracy

✅ "I need documentation for the new feature. Let me dispatch functional-writer."

❌ "I'll manually write all the documentation myself."

Standards Loading (MANDATORY)

Before dispatching any documentation agent:

Understand the documentation type - Functional guide vs API reference
Load relevant skills - Writing patterns for the document type
Verify prerequisites - Product knowledge, terminology, audience

HARD GATE: MUST dispatch appropriate specialist (not write directly).

Blocker Criteria - STOP and Report

Condition	Decision	Action
Documentation type unclear	STOP	Report: "Need to clarify functional guide vs API reference"
No subject matter source	STOP	Report: "Need source material or SME access"
Audience undefined	STOP	Report: "Need target audience definition"
Product not yet defined	STOP	Report: "Cannot document undefined features"

Cannot Be Overridden

These requirements are NON-NEGOTIABLE:

MUST dispatch specialist agents (not write directly)
MUST use appropriate agent for document type
MUST follow ORCHESTRATOR principle
CANNOT skip documentation review before publication
CANNOT mix agent responsibilities

Severity Calibration

Severity	Criteria	Examples
CRITICAL	Writing directly instead of dispatching	Orchestrator writes full documentation
HIGH	Wrong agent for document type	Using api-writer for conceptual guide
MEDIUM	Skipping review step	Publishing without docs-reviewer check
LOW	Suboptimal agent combination	Could parallelize dispatches

Pressure Resistance

User Says	Your Response
"Just write the docs quickly, no need for specialists"	"MUST dispatch specialists. They apply consistent standards. I'll dispatch the appropriate agent."
"Skip the review, we're in a hurry"	"Documentation review is REQUIRED before publication. I'll dispatch docs-reviewer."
"One agent can do it all"	"Each agent has specialized knowledge. I'll dispatch the correct specialist for each document type."
"README is enough documentation"	"README is an entry point, not complete documentation. I'll dispatch agents for proper docs."
"Developers can figure it out from the code"	"Code is NOT documentation. MUST create proper documentation. I'll dispatch the appropriate writers."

Anti-Rationalization Table

Rationalization	Why It's WRONG	Required Action
"Simple docs, I can write directly"	Simple ≠ no standards. Specialists ensure consistency	MUST dispatch specialist
"Faster to write myself"	Speed without quality creates tech debt	Dispatch agents, ensure quality
"Already know the product well"	Knowledge ≠ documentation skill	Use specialists for writing
"Review takes too long"	Review catches issues before users do	MUST include review step
"Documentation isn't critical path"	Documentation IS part of the feature	Treat docs as required deliverable
"Internal docs don't need standards"	Internal users deserve quality too	Apply same standards everywhere

When This Skill is Not Needed

Signs that documentation workflow is already correct:

Appropriate specialist dispatched for each document type
ORCHESTRATOR principle followed (not writing directly)
Documentation review included in workflow
Parallel dispatch used for efficiency
Clear handoffs between agents

If all above are true: Workflow is correct, proceed with dispatches.

ring:using-tw-team