| name | review-doc-style |
| description | 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. |
| author | NVIDIA Corporation and Affiliates |
| license | Apache-2.0 |
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
- Identify the changed docs, examples, or public-facing strings.
- Confirm the described behavior is still true in the current repo.
- Check whether entry-point docs also need updates:
README.mddocs/index.yml- Package or crate READMEs
- Adapter and integration READMEs such as
adapters/codex/README.md or integrations/harbor/README.md
- Start with
assets/nvidia-style-guide.md, then open only the focused support document needed for the issue under review.
- Scan for high-signal style issues in headings, links, code formatting, terminology, procedures, and plain-English readability.
- 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 issuesShould fix: clarity and consistency issues that materially improve the docNice 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.mddocs/index.ymlassets/nvidia-style-guide.mdassets/nvidia-style-technical-docs.mdassets/nvidia-style-language-mechanics.mdassets/nvidia-style-brand-terminology.md
