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.
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
1---2name: lerianstudio-ring-using-tw-team3description: Using Ring Technical Writing Specialists4---56# Using Ring Technical Writing Specialists78The ring-tw-team plugin provides specialized agents for technical documentation. Use them via `Task tool with subagent_type:`.910**Remember:** Follow the **ORCHESTRATOR principle** from `ring:using-ring`. Dispatch agents to handle documentation tasks; don't write complex documentation directly.1112## 3 Documentation Specialists1314| Agent | Specialization | Use When |15|-------|---------------|----------|16| `ring:functional-writer` | Conceptual docs, guides, tutorials, best practices, workflows | Writing product guides, tutorials, "how to" content |17| `ring:api-writer` | REST API reference, endpoints, schemas, errors, field descriptions | Documenting API endpoints, request/response examples |18| `ring:docs-reviewer` | Voice/tone, structure, completeness, clarity, accuracy | Reviewing drafts, pre-publication quality check |1920---2122## Documentation Standards Summary2324### Voice and Tone25- **Assertive, but never arrogant** – Say what needs to be said, clearly26- **Encouraging and empowering** – Guide users through complexity27- **Tech-savvy, but human** – Use technical terms when needed, prioritize clarity28- **Humble and open** – Confident but always learning2930### Capitalization31- **Sentence case** for all headings and titles32- Only first letter and proper nouns capitalized33- ✅ "Getting started with the API"34- ❌ "Getting Started With The API"3536### Structure Patterns371. Lead with clear definition paragraph382. Use bullet points for key characteristics393. Separate sections with `---` dividers404. Include info boxes and warnings where needed415. Link to related API reference426. Add code examples for technical topics4344---4546## Dispatching Specialists4748**Parallel dispatch** for comprehensive documentation (single message, multiple Tasks):4950```51Task #1: functional-writer (write the guide)52Task #2: api-writer (write API reference)53(Both run in parallel)5455Then:56Task #3: docs-reviewer (review both)57```5859---6061## Available in This Plugin6263**Agents:** functional-writer, api-writer, docs-reviewer6465**Skills:**66- using-tw-team: Plugin introduction67- writing-functional-docs: Functional doc patterns68- writing-api-docs: API reference patterns69- documentation-structure: Hierarchy and organization70- voice-and-tone: Voice guidelines71- documentation-review: Quality checklist72- api-field-descriptions: Field description patterns7374**Commands:**75- /write-guide: Start functional guide76- /write-api: Start API documentation77- /review-docs: Review existing docs7879---8081## Integration with Other Plugins8283| Plugin | Use For |84|--------|---------|85| ring:using-ring (default) | ORCHESTRATOR principle |86| ring:using-dev-team | Developer agents for technical accuracy |87| ring:using-pm-team | Pre-dev planning before documentation |8889---9091## ORCHESTRATOR Principle9293- **You're the orchestrator** – Dispatch specialists, don't write directly94- **Let specialists apply standards** – They know voice, tone, structure95- **Combine with other plugins** – API writers + backend engineers for accuracy9697> ✅ "I need documentation for the new feature. Let me dispatch functional-writer."98>99> ❌ "I'll manually write all the documentation myself."100101---102103## Standards Loading (MANDATORY)104105Before dispatching any documentation agent:1061071. **Understand the documentation type** - Functional guide vs API reference1082. **Load relevant skills** - Writing patterns for the document type1093. **Verify prerequisites** - Product knowledge, terminology, audience110111**HARD GATE:** MUST dispatch appropriate specialist (not write directly).112113---114115## Blocker Criteria - STOP and Report116117| Condition | Decision | Action |118|-----------|----------|--------|119| Documentation type unclear | STOP | Report: "Need to clarify functional guide vs API reference" |120| No subject matter source | STOP | Report: "Need source material or SME access" |121| Audience undefined | STOP | Report: "Need target audience definition" |122| Product not yet defined | STOP | Report: "Cannot document undefined features" |123124### Cannot Be Overridden125126These requirements are NON-NEGOTIABLE:127128- MUST dispatch specialist agents (not write directly)129- MUST use appropriate agent for document type130- MUST follow ORCHESTRATOR principle131- CANNOT skip documentation review before publication132- CANNOT mix agent responsibilities133134---135136## Severity Calibration137138| Severity | Criteria | Examples |139|----------|----------|----------|140| **CRITICAL** | Writing directly instead of dispatching | Orchestrator writes full documentation |141| **HIGH** | Wrong agent for document type | Using api-writer for conceptual guide |142| **MEDIUM** | Skipping review step | Publishing without docs-reviewer check |143| **LOW** | Suboptimal agent combination | Could parallelize dispatches |144145---146147## Pressure Resistance148149| User Says | Your Response |150|-----------|---------------|151| "Just write the docs quickly, no need for specialists" | "MUST dispatch specialists. They apply consistent standards. I'll dispatch the appropriate agent." |152| "Skip the review, we're in a hurry" | "Documentation review is REQUIRED before publication. I'll dispatch docs-reviewer." |153| "One agent can do it all" | "Each agent has specialized knowledge. I'll dispatch the correct specialist for each document type." |154| "README is enough documentation" | "README is an entry point, not complete documentation. I'll dispatch agents for proper docs." |155| "Developers can figure it out from the code" | "Code is NOT documentation. MUST create proper documentation. I'll dispatch the appropriate writers." |156157---158159## Anti-Rationalization Table160161| Rationalization | Why It's WRONG | Required Action |162|-----------------|----------------|-----------------|163| "Simple docs, I can write directly" | Simple ≠ no standards. Specialists ensure consistency | **MUST dispatch specialist** |164| "Faster to write myself" | Speed without quality creates tech debt | **Dispatch agents, ensure quality** |165| "Already know the product well" | Knowledge ≠ documentation skill | **Use specialists for writing** |166| "Review takes too long" | Review catches issues before users do | **MUST include review step** |167| "Documentation isn't critical path" | Documentation IS part of the feature | **Treat docs as required deliverable** |168| "Internal docs don't need standards" | Internal users deserve quality too | **Apply same standards everywhere** |169170---171172## When This Skill is Not Needed173174Signs that documentation workflow is already correct:175176- Appropriate specialist dispatched for each document type177- ORCHESTRATOR principle followed (not writing directly)178- Documentation review included in workflow179- Parallel dispatch used for efficiency180- Clear handoffs between agents181182**If all above are true:** Workflow is correct, proceed with dispatches.183184---185> Converted and distributed by [TomeVault](https://tomevault.io/claim/lerianstudio) — claim your Tome and manage your conversions.186<!-- tomevault:4.0:skill_md:2026-04-11 -->
tomevault-io