/using-tw-team
Using the ring-tw-team plugin and orchestrating its documentation specialists in parallel: guide-writer (guides/concepts/tutorials), api-writer (REST API reference), and docs-reviewer (quality review). Use when creating functional or API documentation, or reviewing doc quality.
$ npx -y skills add LerianStudio/ring --skill using-tw-team --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/using-tw-team
Context preview
The summary Claude sees to decide when to auto-load this skill.
Using the ring-tw-team plugin and orchestrating its documentation specialists in parallel: guide-writer (guides/concepts/tutorials), api-writer (REST API reference), and docs-reviewer (quality review). Use when creating functional or API documentation, or reviewing doc quality.
SKILL.md
using-tw-team.SKILL.mdname: ring:using-tw-team
description: "Using the ring-tw-team plugin and orchestrating its documentation specialists in parallel: guide-writer (guides/concepts/tutorials), api-writer (REST API reference), and docs-reviewer (quality review). Use when creating functional or API documentation, or reviewing doc quality. Skip when writing code (use dev-team) or writing plans (use pm-team)."
Using Ring Technical Writing Specialists
When to use
- Need to write functional documentation (guides, conceptual docs, tutorials)
- Need to write API reference documentation
- Need to review existing documentation quality
- Writing or updating product documentation
Skip when
- Writing code → use dev-team agents
- Writing plans → use pm-team agents
- General code review → use `ring:reviewing-code` with dev-team reviewer agents
Related
**Similar:** ring:using-ring, ring:using-dev-team
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:guide-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
1. Lead with clear definition paragraph 2. Use bullet points for key characteristics 3. Separate sections with `---` dividers 4. Include info boxes and warnings where needed 5. Link to related API reference 6. Add code examples for technical topics
---
Dispatching Specialists
**Parallel dispatch** for comprehensive documentation (single turn, multiple Tasks):
Task #1: guide-writer (write the guide)
Task #2: api-writer (write API reference)
(Both run in parallel)
Then:
Task #3: docs-reviewer (review both)
⛔ MUST NOT trickle-dispatch
Tasks #1 and #2 leave in the SAME TURN, before reading either's output. Forbidden: dispatch #1 → read result → dispatch #2. If you find yourself about to dispatch #2 in a turn AFTER #1 has already returned → STOP, report the violation, and re-dispatch both together. Task #3 runs only after both #1 and #2 complete — that sequencing is intentional; the trickle inside the parallel pair is not.
Parallel dispatch — atomic batch
Emit both Task calls in a SINGLE TURN as one atomic batch. If your runtime exposes a `multi_tool_use.parallel` wrapper, use it. The anti-trickle guard above remains binding.
---
Available in This Plugin
**Agents:** guide-writer, api-writer, docs-reviewer
**Skills:**
- using-tw-team: Plugin introduction
- structuring-documentation: Hierarchy and organization
- applying-voice-and-tone: Voice guidelines
- reviewing-docs: Quality checklist
**Commands:**
- /ring:reviewing-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 guide-writer." > > ❌ "I'll manually write all the documentation myself."
---
Read more
name: ring:using-tw-team description: "Using the ring-tw-team plugin and orchestrating its documentation specialists in parallel: guide-writer (guides/concepts/tutorials), api-writer (REST API reference), and docs-reviewer (quality review). Use when creating functional or API documentation, or reviewing doc quality. Skip when writing code (use dev-team) or writing plans (use pm-team)."
Using Ring Technical Writing Specialists
When to use
- Need to write functional documentation (guides, conceptual docs, tutorials)
- Need to write API reference documentation
- Need to review existing documentation quality
- Writing or updating product documentation
Skip when
- Writing code → use dev-team agents
- Writing plans → use pm-team agents
- General code review → use `ring:reviewing-code` with dev-team reviewer agents
Related
**Similar:** ring:using-ring, ring:using-dev-team
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:guide-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
1. Lead with clear definition paragraph 2. Use bullet points for key characteristics 3. Separate sections with `---` dividers 4. Include info boxes and warnings where needed 5. Link to related API reference 6. Add code examples for technical topics
---
Dispatching Specialists
**Parallel dispatch** for comprehensive documentation (single turn, multiple Tasks):
Task #1: guide-writer (write the guide) Task #2: api-writer (write API reference) (Both run in parallel) Then: Task #3: docs-reviewer (review both)
⛔ MUST NOT trickle-dispatch
Tasks #1 and #2 leave in the SAME TURN, before reading either's output. Forbidden: dispatch #1 → read result → dispatch #2. If you find yourself about to dispatch #2 in a turn AFTER #1 has already returned → STOP, report the violation, and re-dispatch both together. Task #3 runs only after both #1 and #2 complete — that sequencing is intentional; the trickle inside the parallel pair is not.
Parallel dispatch — atomic batch
Emit both Task calls in a SINGLE TURN as one atomic batch. If your runtime exposes a `multi_tool_use.parallel` wrapper, use it. The anti-trickle guard above remains binding.
---
Available in This Plugin
**Agents:** guide-writer, api-writer, docs-reviewer
**Skills:**
- using-tw-team: Plugin introduction
- structuring-documentation: Hierarchy and organization
- applying-voice-and-tone: Voice guidelines
- reviewing-docs: Quality checklist
**Commands:**
- /ring:reviewing-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 guide-writer." > > ❌ "I'll manually write all the documentation myself."
---
Proven engineering practices, enforced through skills. Ring is a comprehensive skills library and workflow system for AI agents that transforms how AI assistants approach software development.
Repo: LerianStudio/ring
Other skills on ring.
- /analyzing-options
Analyzing different approaches for a task or problem with structured comparisons, effort estimates, and recommendations. Use when facing strategic decisions, architecture choices, or multiple viable approaches. Skip when there's an obvious single approach or the decision is
Open skill - /auditing-production-readiness
Auditing a service's production readiness against Ring engineering standards across base dimensions plus a conditional multi-tenant dimension, then emitting a scored report and an HTML dashboard. Use before production deploy, periodic review, onboarding, or a major release. Skip
Open skill - /cleaning-comments
Cleaning redundant and obvious comments following clean code principles while preserving meaningful documentation. Supports git scope filtering (staged, unstaged, branch, commit-range). Use when code has excessive comments, during code review, or post-refactor cleanup. Skip when
Open skill - /committing-changes
Commit changes with scope allowlist enforcement, atomic grouping, GPG-signed conventional commits, and trailer management. Detects the repo's PR-validation scope policy before proposing any message. Use when the user asks to commit or has changes ready to record. Skip when the
Open skill - /creating-handoffs
Creating a handoff document that captures session state (completed work, decisions, open items, next steps) and delivering it via Plan Mode so the user gets the native 'clear context and continue implementing' resume option. Use when ending a session, when context grows large,
Open skill - /creating-worktrees
Creating an isolated git worktree for parallel branch work: selects the directory by priority order, verifies/adds .gitignore safety, auto-installs the detected toolchain's dependencies, runs a baseline test, and reports readiness. Use before a feature that needs isolation from
Open skill

