# Review Doc Style

> Review NeMo Fabric documentation, examples, and docs-heavy changes for NVIDIA technical writing style, terminology, repository accuracy, and current public behavior. Use for documentation reviews and public-facing text changes.

- Skill: `nvidia/review-doc-style` (Agent Skill, multi-file: 9 files)
- Install (CLI): `npx skillmds@latest add nvidia/review-doc-style`
- Raw SKILL.md: https://api.skillmd.com/api/skills/nvidia/review-doc-style/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- License: Apache-2.0
- Author: NVIDIA (https://skillmd.com/u/nvidia)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/nvidia/review-doc-style

---



# Review Documentation Style

## Companion Guidance

Use `karpathy-guidelines` alongside this skill for implementation or review
work. Keep changes scoped, surface assumptions, and define focused validation
before editing.

Use this skill when reviewing docs-only changes, example-heavy changes, or any
public-facing text update that should be checked against NVIDIA style guidance
and NVIDIA NeMo Fabric repo conventions.

## Generated API Reference

- Treat all files under `docs/reference/api/` as generated output. Do not modify
  them directly.
- For Python API reference changes, update the source docstrings under
  `sdk/python/nemo-fabric-runtime/src/nemo_fabric/` or the generator in
  `scripts/generate_api_docs.sh`.
- For Rust API reference changes, update the Rust documentation comments under
  `crates/fabric-core/` or the generator in
  `scripts/docs/generate_rust_library_reference.py`.
- Run `just docs` to regenerate and validate the API reference after changing a
  source or generator.

## Documentation Links

- For links between files under `docs/`, use paths relative to the source file
  and include the target file's `.mdx` extension. These links work in both Fern
  builds and repository browsers.
- Do not use Fern site-root paths such as
  `[NeMo Fabric overview](/nemo/fabric/about-nemo-fabric/overview)`.
- Use the repository-relative equivalent, such as
  `[NeMo Fabric overview](../about-nemo-fabric/overview.mdx)`.

## Review Priorities

- Prioritize factual accuracy over copy polish
- Flag stale commands, package names, APIs, bindings, repo paths, or support claims before stylistic issues
- Keep docs aligned with current NeMo Fabric behavior, repo layout, and entry points
- Apply NVIDIA technical-writing guidance where it improves clarity and consistency without watering down technical precision
- The full product name is "NVIDIA NeMo Fabric".
  - The first usage of the name (typically in the title and H1 tag) should use the full product name.
  - All other uses of the name can use the shortened form "NeMo Fabric".
  - The only acceptable usage of "fabric" by itself is when referring to the CLI tool, and these references must be surrounded by back-ticks.

## Review Flow

1. Identify the changed docs, examples, or public-facing strings.
2. Confirm the described behavior is still true in the current repo.
3. Check whether entry-point docs also need updates:
   - `README.md`
   - `docs/index.yml`
   - Package or crate READMEs
   - Adapter and integration READMEs such as `adapters/python/codex/README.md` or `integrations/harbor/README.md`
4. Start with `assets/nvidia-style-guide.md`, then open only the focused support document needed for the issue under review.
5. Scan for high-signal style issues in headings, links, code formatting, terminology, procedures, and plain-English readability.
6. Report findings in severity order with file references and concrete rewrites.

## Must-Fix Findings

Treat these as blocking issues:

- Commands, package names, file paths, or APIs are incorrect or stale
- Public behavior changed but the corresponding entry-point docs were not updated
- A doc claims support for a binding, feature, or workflow that the repo no longer provides
- Examples or procedures are likely to fail as written
- User-facing naming is inconsistent with current repo terminology
- MDX top-of-file SPDX comments use HTML comment delimiters instead of
  `{/* ... */}`
- Links between files under `docs/` use Fern site-root paths instead of
  repository-relative `.mdx` paths
- NVIDIA is not capitalized correctly
- Code, commands, paths, or filenames are not formatted as inline code where needed

## Should-Fix Findings

Flag these when they materially improve clarity or consistency:

- Headings are not in title case for technical documentation
- Code blocks, tables, or lists are introduced with incomplete lead-in sentences
- Raw URLs or generic link text such as "here" appear in prose
- Passive voice, long sentences, or vague wording bury the action
- Terminology changes within the same document for the same concept
- Procedures are not imperative, not parallel, or too long for one sequence
- "once" is used where "after" is clearer
- "may" is used when the meaning is possibility rather than permission and "can" would be clearer

## High-Signal Review Checklist

- **Accuracy**: Commands, paths, package names, APIs, and binding claims match the current repo.
- **Entry points**: Top-level docs changed wherever users would naturally look first.
- **Headings**: Technical docs use title case consistently.
- **Voice**: Prefer active voice, present tense, short sentences, and plain English.
- **Links**: Use descriptive anchor text, not bare URLs or weak labels. For links
  within `docs/`, use repository-relative paths with the `.mdx` extension.
- **Formatting**: Commands, code elements, expressions, file names, and paths are monospace.
- **MDX headers**: Top-of-file MDX SPDX comments use `{/*` and `*/}` delimiters.
- **Procedures**: Steps are easy to scan, imperative, and split into smaller tasks when long.
- **Examples**: Code blocks are introduced by full sentences and match current APIs and build commands.
- **Terminology**: Use consistent terms throughout the document.
- **Dates and time**: Avoid ambiguous numeric dates and ordinal dates in body text.
- **Temporal references**: Prefer "after" over "once".
- **Trademarks**: For learning-oriented docs, do not force trademark symbols unless the source doc explicitly requires them.

## Output Format

When performing a docs review, lead with findings and keep them actionable:

- `Must fix`: incorrect, stale, misleading, or clearly noncompliant issues
- `Should fix`: clarity and consistency issues that materially improve the doc
- `Nice to have`: optional polish only when the review asked for thoroughness

Each finding should include:

- File path and line reference
- What is wrong now
- Why it conflicts with repo or style guidance
- A concrete rewrite or direction

If no issues are found, say so explicitly and mention any residual risk, such as commands or examples that were not executed.

## When To Open Style Support Docs

Start with the checklist above and `assets/nvidia-style-guide.md`. Open support
docs selectively instead of reading every asset for routine reviews.

| Support Doc | Open For |
|---|---|
| `assets/nvidia-style-technical-docs.md` | Headings, links, lists, tables, code examples, procedures, UI references, accessibility, and technical-document formatting. |
| `assets/nvidia-style-language-mechanics.md` | Voice, tone, plain English, active voice, contractions, temporal wording, punctuation, dates, numbers, units, and symbols. |
| `assets/nvidia-style-brand-terminology.md` | NVIDIA capitalization, product names, model names, trademarks, acronyms, titles, legal copy, SEO, and social copy. |

## References

- `README.md`
- `docs/index.yml`
- `assets/nvidia-style-guide.md`
- `assets/nvidia-style-technical-docs.md`
- `assets/nvidia-style-language-mechanics.md`
- `assets/nvidia-style-brand-terminology.md`