/reviewing-docs
Reviewing end-user and product documentation quality across voice/tone, structure, completeness, clarity, and technical accuracy; flags issues with prioritized findings and a pass/needs-revision verdict. Use when reviewing draft docs, running a pre-publication check, auditing
$ npx -y skills add LerianStudio/ring --skill reviewing-docs --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
/reviewing-docs
Context preview
The summary Claude sees to decide when to auto-load this skill.
Reviewing end-user and product documentation quality across voice/tone, structure, completeness, clarity, and technical accuracy; flags issues with prioritized findings and a pass/needs-revision verdict. Use when reviewing draft docs, running a pre-publication check, auditing
SKILL.md
reviewing-docs.SKILL.mdname: ring:reviewing-docs
description: "Reviewing end-user and product documentation quality across voice/tone, structure, completeness, clarity, and technical accuracy; flags issues with prioritized findings and a pass/needs-revision verdict. Use when reviewing draft docs, running a pre-publication check, auditing existing docs, or enforcing style-guide compliance. Skip when writing new docs, or checking voice only (use ring:applying-voice-and-tone)."
Documentation Review Process
When to use
- Reviewing draft documentation
- Pre-publication quality check
- Documentation audit
- Ensuring style guide compliance
Skip when
- Writing new documentation → dispatch the guide-writer or api-writer agent
- Only checking voice → use ring:applying-voice-and-tone
Sequence
**Runs after:** guide-writer, api-writer (agents)
Related
**Complementary:** ring:applying-voice-and-tone, ring:structuring-documentation
Review documentation systematically across multiple dimensions. A thorough review catches issues before they reach users.
Review Dimensions
1. **Voice and Tone** – Does it sound right? 2. **Structure** – Is it organized effectively? 3. **Completeness** – Is everything covered? 4. **Clarity** – Is it easy to understand? 5. **Technical Accuracy** – Is it correct?
---
Voice and Tone Review
| Check | Flag If | |-------|---------| | Second person | "Users can..." instead of "You can..." | | Present tense | "will return" instead of "returns" | | Active voice | "is returned by the API" instead of "The API returns" | | Tone | Arrogant ("Obviously...") or condescending |
---
Structure Review
| Check | Flag If | |-------|---------| | Hierarchy | Deep nesting (H4+), unclear parent-child | | Headings | Title Case instead of sentence case | | Section dividers | Missing `---` between major topics | | Navigation | Missing links to related content |
---
Completeness Review
**Conceptual docs:** Definition, characteristics, how it works, related concepts, next steps
**How-to guides:** Prerequisites, all steps, verification, troubleshooting, next steps
**API docs:** HTTP method/path, all parameters, all fields, required vs optional, examples, error codes
---
Clarity Review
| Check | Flag If | |-------|---------| | Sentence length | >25 words per sentence | | Paragraph length | >3 sentences per paragraph | | Jargon | Technical terms not explained on first use | | Examples | Abstract data ("foo", "bar") instead of realistic |
---
Technical Accuracy Review
**Conceptual:** Facts correct, behavior matches description, links work
**API docs:** Paths correct, methods correct, field names match API, types accurate, examples valid JSON
**Code examples:** Compiles/runs, output matches description, no syntax errors
---
Common Issues to Flag
| Category | Issue | Fix | |----------|-------|-----| | Voice | Third person ("Users can...") | "You can..." | | Voice | Passive ("...is returned") | "...returns" | | Voice | Future tense ("will provide") | "provides" | | Structure | Title case heading | Sentence case | | Structure | Wall of text | Add `---` dividers | | Completeness | Missing prereqs | Add prerequisites | | Completeness | No examples | Add code examples | | Clarity | Long sentences (40+ words) | Split into multiple | | Clarity | Undefined jargon | Define on first use |
---
Review Output Format
> **Note:** Documentation reviews use `PASS/NEEDS_REVISION/MAJOR_ISSUES` verdicts (graduated), which differ from code review verdicts (`PASS/FAIL/NEEDS_DISCUSSION`).
## Review Summary
**Overall Assessment:** [PASS | NEEDS_REVISION | MAJOR_ISSUES]
### Issues Found
#### High Priority
1. **Line 45:** Passive voice "is created by" → "creates"
#### Medium Priority
1. **Line 23:** Title case in heading → sentence case
#### Low Priority
1. **Line 12:** Could add example for clarity
### Recommendations
1. Fix passive voice instances (3 found)
2. Add missing API field documentation
---
Quick Review Checklist
**Voice (30s):** "You" not "users", present tense, active voice
**Structure (30s):** Sentence case headings, section dividers, scannable (bullets/tables)
**Completeness (1m):** Examples present, links work, next steps included
**Accuracy (varies):** Technical facts correct, code examples work
---
Read more
name: ring:reviewing-docs description: "Reviewing end-user and product documentation quality across voice/tone, structure, completeness, clarity, and technical accuracy; flags issues with prioritized findings and a pass/needs-revision verdict. Use when reviewing draft docs, running a pre-publication check, auditing existing docs, or enforcing style-guide compliance. Skip when writing new docs, or checking voice only (use ring:applying-voice-and-tone)."
Documentation Review Process
When to use
- Reviewing draft documentation
- Pre-publication quality check
- Documentation audit
- Ensuring style guide compliance
Skip when
- Writing new documentation → dispatch the guide-writer or api-writer agent
- Only checking voice → use ring:applying-voice-and-tone
Sequence
**Runs after:** guide-writer, api-writer (agents)
Related
**Complementary:** ring:applying-voice-and-tone, ring:structuring-documentation
Review documentation systematically across multiple dimensions. A thorough review catches issues before they reach users.
Review Dimensions
1. **Voice and Tone** – Does it sound right? 2. **Structure** – Is it organized effectively? 3. **Completeness** – Is everything covered? 4. **Clarity** – Is it easy to understand? 5. **Technical Accuracy** – Is it correct?
---
Voice and Tone Review
| Check | Flag If | |-------|---------| | Second person | "Users can..." instead of "You can..." | | Present tense | "will return" instead of "returns" | | Active voice | "is returned by the API" instead of "The API returns" | | Tone | Arrogant ("Obviously...") or condescending |
---
Structure Review
| Check | Flag If | |-------|---------| | Hierarchy | Deep nesting (H4+), unclear parent-child | | Headings | Title Case instead of sentence case | | Section dividers | Missing `---` between major topics | | Navigation | Missing links to related content |
---
Completeness Review
**Conceptual docs:** Definition, characteristics, how it works, related concepts, next steps
**How-to guides:** Prerequisites, all steps, verification, troubleshooting, next steps
**API docs:** HTTP method/path, all parameters, all fields, required vs optional, examples, error codes
---
Clarity Review
| Check | Flag If | |-------|---------| | Sentence length | >25 words per sentence | | Paragraph length | >3 sentences per paragraph | | Jargon | Technical terms not explained on first use | | Examples | Abstract data ("foo", "bar") instead of realistic |
---
Technical Accuracy Review
**Conceptual:** Facts correct, behavior matches description, links work
**API docs:** Paths correct, methods correct, field names match API, types accurate, examples valid JSON
**Code examples:** Compiles/runs, output matches description, no syntax errors
---
Common Issues to Flag
| Category | Issue | Fix | |----------|-------|-----| | Voice | Third person ("Users can...") | "You can..." | | Voice | Passive ("...is returned") | "...returns" | | Voice | Future tense ("will provide") | "provides" | | Structure | Title case heading | Sentence case | | Structure | Wall of text | Add `---` dividers | | Completeness | Missing prereqs | Add prerequisites | | Completeness | No examples | Add code examples | | Clarity | Long sentences (40+ words) | Split into multiple | | Clarity | Undefined jargon | Define on first use |
---
Review Output Format
> **Note:** Documentation reviews use `PASS/NEEDS_REVISION/MAJOR_ISSUES` verdicts (graduated), which differ from code review verdicts (`PASS/FAIL/NEEDS_DISCUSSION`).
## Review Summary **Overall Assessment:** [PASS | NEEDS_REVISION | MAJOR_ISSUES] ### Issues Found #### High Priority 1. **Line 45:** Passive voice "is created by" → "creates" #### Medium Priority 1. **Line 23:** Title case in heading → sentence case #### Low Priority 1. **Line 12:** Could add example for clarity ### Recommendations 1. Fix passive voice instances (3 found) 2. Add missing API field documentation
---
Quick Review Checklist
**Voice (30s):** "You" not "users", present tense, active voice
**Structure (30s):** Sentence case headings, section dividers, scannable (bullets/tables)
**Completeness (1m):** Examples present, links work, next steps included
**Accuracy (varies):** Technical facts correct, code examples work
---
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

