docs: align overview and getting-started guides#89
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughThe documentation refresh restructures the overview, adds a beginner tutorial, revises quickstart and installation guidance, updates navigation routes, clarifies release-note status, and synchronizes documentation routing tests. ChangesDocumentation refresh
Estimated code review effort: 3 (Moderate) | ~25 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/about-nemo-fabric/overview.mdx`:
- Around line 10-15: Update the NVIDIA NeMo Fabric link in the overview
documentation to point to a verified live repository URL, or remove the
hyperlink if no valid repository exists; preserve the surrounding description
and links.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Enterprise
Run ID: fa0555fb-4947-48b8-9d3c-a3ed63767400
📒 Files selected for processing (7)
docs/about-nemo-fabric/overview.mdxdocs/about-nemo-fabric/release-notes.mdxdocs/getting-started/install.mdxdocs/getting-started/quick-start.mdxdocs/getting-started/quickstart.mdxdocs/index.ymltests/docs/test_python_api_docs.py
📜 Review details
🧰 Additional context used
📓 Path-based instructions (21)
**/*.{md,mdx,html}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Changes affecting public behavior, adapters, examples, or workspace structure must update the corresponding documentation; public API changes require updated SDK or API reference documentation.
Files:
docs/about-nemo-fabric/release-notes.mdxdocs/getting-started/install.mdxdocs/getting-started/quickstart.mdxdocs/getting-started/quick-start.mdxdocs/about-nemo-fabric/overview.mdx
**/*.{md,mdx}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
For docs site changes, run
just docsto regenerate Python and Rust API references and validate Fern configuration.
**/*.{md,mdx}: Prioritize factual accuracy in NeMo Fabric documentation and keep commands, package names, APIs, file paths, repository layout, entry points, support claims, examples, and procedures aligned with current repository behavior.
Update relevant entry-point documentation when public behavior changes, includingREADME.md,docs/index.yml, package or crate READMEs, and adapter or integration READMEs.
Use{/* ... */}delimiters for top-of-file SPDX comments in MDX files, not HTML comment delimiters.
CapitalizeNVIDIAcorrectly and use consistent current repository terminology, product names, APIs, and feature names.
Format commands, code, expressions, file names, paths, and filenames as inline code where appropriate.
Use title case for technical-documentation headings.
Introduce code blocks, tables, and lists with complete lead-in sentences.
Use descriptive link text instead of raw URLs or generic labels such ashere.
Write procedures as short, imperative, parallel, easy-to-scan steps; prefer active voice, present tense, plain English, and concise sentences.
Useafterinstead ofoncewhen expressing temporal sequence, and usecaninstead ofmaywhen describing possibility rather than permission.
Use unambiguous date formats and avoid ordinal dates in body text.
When reviewing documentation, report findings in severity order underMust fix,Should fix, andNice to have, with file paths, line references, explanations, and concrete rewrites or directions.
Files:
docs/about-nemo-fabric/release-notes.mdxdocs/getting-started/install.mdxdocs/getting-started/quickstart.mdxdocs/getting-started/quick-start.mdxdocs/about-nemo-fabric/overview.mdx
**/*
📄 CodeRabbit inference engine (CONTRIBUTING.md)
**/*: All source files must include the specified SPDX copyright and Apache-2.0 license header using the comment syntax appropriate to the file type.
Release tags must use raw Rust-compatible SemVer without a leadingv, such as0.1.0or0.1.0-rc.1.
**/*: Before implementing, explicitly state assumptions, surface ambiguity and tradeoffs, present multiple interpretations when relevant, and ask for clarification rather than silently deciding or proceeding when requirements are unclear.
Prefer the minimum code needed to solve the requested problem: avoid speculative features, unnecessary abstractions, unrequested flexibility, and handling of impossible scenarios; simplify overcomplicated solutions.
When editing existing code, make surgical changes only: do not modify unrelated code, comments, formatting, or pre-existing dead code; match the existing style, and remove only unused imports, variables, or functions introduced by your changes.
Define verifiable success criteria for each task, such as writing regression tests for bugs and invalid-input tests for validation, then verify the implementation against those criteria. For multi-step work, state a brief plan with a verification check for each step.
**/*: Keep pull request branch scope coherent and reviewable.
Run relevant tests undervalidate-changebefore opening or updating a pull request.
Format changed files with the language-native formatter.
Update documentation and examples for public behavior changes.
Update dependent maintainer or consumer guidance when code changes affect APIs, bindings, commands, paths, packaging guidance, or best practices.
Use Conventional Commit style for pull request titles:<type>: <concise imperative summary>, choosing the type from the actual change surface. Usefixonly for user-facing or runtime product-code bug fixes.
A pull request body must include#### Overview,#### Details,#### Validation,#### Where should the reviewer start?, and `#### Related ...
Files:
docs/about-nemo-fabric/release-notes.mdxdocs/getting-started/install.mdxdocs/getting-started/quickstart.mdxdocs/getting-started/quick-start.mdxdocs/index.ymldocs/about-nemo-fabric/overview.mdxtests/docs/test_python_api_docs.py
**/*.mdx
📄 CodeRabbit inference engine (CONTRIBUTING.md)
MDX files must use the specified SPDX header in a JSX comment.
In MDX files, use JSX comment delimiters (
{/*and*/}) for top-of-file comments, including SPDX headers; do not use HTML comments.
Files:
docs/about-nemo-fabric/release-notes.mdxdocs/getting-started/install.mdxdocs/getting-started/quickstart.mdxdocs/getting-started/quick-start.mdxdocs/about-nemo-fabric/overview.mdx
{README.md,docs/**/*.{md,mdx,yml},examples/**/*.{md,mdx,yml}}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Keep package names, repository references, and build commands current in documentation and examples.
Files:
docs/about-nemo-fabric/release-notes.mdxdocs/getting-started/install.mdxdocs/getting-started/quickstart.mdxdocs/getting-started/quick-start.mdxdocs/index.ymldocs/about-nemo-fabric/overview.mdx
{docs/**/*.{md,mdx,yml},examples/**/*.{md,mdx,yml}}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Update relevant getting-started, reference, adapter, and example documentation when the corresponding examples or adapters change.
Files:
docs/about-nemo-fabric/release-notes.mdxdocs/getting-started/install.mdxdocs/getting-started/quickstart.mdxdocs/getting-started/quick-start.mdxdocs/index.ymldocs/about-nemo-fabric/overview.mdx
docs/**/*.{md,mdx,yml}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Run
just docswhen the documentation site changes.
Files:
docs/about-nemo-fabric/release-notes.mdxdocs/getting-started/install.mdxdocs/getting-started/quickstart.mdxdocs/getting-started/quick-start.mdxdocs/index.ymldocs/about-nemo-fabric/overview.mdx
{docs/**/*,.github/workflows/ci_python.yml,.github/workflows/ci_rust.yml,justfile}
📄 CodeRabbit inference engine (.agents/skills/maintain-packaging/SKILL.md)
Use the current install, import, build, test, clean, and documentation commands consistently in documentation, examples, CI workflows, and just recipes.
Files:
docs/about-nemo-fabric/release-notes.mdxdocs/getting-started/install.mdxdocs/getting-started/quickstart.mdxdocs/getting-started/quick-start.mdxdocs/index.ymldocs/about-nemo-fabric/overview.mdx
{docs/**/*,.github/workflows/ci_python.yml,.github/workflows/ci_rust.yml}
📄 CodeRabbit inference engine (.agents/skills/maintain-packaging/SKILL.md)
Reflect public packaging changes in release-facing documentation and examples.
Files:
docs/about-nemo-fabric/release-notes.mdxdocs/getting-started/install.mdxdocs/getting-started/quickstart.mdxdocs/getting-started/quick-start.mdxdocs/index.ymldocs/about-nemo-fabric/overview.mdx
**/*.{md,mdx,rst}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-guide.md)
**/*.{md,mdx,rst}: For NeMo Fabric documentation, verify technical claims against the current repository, public API, or documented command before reviewing style.
Always spellNVIDIAin all caps; do not useNvidia,nvidia, orNV.
Format commands, code elements, expressions, package names, file names, and paths as inline code.
Use descriptive link text; avoid raw URLs and weak anchors such ashereorread more.
Use title case consistently for technical documentation headings.
Introduce code blocks, lists, tables, and images with complete sentences.
Write procedures as imperative, parallel steps; split long procedures into smaller tasks.
Prefer active voice, present tense, short sentences, contractions, and plain English while preserving necessary technical precision.
Usecanfor possibility and reservemayfor permission.
Useafterfor temporal relationships instead ofonce, and preferrefer tooverseewhen directing readers to another resource.
Avoid culture-specific idioms, unnecessary Latinisms, jokes, and marketing exaggeration in technical documentation.
Spell out months in body text, avoid ordinal dates, and use clear time zones.
Spell out whole numbers from zero through nine unless they are technical values, parameters, versions, or UI values; use numerals for 10 or greater and commas in thousands.
Do not add trademark symbols to learning-oriented documentation unless the source, platform, or legal guidance explicitly requires them.
Do not replace precise technical terms with simpler words when doing so would lose precision.
Do not flag passive voice when the actor is unknown or the action is the important part.
Do not rewrite API names, package names, command flags, or code literals for style.
**/*.{md,mdx,rst}: Use consistent title case for technical-document headings and table headers; avoid quotation marks, ampersands, and exclamation marks in headings, while preserving official product, event, research, and whitepaper title ...
Files:
docs/about-nemo-fabric/release-notes.mdxdocs/getting-started/install.mdxdocs/getting-started/quickstart.mdxdocs/getting-started/quick-start.mdxdocs/about-nemo-fabric/overview.mdx
docs/**/*
📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
For documentation or examples changes, run
just docswhen practical and verify documented commands against the current repository.
Files:
docs/about-nemo-fabric/release-notes.mdxdocs/getting-started/install.mdxdocs/getting-started/quickstart.mdxdocs/getting-started/quick-start.mdxdocs/index.ymldocs/about-nemo-fabric/overview.mdx
{docs/**,README.md,AGENTS.md}
⚙️ CodeRabbit configuration file
{docs/**,README.md,AGENTS.md}: Review documentation for technical accuracy against the current API, command correctness, and consistency with generated schemas.
Files:
docs/about-nemo-fabric/release-notes.mdxdocs/getting-started/install.mdxdocs/getting-started/quickstart.mdxdocs/getting-started/quick-start.mdxdocs/index.ymldocs/about-nemo-fabric/overview.mdx
**/*.{toml,yaml,yml,sh,bash}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
TOML, YAML, and shell files must use the specified SPDX header with
#comments.
Files:
docs/index.yml
**/*.{rs,py,pyi,json,yaml,yml}
📄 CodeRabbit inference engine (.agents/skills/contribute-api/SKILL.md)
Determine and update every affected public surface, including the CLI, PyO3 bindings, Python SDK, type stubs, schemas, and adapter contract, so they remain in parity.
Files:
docs/index.ymltests/docs/test_python_api_docs.py
{README.md,docs/index.yml}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Update
README.mdordocs/index.ymlwhen documentation entry points or example reading paths change.
Files:
docs/index.yml
**/*.py
📄 CodeRabbit inference engine (CONTRIBUTING.md)
**/*.py: Python public APIs must use type annotations, and native Python binding declarations must remain synchronized with their Rust implementations.
Python files must begin with the specified#SPDX copyright and Apache-2.0 license header.
Files:
tests/docs/test_python_api_docs.py
**/*.{rs,py}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
**/*.{rs,py}: Usesnake_casefor Rust and Python functions and variables; usePascalCasefor Rust types and Python classes.
Run tests for every language surface affected by a change. Changes touching the Rust core or public schemas require both Rust and Python test suites.
Public contract changes must keep native Python binding declarations synchronized with their Rust implementations.
Files:
tests/docs/test_python_api_docs.py
tests/**/*.py
📄 CodeRabbit inference engine (.agents/skills/python-tests/SKILL.md)
tests/**/*.py: Use Pytest to run Python tests.
Do not add@pytest.mark.asyncioto tests; async tests are automatically detected by the async runner.
Do not add-> Nonereturn annotations to test functions.
When mocking a class, useunittest.mock.MagicMockorAsyncMock, supplyingspecwhen necessary; do not define a new mock class.
Prefix mocked class names withmock, notfake.
Prefer pytest fixtures over helper methods.
Define shared fixtures inconftest.pyrather than repeating them across test files.
Define fixtures using@pytest.fixture(name="<fixture_name>"[, scope="<scope>"])and a<fixture_name>_fixturefunction; specifyscopeonly when it is notfunction.
Preferpytest.mark.parametrizeover separate tests for different input types.
Use@pytest.mark.usefixtureswhen a fixture is needed but its return value is unused.
Useos.environto modify environment variables in tests; do not usemonkeypatch.setenv, because the autouserestore_environ_fixtureintests/conftest.pyrestores the environment after each test.
Avoid defensive programming in tests; access expected data directly so missing data raises a clear error instead of being silently tolerated.
Run focused tests withuv run pytest -k "<pattern>"and all tests withuv run pytest.
Files:
tests/docs/test_python_api_docs.py
**/*.{py,pyi}
📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
When Python code or a Python-facing adapter changes, run
just test-python.
Files:
tests/docs/test_python_api_docs.py
**/*.{rs,py,pyi,toml}
📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
When the PyO3 bridge or package metadata changes, run
just build-pythonandcargo check -p fabric-python --locked.
Files:
tests/docs/test_python_api_docs.py
{tests/**,python/tests/**}
⚙️ CodeRabbit configuration file
{tests/**,python/tests/**}: Tests should cover the behavior promised by the changed API surface, including error paths, lifecycle cleanup, and SDK/native parity where relevant.
Files:
tests/docs/test_python_api_docs.py
🔇 Additional comments (11)
docs/about-nemo-fabric/overview.mdx (2)
22-93: LGTM!
94-135: LGTM!docs/about-nemo-fabric/release-notes.mdx (1)
8-8: LGTM!docs/getting-started/install.mdx (1)
2-2: LGTM!docs/getting-started/quick-start.mdx (3)
1-73: LGTM!
11-13: 🎯 Functional CorrectnessThe
install.mdx#source-installation-methodlink is correct.
76-99: 🎯 Functional CorrectnessThe example import and README anchor are present.
examples.code_review_agentexportsBASE_DIRandhermes_configfromexamples/code_review_agent/__init__.pyandexamples/code_review_agent/config.py, andREADME.mdcontains## Quick Start: Hermes Agentfor the link target.> Likely an incorrect or invalid review comment.docs/getting-started/quickstart.mdx (1)
2-2: LGTM!docs/index.yml (1)
13-21: LGTM!tests/docs/test_python_api_docs.py (2)
20-20: LGTM!
94-121: LGTM!
- Convert overview headings to title case and restructure the About overview to the tech-docs About template (Benefits, Use Cases, Core Workflow, Learn More) - Move the source-build Quick Start into a dedicated Getting Started page - Rename nav labels (Install -> Installation, Quickstart -> Beginner Tutorial) and add a Quickstart page; pin slugs so existing URLs are stable - Scaffold the Release Notes page from the tech-docs release-notes template Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: Linette Tang <lvojktu@nvidia.com>
Replace the concept bullets with the five-step workflow (Configure, Create variants, Plan and diagnose, Run or start a runtime, Consume evidence) with bold lead-ins. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: Linette Tang <lvojktu@nvidia.com>
- Lowercase the conjunction in the "Platform and Evaluation Harnesses" subheading for consistent title case - Restore the "Choose Your Interface" comparison table and place it above Core Workflow Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: Linette Tang <lvojktu@nvidia.com>
Introduce lead-in sentences before the bullet lists under Support Matrix and Compatibility Updates, Release Notes for Previous Versions, and Related Topics, matching the other release-notes sections. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: Linette Tang <lvojktu@nvidia.com>
- Add an introductory sentence before the Choose Your Interface table - Align the Core Workflow diagram to use "Hermes Agent" and "Codex", matching the overview intro Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: Linette Tang <lvojktu@nvidia.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: Linette Tang <lvojktu@nvidia.com>
Signed-off-by: Lawrence Lane <25370251+lbliii@users.noreply.github.com>
Signed-off-by: Lawrence Lane <25370251+lbliii@users.noreply.github.com>
8152995 to
1a37473
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/getting-started/quickstart.mdx`:
- Around line 56-103: The quickstart must install the built SDK into the project
environment and explicitly save and execute the example. Update the workflow
before the Python example to install the local wheels into .venv, add the
requested lead-in identifying quickstart.py, and add a command invoking that
file after the code block. Ensure commands use the existing repository
environment and current SDK entry point.
In `@tests/docs/test_python_api_docs.py`:
- Around line 126-127: Update the navigation assertions in test_python_api_docs
to validate each page’s complete navigation block, including its expected route
slug, rather than checking paths alone. Ensure quickstart and beginner-tutorial
are each matched with the correct slug and path so omitted or swapped public
routes fail the test.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Enterprise
Run ID: 50105cdb-3116-417f-9926-e660304bcba9
📒 Files selected for processing (4)
docs/getting-started/beginner-tutorial.mdxdocs/getting-started/quickstart.mdxdocs/index.ymltests/docs/test_python_api_docs.py
📜 Review details
🧰 Additional context used
📓 Path-based instructions (21)
**/*
📄 CodeRabbit inference engine (CONTRIBUTING.md)
**/*: All source files must include the specified SPDX copyright and Apache-2.0 license header using the comment syntax appropriate to the file type.
Release tags must use raw Rust-compatible SemVer without a leadingv, such as0.1.0or0.1.0-rc.1.
**/*: Before implementing, explicitly state assumptions, surface ambiguity and tradeoffs, present multiple interpretations when relevant, and ask for clarification rather than silently deciding or proceeding when requirements are unclear.
Prefer the minimum code needed to solve the requested problem: avoid speculative features, unnecessary abstractions, unrequested flexibility, and handling of impossible scenarios; simplify overcomplicated solutions.
When editing existing code, make surgical changes only: do not modify unrelated code, comments, formatting, or pre-existing dead code; match the existing style, and remove only unused imports, variables, or functions introduced by your changes.
Define verifiable success criteria for each task, such as writing regression tests for bugs and invalid-input tests for validation, then verify the implementation against those criteria. For multi-step work, state a brief plan with a verification check for each step.
**/*: Keep pull request branch scope coherent and reviewable.
Run relevant tests undervalidate-changebefore opening or updating a pull request.
Format changed files with the language-native formatter.
Update documentation and examples for public behavior changes.
Update dependent maintainer or consumer guidance when code changes affect APIs, bindings, commands, paths, packaging guidance, or best practices.
Use Conventional Commit style for pull request titles:<type>: <concise imperative summary>, choosing the type from the actual change surface. Usefixonly for user-facing or runtime product-code bug fixes.
A pull request body must include#### Overview,#### Details,#### Validation,#### Where should the reviewer start?, and `#### Related ...
Files:
docs/index.ymldocs/getting-started/beginner-tutorial.mdxdocs/getting-started/quickstart.mdxtests/docs/test_python_api_docs.py
**/*.{toml,yaml,yml,sh,bash}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
TOML, YAML, and shell files must use the specified SPDX header with
#comments.
Files:
docs/index.yml
**/*.{rs,py,pyi,json,yaml,yml}
📄 CodeRabbit inference engine (.agents/skills/contribute-api/SKILL.md)
Determine and update every affected public surface, including the CLI, PyO3 bindings, Python SDK, type stubs, schemas, and adapter contract, so they remain in parity.
Files:
docs/index.ymltests/docs/test_python_api_docs.py
{README.md,docs/**/*.{md,mdx,yml},examples/**/*.{md,mdx,yml}}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Keep package names, repository references, and build commands current in documentation and examples.
Files:
docs/index.ymldocs/getting-started/beginner-tutorial.mdxdocs/getting-started/quickstart.mdx
{README.md,docs/index.yml}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Update
README.mdordocs/index.ymlwhen documentation entry points or example reading paths change.
Files:
docs/index.yml
{docs/**/*.{md,mdx,yml},examples/**/*.{md,mdx,yml}}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Update relevant getting-started, reference, adapter, and example documentation when the corresponding examples or adapters change.
Files:
docs/index.ymldocs/getting-started/beginner-tutorial.mdxdocs/getting-started/quickstart.mdx
docs/**/*.{md,mdx,yml}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Run
just docswhen the documentation site changes.
Files:
docs/index.ymldocs/getting-started/beginner-tutorial.mdxdocs/getting-started/quickstart.mdx
{docs/**/*,.github/workflows/ci_python.yml,.github/workflows/ci_rust.yml,justfile}
📄 CodeRabbit inference engine (.agents/skills/maintain-packaging/SKILL.md)
Use the current install, import, build, test, clean, and documentation commands consistently in documentation, examples, CI workflows, and just recipes.
Files:
docs/index.ymldocs/getting-started/beginner-tutorial.mdxdocs/getting-started/quickstart.mdx
{docs/**/*,.github/workflows/ci_python.yml,.github/workflows/ci_rust.yml}
📄 CodeRabbit inference engine (.agents/skills/maintain-packaging/SKILL.md)
Reflect public packaging changes in release-facing documentation and examples.
Files:
docs/index.ymldocs/getting-started/beginner-tutorial.mdxdocs/getting-started/quickstart.mdx
docs/**/*
📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
For documentation or examples changes, run
just docswhen practical and verify documented commands against the current repository.
Files:
docs/index.ymldocs/getting-started/beginner-tutorial.mdxdocs/getting-started/quickstart.mdx
{docs/**,README.md,AGENTS.md}
⚙️ CodeRabbit configuration file
{docs/**,README.md,AGENTS.md}: Review documentation for technical accuracy against the current API, command correctness, and consistency with generated schemas.
Files:
docs/index.ymldocs/getting-started/beginner-tutorial.mdxdocs/getting-started/quickstart.mdx
**/*.{md,mdx,html}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Changes affecting public behavior, adapters, examples, or workspace structure must update the corresponding documentation; public API changes require updated SDK or API reference documentation.
Files:
docs/getting-started/beginner-tutorial.mdxdocs/getting-started/quickstart.mdx
**/*.{md,mdx}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
For docs site changes, run
just docsto regenerate Python and Rust API references and validate Fern configuration.
**/*.{md,mdx}: Prioritize factual accuracy in NeMo Fabric documentation and keep commands, package names, APIs, file paths, repository layout, entry points, support claims, examples, and procedures aligned with current repository behavior.
Update relevant entry-point documentation when public behavior changes, includingREADME.md,docs/index.yml, package or crate READMEs, and adapter or integration READMEs.
Use{/* ... */}delimiters for top-of-file SPDX comments in MDX files, not HTML comment delimiters.
CapitalizeNVIDIAcorrectly and use consistent current repository terminology, product names, APIs, and feature names.
Format commands, code, expressions, file names, paths, and filenames as inline code where appropriate.
Use title case for technical-documentation headings.
Introduce code blocks, tables, and lists with complete lead-in sentences.
Use descriptive link text instead of raw URLs or generic labels such ashere.
Write procedures as short, imperative, parallel, easy-to-scan steps; prefer active voice, present tense, plain English, and concise sentences.
Useafterinstead ofoncewhen expressing temporal sequence, and usecaninstead ofmaywhen describing possibility rather than permission.
Use unambiguous date formats and avoid ordinal dates in body text.
When reviewing documentation, report findings in severity order underMust fix,Should fix, andNice to have, with file paths, line references, explanations, and concrete rewrites or directions.
Files:
docs/getting-started/beginner-tutorial.mdxdocs/getting-started/quickstart.mdx
**/*.mdx
📄 CodeRabbit inference engine (CONTRIBUTING.md)
MDX files must use the specified SPDX header in a JSX comment.
In MDX files, use JSX comment delimiters (
{/*and*/}) for top-of-file comments, including SPDX headers; do not use HTML comments.
Files:
docs/getting-started/beginner-tutorial.mdxdocs/getting-started/quickstart.mdx
**/*.{md,mdx,rst}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-guide.md)
**/*.{md,mdx,rst}: For NeMo Fabric documentation, verify technical claims against the current repository, public API, or documented command before reviewing style.
Always spellNVIDIAin all caps; do not useNvidia,nvidia, orNV.
Format commands, code elements, expressions, package names, file names, and paths as inline code.
Use descriptive link text; avoid raw URLs and weak anchors such ashereorread more.
Use title case consistently for technical documentation headings.
Introduce code blocks, lists, tables, and images with complete sentences.
Write procedures as imperative, parallel steps; split long procedures into smaller tasks.
Prefer active voice, present tense, short sentences, contractions, and plain English while preserving necessary technical precision.
Usecanfor possibility and reservemayfor permission.
Useafterfor temporal relationships instead ofonce, and preferrefer tooverseewhen directing readers to another resource.
Avoid culture-specific idioms, unnecessary Latinisms, jokes, and marketing exaggeration in technical documentation.
Spell out months in body text, avoid ordinal dates, and use clear time zones.
Spell out whole numbers from zero through nine unless they are technical values, parameters, versions, or UI values; use numerals for 10 or greater and commas in thousands.
Do not add trademark symbols to learning-oriented documentation unless the source, platform, or legal guidance explicitly requires them.
Do not replace precise technical terms with simpler words when doing so would lose precision.
Do not flag passive voice when the actor is unknown or the action is the important part.
Do not rewrite API names, package names, command flags, or code literals for style.
**/*.{md,mdx,rst}: Use consistent title case for technical-document headings and table headers; avoid quotation marks, ampersands, and exclamation marks in headings, while preserving official product, event, research, and whitepaper title ...
Files:
docs/getting-started/beginner-tutorial.mdxdocs/getting-started/quickstart.mdx
**/*.py
📄 CodeRabbit inference engine (CONTRIBUTING.md)
**/*.py: Python public APIs must use type annotations, and native Python binding declarations must remain synchronized with their Rust implementations.
Python files must begin with the specified#SPDX copyright and Apache-2.0 license header.
Files:
tests/docs/test_python_api_docs.py
**/*.{rs,py}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
**/*.{rs,py}: Usesnake_casefor Rust and Python functions and variables; usePascalCasefor Rust types and Python classes.
Run tests for every language surface affected by a change. Changes touching the Rust core or public schemas require both Rust and Python test suites.
Public contract changes must keep native Python binding declarations synchronized with their Rust implementations.
Files:
tests/docs/test_python_api_docs.py
tests/**/*.py
📄 CodeRabbit inference engine (.agents/skills/python-tests/SKILL.md)
tests/**/*.py: Use Pytest to run Python tests.
Do not add@pytest.mark.asyncioto tests; async tests are automatically detected by the async runner.
Do not add-> Nonereturn annotations to test functions.
When mocking a class, useunittest.mock.MagicMockorAsyncMock, supplyingspecwhen necessary; do not define a new mock class.
Prefix mocked class names withmock, notfake.
Prefer pytest fixtures over helper methods.
Define shared fixtures inconftest.pyrather than repeating them across test files.
Define fixtures using@pytest.fixture(name="<fixture_name>"[, scope="<scope>"])and a<fixture_name>_fixturefunction; specifyscopeonly when it is notfunction.
Preferpytest.mark.parametrizeover separate tests for different input types.
Use@pytest.mark.usefixtureswhen a fixture is needed but its return value is unused.
Useos.environto modify environment variables in tests; do not usemonkeypatch.setenv, because the autouserestore_environ_fixtureintests/conftest.pyrestores the environment after each test.
Avoid defensive programming in tests; access expected data directly so missing data raises a clear error instead of being silently tolerated.
Run focused tests withuv run pytest -k "<pattern>"and all tests withuv run pytest.
Files:
tests/docs/test_python_api_docs.py
**/*.{py,pyi}
📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
When Python code or a Python-facing adapter changes, run
just test-python.
Files:
tests/docs/test_python_api_docs.py
**/*.{rs,py,pyi,toml}
📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
When the PyO3 bridge or package metadata changes, run
just build-pythonandcargo check -p fabric-python --locked.
Files:
tests/docs/test_python_api_docs.py
{tests/**,python/tests/**}
⚙️ CodeRabbit configuration file
{tests/**,python/tests/**}: Tests should cover the behavior promised by the changed API surface, including error paths, lifecycle cleanup, and SDK/native parity where relevant.
Files:
tests/docs/test_python_api_docs.py
🔇 Additional comments (4)
docs/getting-started/beginner-tutorial.mdx (1)
1-137: LGTM!docs/getting-started/quickstart.mdx (1)
2-54: LGTM!Also applies to: 108-117
docs/index.yml (1)
13-21: LGTM!tests/docs/test_python_api_docs.py (1)
20-21: LGTM!
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/getting-started/beginner-tutorial.mdx`:
- Around line 18-23: Update the list lead-in in the tutorial introduction to be
a complete sentence that clearly introduces the following tasks, while
preserving the existing three list items unchanged.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Enterprise
Run ID: 0167edea-2b8c-46fa-917e-c089abf0cac4
📒 Files selected for processing (7)
docs/about-nemo-fabric/overview.mdxdocs/about-nemo-fabric/release-notes.mdxdocs/getting-started/beginner-tutorial.mdxdocs/getting-started/install.mdxdocs/getting-started/quickstart.mdxdocs/index.ymltests/docs/test_python_api_docs.py
📜 Review details
⏰ Context from checks skipped due to timeout. (9)
- GitHub Check: Test (Python 3.14, arm64)
- GitHub Check: Test (Python 3.12, arm64)
- GitHub Check: Test (Python 3.12, x86_64)
- GitHub Check: Test (Python 3.13, arm64)
- GitHub Check: Test (Python 3.11, x86_64)
- GitHub Check: Test (Python 3.14, x86_64)
- GitHub Check: Test (Python 3.11, arm64)
- GitHub Check: Test (Python 3.13, x86_64)
- GitHub Check: Pre-commit
🧰 Additional context used
📓 Path-based instructions (21)
**/*.{md,mdx,html}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Changes affecting public behavior, adapters, examples, or workspace structure must update the corresponding documentation; public API changes require updated SDK or API reference documentation.
Files:
docs/getting-started/install.mdxdocs/about-nemo-fabric/release-notes.mdxdocs/getting-started/quickstart.mdxdocs/getting-started/beginner-tutorial.mdxdocs/about-nemo-fabric/overview.mdx
**/*.{md,mdx}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
For docs site changes, run
just docsto regenerate Python and Rust API references and validate Fern configuration.
**/*.{md,mdx}: Prioritize factual accuracy in NeMo Fabric documentation and keep commands, package names, APIs, file paths, repository layout, entry points, support claims, examples, and procedures aligned with current repository behavior.
Update relevant entry-point documentation when public behavior changes, includingREADME.md,docs/index.yml, package or crate READMEs, and adapter or integration READMEs.
Use{/* ... */}delimiters for top-of-file SPDX comments in MDX files, not HTML comment delimiters.
CapitalizeNVIDIAcorrectly and use consistent current repository terminology, product names, APIs, and feature names.
Format commands, code, expressions, file names, paths, and filenames as inline code where appropriate.
Use title case for technical-documentation headings.
Introduce code blocks, tables, and lists with complete lead-in sentences.
Use descriptive link text instead of raw URLs or generic labels such ashere.
Write procedures as short, imperative, parallel, easy-to-scan steps; prefer active voice, present tense, plain English, and concise sentences.
Useafterinstead ofoncewhen expressing temporal sequence, and usecaninstead ofmaywhen describing possibility rather than permission.
Use unambiguous date formats and avoid ordinal dates in body text.
When reviewing documentation, report findings in severity order underMust fix,Should fix, andNice to have, with file paths, line references, explanations, and concrete rewrites or directions.
Files:
docs/getting-started/install.mdxdocs/about-nemo-fabric/release-notes.mdxdocs/getting-started/quickstart.mdxdocs/getting-started/beginner-tutorial.mdxdocs/about-nemo-fabric/overview.mdx
**/*
📄 CodeRabbit inference engine (CONTRIBUTING.md)
**/*: All source files must include the specified SPDX copyright and Apache-2.0 license header using the comment syntax appropriate to the file type.
Release tags must use raw Rust-compatible SemVer without a leadingv, such as0.1.0or0.1.0-rc.1.
**/*: Before implementing, explicitly state assumptions, surface ambiguity and tradeoffs, present multiple interpretations when relevant, and ask for clarification rather than silently deciding or proceeding when requirements are unclear.
Prefer the minimum code needed to solve the requested problem: avoid speculative features, unnecessary abstractions, unrequested flexibility, and handling of impossible scenarios; simplify overcomplicated solutions.
When editing existing code, make surgical changes only: do not modify unrelated code, comments, formatting, or pre-existing dead code; match the existing style, and remove only unused imports, variables, or functions introduced by your changes.
Define verifiable success criteria for each task, such as writing regression tests for bugs and invalid-input tests for validation, then verify the implementation against those criteria. For multi-step work, state a brief plan with a verification check for each step.
**/*: Keep pull request branch scope coherent and reviewable.
Run relevant tests undervalidate-changebefore opening or updating a pull request.
Format changed files with the language-native formatter.
Update documentation and examples for public behavior changes.
Update dependent maintainer or consumer guidance when code changes affect APIs, bindings, commands, paths, packaging guidance, or best practices.
Use Conventional Commit style for pull request titles:<type>: <concise imperative summary>, choosing the type from the actual change surface. Usefixonly for user-facing or runtime product-code bug fixes.
A pull request body must include#### Overview,#### Details,#### Validation,#### Where should the reviewer start?, and `#### Related ...
Files:
docs/getting-started/install.mdxdocs/about-nemo-fabric/release-notes.mdxdocs/index.ymldocs/getting-started/quickstart.mdxdocs/getting-started/beginner-tutorial.mdxtests/docs/test_python_api_docs.pydocs/about-nemo-fabric/overview.mdx
**/*.mdx
📄 CodeRabbit inference engine (CONTRIBUTING.md)
MDX files must use the specified SPDX header in a JSX comment.
In MDX files, use JSX comment delimiters (
{/*and*/}) for top-of-file comments, including SPDX headers; do not use HTML comments.
Files:
docs/getting-started/install.mdxdocs/about-nemo-fabric/release-notes.mdxdocs/getting-started/quickstart.mdxdocs/getting-started/beginner-tutorial.mdxdocs/about-nemo-fabric/overview.mdx
{README.md,docs/**/*.{md,mdx,yml},examples/**/*.{md,mdx,yml}}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Keep package names, repository references, and build commands current in documentation and examples.
Files:
docs/getting-started/install.mdxdocs/about-nemo-fabric/release-notes.mdxdocs/index.ymldocs/getting-started/quickstart.mdxdocs/getting-started/beginner-tutorial.mdxdocs/about-nemo-fabric/overview.mdx
{docs/**/*.{md,mdx,yml},examples/**/*.{md,mdx,yml}}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Update relevant getting-started, reference, adapter, and example documentation when the corresponding examples or adapters change.
Files:
docs/getting-started/install.mdxdocs/about-nemo-fabric/release-notes.mdxdocs/index.ymldocs/getting-started/quickstart.mdxdocs/getting-started/beginner-tutorial.mdxdocs/about-nemo-fabric/overview.mdx
docs/**/*.{md,mdx,yml}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Run
just docswhen the documentation site changes.
Files:
docs/getting-started/install.mdxdocs/about-nemo-fabric/release-notes.mdxdocs/index.ymldocs/getting-started/quickstart.mdxdocs/getting-started/beginner-tutorial.mdxdocs/about-nemo-fabric/overview.mdx
{docs/**/*,.github/workflows/ci_python.yml,.github/workflows/ci_rust.yml,justfile}
📄 CodeRabbit inference engine (.agents/skills/maintain-packaging/SKILL.md)
Use the current install, import, build, test, clean, and documentation commands consistently in documentation, examples, CI workflows, and just recipes.
Files:
docs/getting-started/install.mdxdocs/about-nemo-fabric/release-notes.mdxdocs/index.ymldocs/getting-started/quickstart.mdxdocs/getting-started/beginner-tutorial.mdxdocs/about-nemo-fabric/overview.mdx
{docs/**/*,.github/workflows/ci_python.yml,.github/workflows/ci_rust.yml}
📄 CodeRabbit inference engine (.agents/skills/maintain-packaging/SKILL.md)
Reflect public packaging changes in release-facing documentation and examples.
Files:
docs/getting-started/install.mdxdocs/about-nemo-fabric/release-notes.mdxdocs/index.ymldocs/getting-started/quickstart.mdxdocs/getting-started/beginner-tutorial.mdxdocs/about-nemo-fabric/overview.mdx
**/*.{md,mdx,rst}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-guide.md)
**/*.{md,mdx,rst}: For NeMo Fabric documentation, verify technical claims against the current repository, public API, or documented command before reviewing style.
Always spellNVIDIAin all caps; do not useNvidia,nvidia, orNV.
Format commands, code elements, expressions, package names, file names, and paths as inline code.
Use descriptive link text; avoid raw URLs and weak anchors such ashereorread more.
Use title case consistently for technical documentation headings.
Introduce code blocks, lists, tables, and images with complete sentences.
Write procedures as imperative, parallel steps; split long procedures into smaller tasks.
Prefer active voice, present tense, short sentences, contractions, and plain English while preserving necessary technical precision.
Usecanfor possibility and reservemayfor permission.
Useafterfor temporal relationships instead ofonce, and preferrefer tooverseewhen directing readers to another resource.
Avoid culture-specific idioms, unnecessary Latinisms, jokes, and marketing exaggeration in technical documentation.
Spell out months in body text, avoid ordinal dates, and use clear time zones.
Spell out whole numbers from zero through nine unless they are technical values, parameters, versions, or UI values; use numerals for 10 or greater and commas in thousands.
Do not add trademark symbols to learning-oriented documentation unless the source, platform, or legal guidance explicitly requires them.
Do not replace precise technical terms with simpler words when doing so would lose precision.
Do not flag passive voice when the actor is unknown or the action is the important part.
Do not rewrite API names, package names, command flags, or code literals for style.
**/*.{md,mdx,rst}: Use consistent title case for technical-document headings and table headers; avoid quotation marks, ampersands, and exclamation marks in headings, while preserving official product, event, research, and whitepaper title ...
Files:
docs/getting-started/install.mdxdocs/about-nemo-fabric/release-notes.mdxdocs/getting-started/quickstart.mdxdocs/getting-started/beginner-tutorial.mdxdocs/about-nemo-fabric/overview.mdx
docs/**/*
📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
For documentation or examples changes, run
just docswhen practical and verify documented commands against the current repository.
Files:
docs/getting-started/install.mdxdocs/about-nemo-fabric/release-notes.mdxdocs/index.ymldocs/getting-started/quickstart.mdxdocs/getting-started/beginner-tutorial.mdxdocs/about-nemo-fabric/overview.mdx
{docs/**,README.md,AGENTS.md}
⚙️ CodeRabbit configuration file
{docs/**,README.md,AGENTS.md}: Review documentation for technical accuracy against the current API, command correctness, and consistency with generated schemas.
Files:
docs/getting-started/install.mdxdocs/about-nemo-fabric/release-notes.mdxdocs/index.ymldocs/getting-started/quickstart.mdxdocs/getting-started/beginner-tutorial.mdxdocs/about-nemo-fabric/overview.mdx
**/*.{toml,yaml,yml,sh,bash}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
TOML, YAML, and shell files must use the specified SPDX header with
#comments.
Files:
docs/index.yml
**/*.{rs,py,pyi,json,yaml,yml}
📄 CodeRabbit inference engine (.agents/skills/contribute-api/SKILL.md)
Determine and update every affected public surface, including the CLI, PyO3 bindings, Python SDK, type stubs, schemas, and adapter contract, so they remain in parity.
Files:
docs/index.ymltests/docs/test_python_api_docs.py
{README.md,docs/index.yml}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Update
README.mdordocs/index.ymlwhen documentation entry points or example reading paths change.
Files:
docs/index.yml
**/*.py
📄 CodeRabbit inference engine (CONTRIBUTING.md)
**/*.py: Python public APIs must use type annotations, and native Python binding declarations must remain synchronized with their Rust implementations.
Python files must begin with the specified#SPDX copyright and Apache-2.0 license header.
Files:
tests/docs/test_python_api_docs.py
**/*.{rs,py}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
**/*.{rs,py}: Usesnake_casefor Rust and Python functions and variables; usePascalCasefor Rust types and Python classes.
Run tests for every language surface affected by a change. Changes touching the Rust core or public schemas require both Rust and Python test suites.
Public contract changes must keep native Python binding declarations synchronized with their Rust implementations.
Files:
tests/docs/test_python_api_docs.py
tests/**/*.py
📄 CodeRabbit inference engine (.agents/skills/python-tests/SKILL.md)
tests/**/*.py: Use Pytest to run Python tests.
Do not add@pytest.mark.asyncioto tests; async tests are automatically detected by the async runner.
Do not add-> Nonereturn annotations to test functions.
When mocking a class, useunittest.mock.MagicMockorAsyncMock, supplyingspecwhen necessary; do not define a new mock class.
Prefix mocked class names withmock, notfake.
Prefer pytest fixtures over helper methods.
Define shared fixtures inconftest.pyrather than repeating them across test files.
Define fixtures using@pytest.fixture(name="<fixture_name>"[, scope="<scope>"])and a<fixture_name>_fixturefunction; specifyscopeonly when it is notfunction.
Preferpytest.mark.parametrizeover separate tests for different input types.
Use@pytest.mark.usefixtureswhen a fixture is needed but its return value is unused.
Useos.environto modify environment variables in tests; do not usemonkeypatch.setenv, because the autouserestore_environ_fixtureintests/conftest.pyrestores the environment after each test.
Avoid defensive programming in tests; access expected data directly so missing data raises a clear error instead of being silently tolerated.
Run focused tests withuv run pytest -k "<pattern>"and all tests withuv run pytest.
Files:
tests/docs/test_python_api_docs.py
**/*.{py,pyi}
📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
When Python code or a Python-facing adapter changes, run
just test-python.
Files:
tests/docs/test_python_api_docs.py
**/*.{rs,py,pyi,toml}
📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
When the PyO3 bridge or package metadata changes, run
just build-pythonandcargo check -p fabric-python --locked.
Files:
tests/docs/test_python_api_docs.py
{tests/**,python/tests/**}
⚙️ CodeRabbit configuration file
{tests/**,python/tests/**}: Tests should cover the behavior promised by the changed API surface, including error paths, lifecycle cleanup, and SDK/native parity where relevant.
Files:
tests/docs/test_python_api_docs.py
🔇 Additional comments (10)
docs/about-nemo-fabric/overview.mdx (2)
11-16: Should Fix — Correct the Repository LinkThe
NVIDIA/NeMo-Fabricrepository link remains unresolved from the prior review.
2-9: LGTM!Also applies to: 18-138
docs/getting-started/quickstart.mdx (2)
56-106: Must Fix — Install and Execute the Built SDKThe workflow still builds wheels but neither installs the SDK into
.venvnor tells readers to save and execute the example, so it cannot produce the stated completion signal.
3-54: LGTM!Also applies to: 108-117
tests/docs/test_python_api_docs.py (2)
126-127: Should Fix — Assert Each Page’s Route SlugThese assertions still validate paths independently, allowing the
quick-startandquickstartslugs to be omitted or swapped.
20-21: LGTM!Also applies to: 95-125, 128-128
docs/about-nemo-fabric/release-notes.mdx (1)
8-8: LGTM!docs/getting-started/install.mdx (1)
2-2: LGTM!docs/getting-started/beginner-tutorial.mdx (1)
1-17: LGTM!Also applies to: 26-137
docs/index.yml (1)
13-21: LGTM!
Signed-off-by: Lawrence Lane <25370251+lbliii@users.noreply.github.com>
lbliii
changed the title
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@tests/docs/test_python_api_docs.py`:
- Around line 136-145: Strengthen the navigation assertions in the relevant
Python API documentation test so each landing-page link is validated with its
correct label-to-destination pairing. Ensure the Quickstart label points to its
quickstart path/slug and Beginner Tutorial points to its beginner-tutorial
path/slug, preventing the two destinations from being swapped while still
passing.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Enterprise
Run ID: 4a088b45-980c-4c72-8ff1-005e705668b1
📒 Files selected for processing (4)
docs/about-nemo-fabric/overview.mdxdocs/getting-started/beginner-tutorial.mdxdocs/getting-started/quickstart.mdxtests/docs/test_python_api_docs.py
📜 Review details
⏰ Context from checks skipped due to timeout. (9)
- GitHub Check: Test (Python 3.13, x86_64)
- GitHub Check: Test (Python 3.14, arm64)
- GitHub Check: Test (Python 3.14, x86_64)
- GitHub Check: Test (Python 3.12, x86_64)
- GitHub Check: Test (Python 3.12, arm64)
- GitHub Check: Test (Python 3.13, arm64)
- GitHub Check: Test (Python 3.11, x86_64)
- GitHub Check: Test (Python 3.11, arm64)
- GitHub Check: Pre-commit
🧰 Additional context used
📓 Path-based instructions (19)
**/*.{md,mdx,html}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Changes affecting public behavior, adapters, examples, or workspace structure must update the corresponding documentation; public API changes require updated SDK or API reference documentation.
Files:
docs/getting-started/quickstart.mdxdocs/getting-started/beginner-tutorial.mdxdocs/about-nemo-fabric/overview.mdx
**/*.{md,mdx}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
For docs site changes, run
just docsto regenerate Python and Rust API references and validate Fern configuration.
**/*.{md,mdx}: Prioritize factual accuracy in NeMo Fabric documentation and keep commands, package names, APIs, file paths, repository layout, entry points, support claims, examples, and procedures aligned with current repository behavior.
Update relevant entry-point documentation when public behavior changes, includingREADME.md,docs/index.yml, package or crate READMEs, and adapter or integration READMEs.
Use{/* ... */}delimiters for top-of-file SPDX comments in MDX files, not HTML comment delimiters.
CapitalizeNVIDIAcorrectly and use consistent current repository terminology, product names, APIs, and feature names.
Format commands, code, expressions, file names, paths, and filenames as inline code where appropriate.
Use title case for technical-documentation headings.
Introduce code blocks, tables, and lists with complete lead-in sentences.
Use descriptive link text instead of raw URLs or generic labels such ashere.
Write procedures as short, imperative, parallel, easy-to-scan steps; prefer active voice, present tense, plain English, and concise sentences.
Useafterinstead ofoncewhen expressing temporal sequence, and usecaninstead ofmaywhen describing possibility rather than permission.
Use unambiguous date formats and avoid ordinal dates in body text.
When reviewing documentation, report findings in severity order underMust fix,Should fix, andNice to have, with file paths, line references, explanations, and concrete rewrites or directions.
Files:
docs/getting-started/quickstart.mdxdocs/getting-started/beginner-tutorial.mdxdocs/about-nemo-fabric/overview.mdx
**/*
📄 CodeRabbit inference engine (CONTRIBUTING.md)
**/*: All source files must include the specified SPDX copyright and Apache-2.0 license header using the comment syntax appropriate to the file type.
Release tags must use raw Rust-compatible SemVer without a leadingv, such as0.1.0or0.1.0-rc.1.
**/*: Before implementing, explicitly state assumptions, surface ambiguity and tradeoffs, present multiple interpretations when relevant, and ask for clarification rather than silently deciding or proceeding when requirements are unclear.
Prefer the minimum code needed to solve the requested problem: avoid speculative features, unnecessary abstractions, unrequested flexibility, and handling of impossible scenarios; simplify overcomplicated solutions.
When editing existing code, make surgical changes only: do not modify unrelated code, comments, formatting, or pre-existing dead code; match the existing style, and remove only unused imports, variables, or functions introduced by your changes.
Define verifiable success criteria for each task, such as writing regression tests for bugs and invalid-input tests for validation, then verify the implementation against those criteria. For multi-step work, state a brief plan with a verification check for each step.
**/*: Keep pull request branch scope coherent and reviewable.
Run relevant tests undervalidate-changebefore opening or updating a pull request.
Format changed files with the language-native formatter.
Update documentation and examples for public behavior changes.
Update dependent maintainer or consumer guidance when code changes affect APIs, bindings, commands, paths, packaging guidance, or best practices.
Use Conventional Commit style for pull request titles:<type>: <concise imperative summary>, choosing the type from the actual change surface. Usefixonly for user-facing or runtime product-code bug fixes.
A pull request body must include#### Overview,#### Details,#### Validation,#### Where should the reviewer start?, and `#### Related ...
Files:
docs/getting-started/quickstart.mdxdocs/getting-started/beginner-tutorial.mdxtests/docs/test_python_api_docs.pydocs/about-nemo-fabric/overview.mdx
**/*.mdx
📄 CodeRabbit inference engine (CONTRIBUTING.md)
MDX files must use the specified SPDX header in a JSX comment.
In MDX files, use JSX comment delimiters (
{/*and*/}) for top-of-file comments, including SPDX headers; do not use HTML comments.
Files:
docs/getting-started/quickstart.mdxdocs/getting-started/beginner-tutorial.mdxdocs/about-nemo-fabric/overview.mdx
{README.md,docs/**/*.{md,mdx,yml},examples/**/*.{md,mdx,yml}}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Keep package names, repository references, and build commands current in documentation and examples.
Files:
docs/getting-started/quickstart.mdxdocs/getting-started/beginner-tutorial.mdxdocs/about-nemo-fabric/overview.mdx
{docs/**/*.{md,mdx,yml},examples/**/*.{md,mdx,yml}}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Update relevant getting-started, reference, adapter, and example documentation when the corresponding examples or adapters change.
Files:
docs/getting-started/quickstart.mdxdocs/getting-started/beginner-tutorial.mdxdocs/about-nemo-fabric/overview.mdx
docs/**/*.{md,mdx,yml}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Run
just docswhen the documentation site changes.
Files:
docs/getting-started/quickstart.mdxdocs/getting-started/beginner-tutorial.mdxdocs/about-nemo-fabric/overview.mdx
{docs/**/*,.github/workflows/ci_python.yml,.github/workflows/ci_rust.yml,justfile}
📄 CodeRabbit inference engine (.agents/skills/maintain-packaging/SKILL.md)
Use the current install, import, build, test, clean, and documentation commands consistently in documentation, examples, CI workflows, and just recipes.
Files:
docs/getting-started/quickstart.mdxdocs/getting-started/beginner-tutorial.mdxdocs/about-nemo-fabric/overview.mdx
{docs/**/*,.github/workflows/ci_python.yml,.github/workflows/ci_rust.yml}
📄 CodeRabbit inference engine (.agents/skills/maintain-packaging/SKILL.md)
Reflect public packaging changes in release-facing documentation and examples.
Files:
docs/getting-started/quickstart.mdxdocs/getting-started/beginner-tutorial.mdxdocs/about-nemo-fabric/overview.mdx
**/*.{md,mdx,rst}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-guide.md)
**/*.{md,mdx,rst}: For NeMo Fabric documentation, verify technical claims against the current repository, public API, or documented command before reviewing style.
Always spellNVIDIAin all caps; do not useNvidia,nvidia, orNV.
Format commands, code elements, expressions, package names, file names, and paths as inline code.
Use descriptive link text; avoid raw URLs and weak anchors such ashereorread more.
Use title case consistently for technical documentation headings.
Introduce code blocks, lists, tables, and images with complete sentences.
Write procedures as imperative, parallel steps; split long procedures into smaller tasks.
Prefer active voice, present tense, short sentences, contractions, and plain English while preserving necessary technical precision.
Usecanfor possibility and reservemayfor permission.
Useafterfor temporal relationships instead ofonce, and preferrefer tooverseewhen directing readers to another resource.
Avoid culture-specific idioms, unnecessary Latinisms, jokes, and marketing exaggeration in technical documentation.
Spell out months in body text, avoid ordinal dates, and use clear time zones.
Spell out whole numbers from zero through nine unless they are technical values, parameters, versions, or UI values; use numerals for 10 or greater and commas in thousands.
Do not add trademark symbols to learning-oriented documentation unless the source, platform, or legal guidance explicitly requires them.
Do not replace precise technical terms with simpler words when doing so would lose precision.
Do not flag passive voice when the actor is unknown or the action is the important part.
Do not rewrite API names, package names, command flags, or code literals for style.
**/*.{md,mdx,rst}: Use consistent title case for technical-document headings and table headers; avoid quotation marks, ampersands, and exclamation marks in headings, while preserving official product, event, research, and whitepaper title ...
Files:
docs/getting-started/quickstart.mdxdocs/getting-started/beginner-tutorial.mdxdocs/about-nemo-fabric/overview.mdx
docs/**/*
📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
For documentation or examples changes, run
just docswhen practical and verify documented commands against the current repository.
Files:
docs/getting-started/quickstart.mdxdocs/getting-started/beginner-tutorial.mdxdocs/about-nemo-fabric/overview.mdx
{docs/**,README.md,AGENTS.md}
⚙️ CodeRabbit configuration file
{docs/**,README.md,AGENTS.md}: Review documentation for technical accuracy against the current API, command correctness, and consistency with generated schemas.
Files:
docs/getting-started/quickstart.mdxdocs/getting-started/beginner-tutorial.mdxdocs/about-nemo-fabric/overview.mdx
**/*.py
📄 CodeRabbit inference engine (CONTRIBUTING.md)
**/*.py: Python public APIs must use type annotations, and native Python binding declarations must remain synchronized with their Rust implementations.
Python files must begin with the specified#SPDX copyright and Apache-2.0 license header.
Files:
tests/docs/test_python_api_docs.py
**/*.{rs,py}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
**/*.{rs,py}: Usesnake_casefor Rust and Python functions and variables; usePascalCasefor Rust types and Python classes.
Run tests for every language surface affected by a change. Changes touching the Rust core or public schemas require both Rust and Python test suites.
Public contract changes must keep native Python binding declarations synchronized with their Rust implementations.
Files:
tests/docs/test_python_api_docs.py
**/*.{rs,py,pyi,json,yaml,yml}
📄 CodeRabbit inference engine (.agents/skills/contribute-api/SKILL.md)
Determine and update every affected public surface, including the CLI, PyO3 bindings, Python SDK, type stubs, schemas, and adapter contract, so they remain in parity.
Files:
tests/docs/test_python_api_docs.py
tests/**/*.py
📄 CodeRabbit inference engine (.agents/skills/python-tests/SKILL.md)
tests/**/*.py: Use Pytest to run Python tests.
Do not add@pytest.mark.asyncioto tests; async tests are automatically detected by the async runner.
Do not add-> Nonereturn annotations to test functions.
When mocking a class, useunittest.mock.MagicMockorAsyncMock, supplyingspecwhen necessary; do not define a new mock class.
Prefix mocked class names withmock, notfake.
Prefer pytest fixtures over helper methods.
Define shared fixtures inconftest.pyrather than repeating them across test files.
Define fixtures using@pytest.fixture(name="<fixture_name>"[, scope="<scope>"])and a<fixture_name>_fixturefunction; specifyscopeonly when it is notfunction.
Preferpytest.mark.parametrizeover separate tests for different input types.
Use@pytest.mark.usefixtureswhen a fixture is needed but its return value is unused.
Useos.environto modify environment variables in tests; do not usemonkeypatch.setenv, because the autouserestore_environ_fixtureintests/conftest.pyrestores the environment after each test.
Avoid defensive programming in tests; access expected data directly so missing data raises a clear error instead of being silently tolerated.
Run focused tests withuv run pytest -k "<pattern>"and all tests withuv run pytest.
Files:
tests/docs/test_python_api_docs.py
**/*.{py,pyi}
📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
When Python code or a Python-facing adapter changes, run
just test-python.
Files:
tests/docs/test_python_api_docs.py
**/*.{rs,py,pyi,toml}
📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
When the PyO3 bridge or package metadata changes, run
just build-pythonandcargo check -p fabric-python --locked.
Files:
tests/docs/test_python_api_docs.py
{tests/**,python/tests/**}
⚙️ CodeRabbit configuration file
{tests/**,python/tests/**}: Tests should cover the behavior promised by the changed API surface, including error paths, lifecycle cleanup, and SDK/native parity where relevant.
Files:
tests/docs/test_python_api_docs.py
🔇 Additional comments (3)
docs/about-nemo-fabric/overview.mdx (1)
11-15: LGTM!Also applies to: 134-137
docs/getting-started/quickstart.mdx (1)
10-12: LGTM!Also applies to: 56-57, 83-103
docs/getting-started/beginner-tutorial.mdx (1)
4-273: LGTM!
Signed-off-by: Lawrence Lane <25370251+lbliii@users.noreply.github.com>
Signed-off-by: Lawrence Lane <25370251+lbliii@users.noreply.github.com>
Signed-off-by: Lawrence Lane <25370251+lbliii@users.noreply.github.com>
Signed-off-by: Lawrence Lane <25370251+lbliii@users.noreply.github.com>
Signed-off-by: Lawrence Lane <25370251+lbliii@users.noreply.github.com>
Signed-off-by: Lawrence Lane <25370251+lbliii@users.noreply.github.com>
1 participant
Overview
Clarifies the path for new NeMo Fabric users and aligns the docs with the
NVIDIA Template Library's recommended Getting Started information architecture.
The three pages are intentionally separate:
The distinction is deliberate: the Quickstart optimizes for time to first
success, while the Beginner Tutorial optimizes for guided learning. Keeping
both prevents one page from trying to serve two different reader needs.
Details
core workflow, and learning paths.
numbered steps, an explicit success check, and card-based next steps.
examples/notebooks/01_quickstart.ipynbonboardingnotebook into a Beginner Tutorial covering typed configuration, normalized
results, one-shot and stateful runs, planning, and diagnostics.
summary, and next-step navigation. Uses Fern components to keep the tutorial
goal and learning objectives easy to scan.
Tutorial a matching filename, navigation label, and canonical URL.
This PR supersedes #85 because its source branch is no longer accessible.
Validation
npx --prefix docs --no-install fern check --warnings— 0 errors; the FDRredirect comparison was skipped because the service was unreachable.
npx --prefix docs --no-install fern docs broken-links --strictPYTHONPATH="$PWD/python/src" .venv/bin/python -m pytest tests/docs/test_python_api_docs.py -q— 4 passed.
quickstartandtutorialschema validation — both pagestructures pass manual review; the validator reports only its known Fern
frontmatter-title mismatch and optional-section notices.
doc-audit(::a) — 4 Python and 19 Bash code blocks passedsyntax validation; 36 focused SDK, runtime, example, and docs tests passed;
all changed pages reported fresh; key claims were verified against source,
tests, schemas, and package configuration.
uv run --no-sync ruff check tests/docs/test_python_api_docs.pyexecuted locally.
git diff --checkLive model-dependent examples were not run because the validation environment
does not contain an
NVIDIA_API_KEY. No runtime APIs or published URLs change.The GitHub repository is currently internal, so repository and notebook links
require NVIDIA access. They become consumer-accessible when the repository is
published. If the docs launch first, replace those links before publication.
Where should the reviewer start?
Start with
docs/getting-started/quickstart.mdxanddocs/getting-started/beginner-tutorial.mdx. The main review question iswhether the Quickstart stops at first success while the tutorial provides the
guided learning experience expected by the Template Library.
Related Issues: (use one of the action keywords Closes / Fixes / Resolves / Relates to)
Relates to docs: Edits for template alignment #85
Relates to Add onboarding notebooks for the Python SDK #68
I confirm this contribution is my own work, or I have the right to submit it under this project's license.
I searched existing issues and open pull requests, and this does not duplicate existing work.