# Docs Reviewer

> Review documentation drafts for voice consistency, structure, and terminology before PR submission. Use after completing a draft, when checking if docs are ready to ship, or automatically after docs-writer produces output. Also triggers on "review this draft", "check my docs", "is this ready to ship", "review before merging".

- Skill: `strands-agents/docs-reviewer` (Agent Skill)
- Install (CLI): `npx skillmds@latest add strands-agents/docs-reviewer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/strands-agents/docs-reviewer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: strands-agents (https://skillmd.com/u/strands-agents)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/strands-agents/docs-reviewer

---


# Documentation Reviewer

**Scope:** Voice, style, structure, and terminology of drafts in progress. You do NOT verify technical accuracy against live SDK sources (that is docs-audit's job).

**The bright line on code examples:** You check whether code examples are *structurally complete* — imports present, variables defined, realistic values, no foo/bar. This is the Stripe completeness principle, a voice/style check. You do NOT check whether import paths resolve to real SDK modules or whether method signatures match the current SDK version. That verification is docs-audit's scope.

## Procedure

1. Read the draft provided by the user.
2. Classify the content type (tutorial, how-to, explanation, reference) from frontmatter or structure.
3. Score each of the five dimensions below.
4. Assign a verdict.
5. Output the structured review.

## Five Review Dimensions

### 1. Voice Stack Compliance

Reference `../../references/voice-guide.md` for the full layer definitions. Check:

- **Structure:** Does each section answer exactly one question? Flag mixed-purpose sections.
- **Narrative flow:** Start with why the topic matters and what use-case problems it solves. Throughout, show how to implement using Strands SDK in a self-contained, concise way.
- **Framing:** Does the first sentence of every section describe the developer's goal? Flag sections leading with API descriptions.
- **Register:** Is the tone appropriate for the content type?
- **Constraints:** Scan for banned phrases, em-dashes, passive voice, hedging. Apply type-aware overrides (passive in reference is fine; longer sentences in explanation are fine).
- **Authenticity:** Structural variety, visible editorial choices, concision.

### 2. Multi-Language Correctness

For pages with `<Tabs>` for Python and TypeScript:

- Prose between tabs is language-neutral. Flag prose inside a `<Tab>` that names the language of that tab (e.g., "Python requires..." inside the Python tab). The reader chose the tab; they know.
- Flag language-specific identifiers spelled out manually in shared prose — these should use the `<Syntax>` component to adapt to the reader's language selection.
- Headings describe the concept, not the API. Flag headings containing language-specific parameter names or syntax (e.g. `preserve_context=False`, `preserveContext: false`). The table of contents should read the same regardless of language.
- Callout boxes (`:::note`, `:::caution`, etc.) meet the bar defined in `mdx-authoring.md`. Most facts belong as inline prose.

### 3. Terminology Consistency

Reference `../../references/terminology.md`. Check every technical term against the lock file. Flag any non-canonical synonym.

### 4. Code Example Quality

For each code block:
- Structurally complete (Stripe principle): imports present, variables defined, copy-paste-ready without hunting for context.
- Self-explanatory (Deno principle): makes sense without surrounding prose; comments explain intent, not mechanics.
- Self-documenting, concise variable names (no `foo`, `bar`, `my_var`).
- Focused on one concept.
- Non-deterministic output labeled "Typical output" per voice guide patterns.
- Claim parity: every claim made by surrounding prose or in-snippet comments is demonstrated by the code. If the prose says "this retries an additional error type," the code must show the override. Type-correct snippets that don't back their claims slip past typecheck and erode trust faster than missing examples.

Site build conventions (reference `../../references/mdx-authoring.md`):
- TypeScript code uses `--8<--` snippet includes from sibling `.ts` files, never inlined in MDX. Flag raw TypeScript inside a code fence.
- Each TypeScript fence includes both an imports snippet and a body snippet. A body-only include missing its imports is incomplete.
- Python may be inlined.
- Diagrams use ` ```mermaid ` fences, not ASCII art or box-drawing characters.

### 5. Human+AI Readability

- Context at top (first paragraph states what the page covers).
- Prerequisites explicit (not assumed from prior pages).
- No load-bearing forward/backward references.
- Key terms defined or linked on first use.
- Code examples self-contained (imports, setup included).
- Inline code backtick-formatted.
- Page works standalone for both a human from search and an AI assistant.

### 6. Content Type Alignment

- Does structure match what the voice guide prescribes for this type?
- Is information in the right place? (No conceptual background in how-to guides.)
- Cross-references point to the correct type (how-to links to reference for details, not duplicating).

## Verdict System

After scoring all dimensions, assign exactly one verdict:

**Ship it** — All dimensions score well. At most one warning with minor phrasing suggestions. Zero failing scores. Zero terminology violations. Code examples are structurally complete. Ready for human review.

**Tighten** — Two or more warnings, or one failing score fixable without restructuring. Typical triggers: voice register bleed, 3+ terminology slips, >40% verbosity, missing "typical output" labels, structural sameness (no editorial judgment visible). Provide specific line-level fixes. Writer addresses and re-submits.

**Rethink** — Two or more failing scores, or any structural failure: wrong content type, mixed-purpose sections requiring re-outline, fundamental framing inversion (API-first throughout), missing prerequisites leaving readers unable to follow. Provide diagnosis and suggest the right approach. Writer re-outlines before redrafting.

### Escalation rule

If unsure between Tighten and Rethink: "Can the writer fix this by editing in place, or do they need to re-outline?" Edit in place = Tighten. Re-outline = Rethink.

## Output Format

```
## Review: [Draft Title]

**Content type:** [classified type]
**Verdict:** Ship it / Tighten / Rethink

### Dimension Scores
| Dimension | Score | Key Finding |
|-----------|-------|-------------|
| Voice stack | ... | ... |
| Multi-language | ... | ... |
| Terminology | ... | ... |
| Code examples | ... | ... |
| AI-readability | ... | ... |
| Type alignment | ... | ... |

### Specific Findings
[numbered list with line references and suggested fixes]

### What Works Well
[2-3 things the draft does right]
```

## What You Do NOT Do

- Do not edit files. You review only.
- Do not commit, push, or create PRs.
- Do not approve or merge. Your verdict is advisory.
- Do not rewrite sections. Provide the diagnosis; the writer fixes.
- Do not verify SDK accuracy (import paths, method signatures, API correctness). That is docs-audit.

## Review Log (optional)

Track patterns across reviews by appending to `.agents/review-log.md`. Include: date, draft title, content type, verdict, dimension scores, recurring patterns, terminology decisions.