home / skills / lerianstudio / ring / documentation-review

documentation-review skill

/tw-team/skills/documentation-review

This skill helps you enforce high-quality documentation by auditing voice, structure, completeness, clarity, and technical accuracy across outputs.

npx playbooks add skill lerianstudio/ring --skill documentation-review

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
4.0 KB
---
name: ring:documentation-review
description: |
  Comprehensive checklist and process for reviewing documentation quality
  including voice, tone, structure, completeness, and technical accuracy.

trigger: |
  - Reviewing draft documentation
  - Pre-publication quality check
  - Documentation audit
  - Ensuring style guide compliance

skip_when: |
  - Writing new documentation → use writing-functional-docs or writing-api-docs
  - Only checking voice → use voice-and-tone

sequence:
  after: [writing-functional-docs, writing-api-docs]

related:
  complementary: [voice-and-tone, documentation-structure]
---

# Documentation Review Process

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`).

```markdown
## 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

Overview

This skill provides a comprehensive checklist and repeatable process for reviewing documentation quality across voice, structure, completeness, clarity, and technical accuracy. It enforces consistent writing standards and practical quality gates so documentation is user-friendly and reliable. The output uses a graduated verdict (PASS / NEEDS_REVISION / MAJOR_ISSUES) and a prioritized findings list to guide fixes.

How this skill works

The skill inspects documentation files and evaluates specific dimensions: voice and tone, document structure, coverage and examples, sentence and paragraph clarity, and technical correctness of API and code samples. It flags violations with line-level guidance and severity (high/medium/low), then summarizes findings and prioritized recommendations in a compact review report. Quick check timers (30s–1m) help triage common issues before deeper accuracy checks.

When to use it

  • Before merging documentation updates into main branches
  • During release cycles to validate API docs and examples
  • When onboarding new writers to enforce consistent voice and structure
  • As a pre-publication checklist for conceptual and how-to guides
  • When auditing existing docs for technical and editorial debt

Best practices

  • Prefer second-person, present tense, active voice for procedural text
  • Use sentence case for headings and add dividers between major topics
  • Include prerequisites, step-by-step verification, troubleshooting, and next steps in how-to guides
  • Document API method, path, parameters, required vs optional fields, examples, and error codes
  • Keep sentences under ~25 words and paragraphs to three sentences max; define jargon on first use

Example use cases

  • Reviewing an API reference to ensure endpoints, methods, and example JSON are accurate and runnable
  • Auditing a how-to guide to confirm prerequisites, all steps, and verification steps are present
  • Scanning conceptual docs for missing definitions, related concepts, and clear next steps
  • Finding and converting passive voice, future tense, or third-person phrasing into direct guidance
  • Spotting structural issues like deep heading nesting, missing navigation links, or walls of text

FAQ

What verdicts does the review produce?

The review returns PASS, NEEDS_REVISION, or MAJOR_ISSUES, plus a prioritized list of line-level findings.

Does the skill check code examples for correctness?

It verifies that code examples are syntactically correct and that JSON examples are valid; runtime checks depend on available execution context.