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
• For new documentation, use \n newline characters only to intentionally start a new paragraph or add space around a code block or section heading. Do not enforce a line length or reformat an entire document; apply this only to newly written text or the paragraph being edited.
• 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.

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