chore: Remove duplicate adapter extras

[dagardner-nv]

Overview

• We have two sets of redundant adapter extras, I kept the ones with the smaller names
• Removed hermes-agent dependency from the hermes extra, adding a new hermes-agent extra
• Disable verbose flag for license_diff pre-commit hook (unrelated change)
• Replaces PR chore: Remove duplicate adapter extras #94

Where should the reviewer start?

• pyproject.toml

Related Issues: (use one of the action keywords Closes / Fixes / Resolves / Relates to)

• Closes FABRIC-95

• 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.

Summary by CodeRabbit

• New Features
  • Added a dedicated hermes-agent package extra for Hermes Agent support.
  • Streamlined adapter-related extras by replacing adapters-* names with shorter groups (e.g., hermes, claude, codex, deepagents), with hermes-agent now installed via its own extra.
• Documentation
  • Updated README, contributing guide, and getting-started/skill docs to use the new extras-based installation commands.
• Tests
  • Updated Harbor integration test expectations to match the revised extras lists.
• Chores
  • Reduced output verbosity of the license-diff pre-commit hook.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Enterprise

Run ID: a85526b6-7632-4658-a4aa-5e67f6449e56

📥 Commits

Reviewing files that changed from the base of the PR and between 8cda078 and 6ed94c0.

📒 Files selected for processing (1)

• skills/nemo-fabric-integrate/SKILL.md

📜 Recent review details

⏰ Context from checks skipped due to timeout. (1)

• GitHub Check: Test (Python 3.12, macos-arm64)

🧰 Additional context used

📓 Path-based instructions (9)

**/*.{md,rst}

📄 CodeRabbit inference engine (.agents/skills/contribute-api/SKILL.md)

Update documentation and examples in the same branch as the public API change.

Files:

• skills/nemo-fabric-integrate/SKILL.md

**/*

📄 CodeRabbit inference engine (.agents/skills/karpathy-guidelines/SKILL.md)

**/*: 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.

**/*: Always spell NVIDIA in all caps; do not use Nvidia, nvidia, nVidia, nVIDIA, or NV.
Use an NVIDIA before a noun, because the name begins with an “en” sound.
Do not add a registered trademark symbol after NVIDIA when referring to the company; use trademark symbols with product names only when required by the document type or legal guidance.
Verify official capitalization, spacing, hyphenation, and spelling for NVIDIA and third-party product names; do not rewrite official product names for grammar or title-case rules.
Precede NVIDIA product names with NVIDIA on first mention when natural and accurate, and link the first mention when the destination helps the reader.
On first use, include the company name and full model qualifier when it helps identify the model; preserve official capitalization and punctuation, and use shorter family names only after establishing the full name.
For learning-oriented and developer content, do not force trademark symbols unless explicitly required; for press, ...

Files:

• skills/nemo-fabric-integrate/SKILL.md

**/*.{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 spell NVIDIA in all caps; do not use Nvidia, nvidia, or NV.
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 as here or read 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.
Use can for possibility and reserve may for permission.
Use after for temporal relationships instead of once, and prefer refer to over see when 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:

• skills/nemo-fabric-integrate/SKILL.md

**/*.{md,rst,txt,adoc}

📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-language-mechanics.md)

**/*.{md,rst,txt,adoc}: For technical documentation, use professional, active, conversational, engaging, precise, and plain-English prose. Prefer active voice, present tense, short sentences, and scannable paragraphs. Avoid casual or imprecise language, swearing, threats, insults, jokes, puns, culture-specific idioms, marketing exaggeration, and unsupported third-party comparisons.
Use can for possibility and reserve may for permission; use after for temporal order; use refer to for cross-references; prefer short direct sentences and specific verbs; avoid unnecessary please in technical documentation.
Prefer active voice when the actor matters. Passive voice is acceptable when the actor is unknown or irrelevant, when the action or result is the focus, or in programmer documentation.
Use natural contractions in conversational technical prose, but do not force them in formal legal copy, API references, or generated text.
Prefer simpler English over Latinisms: use for example or such as instead of e.g., and so on instead of etc., that is instead of i.e., compared to instead of vs., and by, through, or using instead of via. Use industry-standard terms such as in silico, in vitro, and in vivo when appropriate, and italicize them in running text.
Use that without commas for essential clauses, and which with commas for nonessential clauses.
Format dates and times clearly: spell out months in body text; use forms such as June 12, 2025; avoid numeric or ordinal dates; capitalize days; use 12-hour time when appropriate; include a space before a.m. or p.m.; use ET and PT for needed time zones; avoid 24/7; and prefer from 12:30 to 1:00 p.m. for prose ranges.
Format numbers consistently: spell out zero through nine in body text, use numerals for 10 or greater and for technical values, use commas in thousands, do not begin a sentence with a numeral, spell out ordinals, and use numerals consistently within a category wh...

Files:

• skills/nemo-fabric-integrate/SKILL.md

skills/**

📄 CodeRabbit inference engine (AGENTS.md)

skills/**: Keep consumer skills under skills/ self-contained and dependent only on supported public Python SDK contracts and published documentation; do not add repository-internal contribution guidance.
Keep consumer skills in parity with the public SDK guide, model, and type details when the Python/Rust binding contract changes.

Files:

• skills/nemo-fabric-integrate/SKILL.md

**/*.{md,mdx}

📄 CodeRabbit inference engine (.agents/skills/review-doc-style/SKILL.md)

**/*.{md,mdx}: Use the full product name NVIDIA NeMo Fabric on its first usage, typically in the title or H1; use NeMo Fabric thereafter.
Use fabric by itself only when referring to the CLI tool, and surround those references with backticks.
Capitalize NVIDIA correctly in public documentation.
Format commands, code elements, expressions, file names, paths, and filenames as inline code where needed.
Use title case consistently for headings in technical documentation.
Introduce code blocks, tables, and lists with complete lead-in sentences.
Use descriptive anchor text instead of raw URLs or generic link text such as here.
Prefer active voice, present tense, short sentences, and plain English.
Use consistent terminology for the same concept throughout a document.
Write procedures as imperative, parallel, easy-to-scan steps, and split long sequences into smaller tasks.
Use after instead of once when expressing temporal sequence.
Use can instead of may when the intended meaning is possibility rather than permission.
Avoid ambiguous numeric dates and ordinal dates in body text.
For learning-oriented documentation, do not force trademark symbols unless the source document explicitly requires them.
Introduce examples' code blocks with full sentences and ensure examples match current APIs and build commands.

**/*.{md,mdx}: Update documentation when changes affect public behavior, adapters, examples, or workspace structure; keep README files, SDK/API references, adapter/example documentation, and embedded examples aligned with current behavior.
For documentation site changes, run just docs to regenerate Python and Rust API references and validate the Fern configuration.

Files:

• skills/nemo-fabric-integrate/SKILL.md

**/*.md

📄 CodeRabbit inference engine (CONTRIBUTING.md)

HTML-style SPDX comment headers must be used in Markdown files.

Files:

• skills/nemo-fabric-integrate/SKILL.md

{*.md,**/*.md,**/*.mdx,**/*.ipynb}

⚙️ CodeRabbit configuration file

{*.md,**/*.md,**/*.mdx,**/*.ipynb}: Enforce the product name in user-facing prose: use "NVIDIA NeMo Fabric" on first use and "NeMo Fabric" thereafter. Flag standalone capitalized "Fabric" when it refers to the product. Do not flag the lowercase fabric CLI command, package/import/crate names, code identifiers, API symbols, configuration keys, file paths, or unrelated generic uses of the word.

Files:

• skills/nemo-fabric-integrate/SKILL.md

**/SKILL.md

⚙️ CodeRabbit configuration file

**/SKILL.md: Do not flag SKILL.md files for missing SPDX headers. Skill entrypoints intentionally start with YAML frontmatter instead.
Verify that every SKILL.md keeps valid YAML frontmatter with at least name and description fields before the Markdown body.

Files:

• skills/nemo-fabric-integrate/SKILL.md

🧠 Learnings (1)

📓 Common learnings

Learnt from: CR
Repo: NVIDIA/NeMo-Fabric

Timestamp: 2026-07-22T17:16:39.018Z
Learning: All contributors must sign off every commit using `git commit -s`; unsigned commits are not accepted.

Learnt from: CR
Repo: NVIDIA/NeMo-Fabric

Timestamp: 2026-07-22T17:16:39.018Z
Learning: Before submitting a pull request, identify an issue, run relevant tests, verify affected packages compile, update documentation, and rebase onto the latest `main`.

Learnt from: CR
Repo: NVIDIA/NeMo-Fabric

Timestamp: 2026-07-22T17:16:39.018Z
Learning: Pull requests require at least one approving review, must address review feedback without force-pushing during review, and CI must pass before merging.

Learnt from: CR
Repo: NVIDIA/NeMo-Fabric

Timestamp: 2026-07-22T17:16:39.018Z
Learning: Use commit messages formatted as `type: short description`, with a valid type, a first line shorter than 72 characters, and optional explanatory body text.

🔇 Additional comments (1)

skills/nemo-fabric-integrate/SKILL.md (1)

53-55: Include the separate hermes-agent extra.

This command still installs only nemo-fabric[hermes], so the documented Hermes setup is incomplete after hermes-agent was split into its own extra. Update it to install both extras, consistent with tests/integrations/test_harbor_runner.py.

---

Walkthrough

The PR renames adapter dependency extras, adds a separate hermes-agent extra, updates installation references across documentation and Harbor examples, adjusts an integration assertion, and disables verbose output for the local license-diff hook.

Changes

Hermes extras migration

Layer / File(s)	Summary
Optional dependency extras pyproject.toml	Adapter extras use shorter names, while hermes-agent separately installs the Hermes adapter and hermes-agent package.
Installation and Harbor wiring CONTRIBUTING.md, README.md, adapters/hermes/README.md, docs/getting-started/quickstart.mdx, examples/harbor/...	Installation commands and Harbor package specifications use the renamed extras and include hermes-agent where required.
Documentation and integration validation docs/getting-started/install.mdx, skills/nemo-fabric-integrate/SKILL.md, tests/integrations/test_harbor_runner.py	Adapter documentation lists the new extras, and the Harbor test expects the expanded extras specification.

Hook output configuration

Layer / File(s)	Summary
License-diff verbosity .pre-commit-config.yaml	The local license-diff hook changes verbose from true to false.

Estimated code review effort: 2 (Simple) | ~15 minutes

Possibly related PRs

• NVIDIA/NeMo-Fabric#94: Makes the same Hermes extras restructuring and updates corresponding documentation, Harbor wiring, tests, and hook configuration.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title uses Conventional Commits and accurately summarizes the main change.
Description check	✅ Passed	The description follows the template and includes overview, reviewer start, issue reference, and confirmations.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

Fern docs preview: https://nvidia-preview-pull-request-98.docs.buildwithfern.com/nemo/fabric

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

docs/getting-started/quickstart.mdx (1)

12-16: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Document the Hermes Python-version requirement in every direct installation path.

pyproject.toml gates both the Hermes adapter and hermes-agent dependency with python_version < '3.14'. On Python 3.14, these commands can succeed while installing no Hermes components.

• docs/getting-started/quickstart.mdx#L12-L16: require Python 3.11–3.13 or create the environment with a compatible interpreter.
• adapters/hermes/README.md#L12-L27: add the Python 3.11–3.13 prerequisite before the installation choices.
• CONTRIBUTING.md#L26-L30: qualify the Hermes adapter installation example with the same supported range.

🤖 Prompt for 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.

In `@docs/getting-started/quickstart.mdx` around lines 12 - 16, Document the
Hermes Python requirement across all direct installation paths: in
docs/getting-started/quickstart.mdx lines 12-16, require Python 3.11–3.13 or
create the virtual environment with a compatible interpreter; in
adapters/hermes/README.md lines 12-27, add the same prerequisite before
installation options; and in CONTRIBUTING.md lines 26-30, qualify the Hermes
adapter installation example with the supported Python range.

🤖 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.

Outside diff comments:
In `@docs/getting-started/quickstart.mdx`:
- Around line 12-16: Document the Hermes Python requirement across all direct
installation paths: in docs/getting-started/quickstart.mdx lines 12-16, require
Python 3.11–3.13 or create the virtual environment with a compatible
interpreter; in adapters/hermes/README.md lines 12-27, add the same prerequisite
before installation options; and in CONTRIBUTING.md lines 26-30, qualify the
Hermes adapter installation example with the supported Python range.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Enterprise

Run ID: 4925f0a1-f7f4-4e16-8b11-0a6f641f1492

📥 Commits

Reviewing files that changed from the base of the PR and between eeeb807 and 71c3810.

⛔ Files ignored due to path filters (1)

• uv.lock is excluded by !**/*.lock

📒 Files selected for processing (11)

• .pre-commit-config.yaml
• CONTRIBUTING.md
• README.md
• adapters/hermes/README.md
• docs/getting-started/install.mdx
• docs/getting-started/quickstart.mdx
• examples/harbor/calculator/task/environment/Dockerfile
• examples/harbor/prepare_swebench.sh
• pyproject.toml
• skills/nemo-fabric-integrate/SKILL.md
• tests/integrations/test_harbor_runner.py

📜 Review details

⏰ Context from checks skipped due to timeout. (3)

• GitHub Check: Pre-commit
• GitHub Check: Test (Python 3.14, macos-arm64)
• GitHub Check: Test (Python 3.11, macos-arm64)

🧰 Additional context used

📓 Path-based instructions (39)

.pre-commit-config.yaml

📄 CodeRabbit inference engine (.agents/skills/maintain-packaging/SKILL.md)

Regenerate Rust and Python attribution files with the attributions-rust and attributions-python pre-commit hooks rather than editing generated output manually.

Files:

• .pre-commit-config.yaml

**/*

📄 CodeRabbit inference engine (.agents/skills/karpathy-guidelines/SKILL.md)

**/*: 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.

**/*: Always spell NVIDIA in all caps; do not use Nvidia, nvidia, nVidia, nVIDIA, or NV.
Use an NVIDIA before a noun, because the name begins with an “en” sound.
Do not add a registered trademark symbol after NVIDIA when referring to the company; use trademark symbols with product names only when required by the document type or legal guidance.
Verify official capitalization, spacing, hyphenation, and spelling for NVIDIA and third-party product names; do not rewrite official product names for grammar or title-case rules.
Precede NVIDIA product names with NVIDIA on first mention when natural and accurate, and link the first mention when the destination helps the reader.
On first use, include the company name and full model qualifier when it helps identify the model; preserve official capitalization and punctuation, and use shorter family names only after establishing the full name.
For learning-oriented and developer content, do not force trademark symbols unless explicitly required; for press, ...

Files:

• examples/harbor/prepare_swebench.sh
• docs/getting-started/quickstart.mdx
• README.md
• CONTRIBUTING.md
• docs/getting-started/install.mdx
• adapters/hermes/README.md
• tests/integrations/test_harbor_runner.py
• skills/nemo-fabric-integrate/SKILL.md
• examples/harbor/calculator/task/environment/Dockerfile
• pyproject.toml

**/*.{rs,py,html,md,mdx,toml,yml,yaml,sh}

📄 CodeRabbit inference engine (CONTRIBUTING.md)

Include the required SPDX copyright and Apache-2.0 license headers, using the comment syntax appropriate for each file type.

Files:

• examples/harbor/prepare_swebench.sh
• docs/getting-started/quickstart.mdx
• README.md
• CONTRIBUTING.md
• docs/getting-started/install.mdx
• adapters/hermes/README.md
• tests/integrations/test_harbor_runner.py
• skills/nemo-fabric-integrate/SKILL.md
• pyproject.toml

{adapters/**,examples/**}

⚙️ CodeRabbit configuration file

{adapters/**,examples/**}: Review adapter and example changes for command correctness, config/schema consistency, artifact handling, and compatibility with the public NeMo Fabric contracts.

Files:

• examples/harbor/prepare_swebench.sh
• adapters/hermes/README.md
• examples/harbor/calculator/task/environment/Dockerfile

{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.mdx
• README.md
• docs/getting-started/install.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.mdx
• docs/getting-started/install.mdx

**/*.mdx

📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)

In MDX files, use JSX comment delimiters ({/* and */}) for top-of-file comments, including SPDX headers; do not use HTML comments.

Use {/* ... */} delimiters for top-of-file MDX SPDX comments, not HTML comment delimiters.

Files:

• docs/getting-started/quickstart.mdx
• docs/getting-started/install.mdx

docs/**/*.{md,mdx,yml}

📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)

Run just docs when the documentation site changes.

Files:

• docs/getting-started/quickstart.mdx
• docs/getting-started/install.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 spell NVIDIA in all caps; do not use Nvidia, nvidia, or NV.
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 as here or read 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.
Use can for possibility and reserve may for permission.
Use after for temporal relationships instead of once, and prefer refer to over see when 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.mdx
• README.md
• CONTRIBUTING.md
• docs/getting-started/install.mdx
• adapters/hermes/README.md
• skills/nemo-fabric-integrate/SKILL.md

docs/**/*

📄 CodeRabbit inference engine (AGENTS.md)

Update Fern documentation under docs/ when public behavior, the nemo-fabric package, examples, or supported bindings change.

Files:

• docs/getting-started/quickstart.mdx
• docs/getting-started/install.mdx

**/*.{md,mdx}

📄 CodeRabbit inference engine (.agents/skills/review-doc-style/SKILL.md)

**/*.{md,mdx}: Use the full product name NVIDIA NeMo Fabric on its first usage, typically in the title or H1; use NeMo Fabric thereafter.
Use fabric by itself only when referring to the CLI tool, and surround those references with backticks.
Capitalize NVIDIA correctly in public documentation.
Format commands, code elements, expressions, file names, paths, and filenames as inline code where needed.
Use title case consistently for headings in technical documentation.
Introduce code blocks, tables, and lists with complete lead-in sentences.
Use descriptive anchor text instead of raw URLs or generic link text such as here.
Prefer active voice, present tense, short sentences, and plain English.
Use consistent terminology for the same concept throughout a document.
Write procedures as imperative, parallel, easy-to-scan steps, and split long sequences into smaller tasks.
Use after instead of once when expressing temporal sequence.
Use can instead of may when the intended meaning is possibility rather than permission.
Avoid ambiguous numeric dates and ordinal dates in body text.
For learning-oriented documentation, do not force trademark symbols unless the source document explicitly requires them.
Introduce examples' code blocks with full sentences and ensure examples match current APIs and build commands.

Update corresponding documentation when public behavior, adapters, examples, or workspace structure changes.

Files:

• docs/getting-started/quickstart.mdx
• README.md
• CONTRIBUTING.md
• docs/getting-started/install.mdx
• adapters/hermes/README.md
• skills/nemo-fabric-integrate/SKILL.md

{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.mdx
• README.md
• docs/getting-started/install.mdx

{*.md,**/*.md,**/*.mdx,**/*.ipynb}

⚙️ CodeRabbit configuration file

{*.md,**/*.md,**/*.mdx,**/*.ipynb}: Enforce the product name in user-facing prose: use "NVIDIA NeMo Fabric" on first use and "NeMo Fabric" thereafter. Flag standalone capitalized "Fabric" when it refers to the product. Do not flag the lowercase fabric CLI command, package/import/crate names, code identifiers, API symbols, configuration keys, file paths, or unrelated generic uses of the word.

Files:

• docs/getting-started/quickstart.mdx
• README.md
• CONTRIBUTING.md
• docs/getting-started/install.mdx
• adapters/hermes/README.md
• skills/nemo-fabric-integrate/SKILL.md

**/*.{md,rst}

📄 CodeRabbit inference engine (.agents/skills/contribute-api/SKILL.md)

Update documentation and examples in the same branch as the public API change.

Files:

• README.md
• CONTRIBUTING.md
• adapters/hermes/README.md
• skills/nemo-fabric-integrate/SKILL.md

{README.md,docs/index.yml}

📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)

Update README.md or docs/index.yml when documentation entry points or example reading paths change.

Files:

• README.md

**/*.{md,rst,txt,adoc}

📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-language-mechanics.md)

**/*.{md,rst,txt,adoc}: For technical documentation, use professional, active, conversational, engaging, precise, and plain-English prose. Prefer active voice, present tense, short sentences, and scannable paragraphs. Avoid casual or imprecise language, swearing, threats, insults, jokes, puns, culture-specific idioms, marketing exaggeration, and unsupported third-party comparisons.
Use can for possibility and reserve may for permission; use after for temporal order; use refer to for cross-references; prefer short direct sentences and specific verbs; avoid unnecessary please in technical documentation.
Prefer active voice when the actor matters. Passive voice is acceptable when the actor is unknown or irrelevant, when the action or result is the focus, or in programmer documentation.
Use natural contractions in conversational technical prose, but do not force them in formal legal copy, API references, or generated text.
Prefer simpler English over Latinisms: use for example or such as instead of e.g., and so on instead of etc., that is instead of i.e., compared to instead of vs., and by, through, or using instead of via. Use industry-standard terms such as in silico, in vitro, and in vivo when appropriate, and italicize them in running text.
Use that without commas for essential clauses, and which with commas for nonessential clauses.
Format dates and times clearly: spell out months in body text; use forms such as June 12, 2025; avoid numeric or ordinal dates; capitalize days; use 12-hour time when appropriate; include a space before a.m. or p.m.; use ET and PT for needed time zones; avoid 24/7; and prefer from 12:30 to 1:00 p.m. for prose ranges.
Format numbers consistently: spell out zero through nine in body text, use numerals for 10 or greater and for technical values, use commas in thousands, do not begin a sentence with a numeral, spell out ordinals, and use numerals consistently within a category wh...

Files:

• README.md
• CONTRIBUTING.md
• adapters/hermes/README.md
• skills/nemo-fabric-integrate/SKILL.md

README.md

📄 CodeRabbit inference engine (.agents/skills/small-fix/SKILL.md)

Update README.md when a small Fabric bug fix changes public behavior.

Update the root README.md when public behavior, the nemo-fabric package, examples, or supported bindings change.

Update the top-level README.md when changed behavior affects an entry point users would naturally consult.

Files:

• README.md

**/README.md

📄 CodeRabbit inference engine (.agents/skills/review-doc-style/SKILL.md)

Update relevant package, crate, adapter, and integration README files when public behavior or entry-point documentation changes.

Files:

• README.md
• adapters/hermes/README.md

adapters/*/README.md

📄 CodeRabbit inference engine (AGENTS.md)

Update adapter README files when public behavior, examples, or supported bindings change.

Files:

• adapters/hermes/README.md

**/*.{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/integrations/test_harbor_runner.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.asyncio to tests; async tests are automatically detected by the async runner.
Do not add -> None return annotations to test functions.
When mocking a class, use unittest.mock.MagicMock or AsyncMock, supplying spec when necessary; do not define a new mock class.
Prefix mocked class names with mock, not fake.
Prefer pytest fixtures over helper methods.
Define shared fixtures in conftest.py rather than repeating them across test files.
Define fixtures using @pytest.fixture(name="<fixture_name>"[, scope="<scope>"]) and a <fixture_name>_fixture function; specify scope only when it is not function.
Prefer pytest.mark.parametrize over separate tests for different input types.
Use @pytest.mark.usefixtures when a fixture is needed but its return value is unused.
Use os.environ to modify environment variables in tests; do not use monkeypatch.setenv, because the autouse restore_environ_fixture in tests/conftest.py restores 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 with uv run pytest -k "<pattern>" and all tests with uv run pytest.

Files:

• tests/integrations/test_harbor_runner.py

**/*.{rs,py}

📄 CodeRabbit inference engine (.agents/skills/prepare-pr/SKILL.md)

For native binding changes, run cargo check -p fabric-python --locked.

**/*.{rs,py}: When changing version-helper code, set_project_version must invoke both Cargo and Python project version helpers.
When changing version-helper code, set_cargo_workspace_version must update the workspace version and nemo-fabric-core workspace dependency, then verify every nemo-fabric-* workspace package through Cargo metadata.
When changing version-helper code, set_python_project_versions must update the root setuptools version, recursively discovered adapter pyproject.toml versions, and all internal exact-version pins while rejecting a static version in python/pyproject.toml.

**/*.{rs,py}: Use language-appropriate naming conventions: Rust and Python functions and variables use snake_case; Rust types and Python classes use PascalCase.
Keep native Python binding declarations synchronized with their Rust implementations.
Run tests for every affected language surface; changes to the Rust core or public schemas require running both Rust and Python test suites.
When adding functionality, include tests in the corresponding Rust crate or relevant area under tests/.

Files:

• tests/integrations/test_harbor_runner.py

**/*.{py,pyi}

📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)

If Python code or a Python-facing adapter changes, run just test-python.

Files:

• tests/integrations/test_harbor_runner.py

**/*.{rs,py,pyi}

📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)

**/*.{rs,py,pyi}: If public configuration types change, confirm schema snapshot tests in just test-rust pass and review generated schema diffs.
For schema or public contract changes, run both language suites and review changes under schemas/ and generated API references.

Files:

• tests/integrations/test_harbor_runner.py

**/*.{py,pyi,rs}

📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)

For Python SDK or PyO3 binding changes, use python-tests, run focused pytest tests first, then just test-python; rebuild with just build-python when native code or packaging changes.

Files:

• tests/integrations/test_harbor_runner.py

**/*.py

📄 CodeRabbit inference engine (CONTRIBUTING.md)

Use type annotations for public Python APIs.

Files:

• tests/integrations/test_harbor_runner.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/integrations/test_harbor_runner.py

skills/**

📄 CodeRabbit inference engine (AGENTS.md)

skills/**: Keep consumer skills under skills/ self-contained and dependent only on supported public Python SDK contracts and published documentation; do not add repository-internal contribution guidance.
Keep consumer skills in parity with the public SDK guide, model, and type details when the Python/Rust binding contract changes.

Files:

• skills/nemo-fabric-integrate/SKILL.md

**/SKILL.md

⚙️ CodeRabbit configuration file

**/SKILL.md: Do not flag SKILL.md files for missing SPDX headers. Skill entrypoints intentionally start with YAML frontmatter instead.
Verify that every SKILL.md keeps valid YAML frontmatter with at least name and description fields before the Markdown body.

Files:

• skills/nemo-fabric-integrate/SKILL.md

{Cargo.toml,python/pyproject.toml,pyproject.toml}

📄 CodeRabbit inference engine (.agents/skills/maintain-packaging/SKILL.md)

Keep Rust workspace/package metadata and Python/maturin package metadata internally consistent, including package names, versions, import paths, and module names.

Files:

• pyproject.toml

{Cargo.toml,Cargo.lock,pyproject.toml,uv.lock,python/pyproject.toml}

📄 CodeRabbit inference engine (.agents/skills/maintain-packaging/SKILL.md)

{Cargo.toml,Cargo.lock,pyproject.toml,uv.lock,python/pyproject.toml}: Keep workspace, Python, and lockfile dependency versions aligned where required, and review both direct and transitive dependency changes from resolved lockfiles.
Inspect resolved transitive licenses, explicitly surface UNKNOWN, non-SPDX/custom, proprietary, source-available, copyleft, or network-copyleft terms, and route unresolved licensing questions to dependency approvers with distribution and linkage context.
Document the functional need, alternatives considered, rationale for the selected dependency, and any unresolved licensing question when introducing dependencies.

Files:

• pyproject.toml

{Cargo.toml,pyproject.toml,python/pyproject.toml}

📄 CodeRabbit inference engine (.agents/skills/maintain-packaging/SKILL.md)

Before adding a dependency, prefer the standard library, an existing dependency, or a small local implementation when appropriate; otherwise select a maintained, narrow-fit dependency with clear SPDX metadata and a permissive license where possible.

Files:

• pyproject.toml

{Cargo.toml,Cargo.lock,pyproject.toml,uv.lock}

📄 CodeRabbit inference engine (.agents/skills/maintain-packaging/SKILL.md)

After updating manifests or lockfiles, run uv run --no-project python scripts/licensing/license_diff.py --base-ref origin/main and review added packages and license changes.

Files:

• pyproject.toml

{pyproject.toml,python/pyproject.toml,Cargo.toml,docs/package.json,.github/workflows/*.yml,justfile}

📄 CodeRabbit inference engine (.agents/skills/maintain-packaging/SKILL.md)

Reflect public packaging changes in release-facing documentation and ensure CI references the same package names and commands used by local workflows.

Files:

• pyproject.toml

**/*.{rs,toml}

📄 CodeRabbit inference engine (.agents/skills/prepare-pr/SKILL.md)

For any Rust change, run just test-rust and cargo fmt --all -- --check.

For Rust core, CLI, or shared runtime semantic changes, run Rust formatting and tests, and add Python tests when behavior is exposed through the SDK.

Files:

• pyproject.toml

**/{Cargo.toml,Cargo.lock,pyproject.toml,package.json}

📄 CodeRabbit inference engine (.agents/skills/prepare-pr/SKILL.md)

For new or updated dependencies, document the functional need, alternatives considered, and why the selected dependency is the narrowest fit.

Files:

• pyproject.toml

{pyproject.toml,adapters/**/pyproject.toml}

📄 CodeRabbit inference engine (.agents/skills/update-project-version/SKILL.md)

{pyproject.toml,adapters/**/pyproject.toml}: Update the literal project.version in the root setuptools project and every adapter pyproject.toml.
Keep internal exact-version pins aligned: root optional dependencies must use the release version for every nemo-fabric-* requirement, and adapters must pin nemo-fabric-adapters-common to that version.

Files:

• pyproject.toml

**/*.{toml,lock}

📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)

If a manifest or lockfile changes, run the license-diff script against origin/main, review transitive license changes, and run the attributions-rust and attributions-python pre-commit hooks.

Files:

• pyproject.toml

**/*.{yml,yaml,toml,lock}

📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)

For CI or packaging changes, use maintain-ci or maintain-packaging, then run recipes and checks whose behavior changed.

Files:

• pyproject.toml

🧠 Learnings (1)

📓 Common learnings

Learnt from: CR
Repo: NVIDIA/NeMo-Fabric

Timestamp: 2026-07-22T16:56:08.682Z
Learning: All contributors must sign off their commits using `git commit -s`; unsigned commits are not accepted.

Learnt from: CR
Repo: NVIDIA/NeMo-Fabric

Timestamp: 2026-07-22T16:56:08.682Z
Learning: Pull requests must have at least one approving review, pass CI, include relevant testing information, and address required documentation and issue references.

Learnt from: CR
Repo: NVIDIA/NeMo-Fabric

Timestamp: 2026-07-22T16:56:08.682Z
Learning: Use commit messages in the format `type: short description`, with an allowed type and a first line under 72 characters.

🔇 Additional comments (8)

.pre-commit-config.yaml (1)

69-69: LGTM!

pyproject.toml (1)

38-63: LGTM!

README.md (1)

109-114: LGTM!

examples/harbor/calculator/task/environment/Dockerfile (1)

17-22: LGTM!

examples/harbor/prepare_swebench.sh (1)

66-68: LGTM!

docs/getting-started/install.mdx (1)

37-51: LGTM!

tests/integrations/test_harbor_runner.py (1)

252-255: LGTM!

skills/nemo-fabric-integrate/SKILL.md (1)

53-58: 📐 Maintainability & Code Quality

No frontmatter change needed skills/nemo-fabric-integrate/SKILL.md already has valid YAML frontmatter with both name and description.

			> Likely an incorrect or invalid review comment.

[lbliii]

The adapter-extra rename is reflected consistently, but the new Hermes dependency split is not yet fully documented in the canonical install surface or the exported consumer skill. These are must-fix documentation-parity issues because following either surface can leave a consumer without the Hermes Agent harness. I left concrete inline directions for distinguishing the adapter-only install from a runnable Hermes setup.

Correcting this review after re-auditing the comments against the repository documentation rules. The two blocking suggestions were not supported by the documented adapter-installation scope and have been removed.

[lbliii]

One nonblocking documentation style suggestion remains after re-auditing the changed text against the repository rules of the road.

[lbliii]

One nonblocking wording suggestion, re-anchored after the latest update.

[coderabbitai]

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 `@skills/nemo-fabric-integrate/SKILL.md`:
- Around line 51-55: Update the harness adapter installation instructions in
SKILL.md so the Hermes example installs both the hermes and hermes-agent extras,
or explicitly documents a second hermes-agent installation. Keep the listed
adapter extras and binary/dependency guidance consistent with the package
metadata and the expectations in test_harbor_runner.py.

🪄 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: f83a4b32-dd74-4fa0-996f-8d54eb48403e

📥 Commits

Reviewing files that changed from the base of the PR and between 71c3810 and 8cda078.

📒 Files selected for processing (1)

• skills/nemo-fabric-integrate/SKILL.md

📜 Review details

⏰ Context from checks skipped due to timeout. (2)

• GitHub Check: Test (Python 3.12, macos-arm64)
• GitHub Check: Pre-commit

🧰 Additional context used

📓 Path-based instructions (9)

**/*.{md,rst}

📄 CodeRabbit inference engine (.agents/skills/contribute-api/SKILL.md)

Update documentation and examples in the same branch as the public API change.

Files:

• skills/nemo-fabric-integrate/SKILL.md

**/*

📄 CodeRabbit inference engine (.agents/skills/karpathy-guidelines/SKILL.md)

**/*: 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.

**/*: Always spell NVIDIA in all caps; do not use Nvidia, nvidia, nVidia, nVIDIA, or NV.
Use an NVIDIA before a noun, because the name begins with an “en” sound.
Do not add a registered trademark symbol after NVIDIA when referring to the company; use trademark symbols with product names only when required by the document type or legal guidance.
Verify official capitalization, spacing, hyphenation, and spelling for NVIDIA and third-party product names; do not rewrite official product names for grammar or title-case rules.
Precede NVIDIA product names with NVIDIA on first mention when natural and accurate, and link the first mention when the destination helps the reader.
On first use, include the company name and full model qualifier when it helps identify the model; preserve official capitalization and punctuation, and use shorter family names only after establishing the full name.
For learning-oriented and developer content, do not force trademark symbols unless explicitly required; for press, ...

Files:

• skills/nemo-fabric-integrate/SKILL.md

**/*.{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 spell NVIDIA in all caps; do not use Nvidia, nvidia, or NV.
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 as here or read 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.
Use can for possibility and reserve may for permission.
Use after for temporal relationships instead of once, and prefer refer to over see when 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:

• skills/nemo-fabric-integrate/SKILL.md

**/*.{md,rst,txt,adoc}

📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-language-mechanics.md)

**/*.{md,rst,txt,adoc}: For technical documentation, use professional, active, conversational, engaging, precise, and plain-English prose. Prefer active voice, present tense, short sentences, and scannable paragraphs. Avoid casual or imprecise language, swearing, threats, insults, jokes, puns, culture-specific idioms, marketing exaggeration, and unsupported third-party comparisons.
Use can for possibility and reserve may for permission; use after for temporal order; use refer to for cross-references; prefer short direct sentences and specific verbs; avoid unnecessary please in technical documentation.
Prefer active voice when the actor matters. Passive voice is acceptable when the actor is unknown or irrelevant, when the action or result is the focus, or in programmer documentation.
Use natural contractions in conversational technical prose, but do not force them in formal legal copy, API references, or generated text.
Prefer simpler English over Latinisms: use for example or such as instead of e.g., and so on instead of etc., that is instead of i.e., compared to instead of vs., and by, through, or using instead of via. Use industry-standard terms such as in silico, in vitro, and in vivo when appropriate, and italicize them in running text.
Use that without commas for essential clauses, and which with commas for nonessential clauses.
Format dates and times clearly: spell out months in body text; use forms such as June 12, 2025; avoid numeric or ordinal dates; capitalize days; use 12-hour time when appropriate; include a space before a.m. or p.m.; use ET and PT for needed time zones; avoid 24/7; and prefer from 12:30 to 1:00 p.m. for prose ranges.
Format numbers consistently: spell out zero through nine in body text, use numerals for 10 or greater and for technical values, use commas in thousands, do not begin a sentence with a numeral, spell out ordinals, and use numerals consistently within a category wh...

Files:

• skills/nemo-fabric-integrate/SKILL.md

skills/**

📄 CodeRabbit inference engine (AGENTS.md)

skills/**: Keep consumer skills under skills/ self-contained and dependent only on supported public Python SDK contracts and published documentation; do not add repository-internal contribution guidance.
Keep consumer skills in parity with the public SDK guide, model, and type details when the Python/Rust binding contract changes.

Files:

• skills/nemo-fabric-integrate/SKILL.md

**/*.{md,mdx}

📄 CodeRabbit inference engine (.agents/skills/review-doc-style/SKILL.md)

**/*.{md,mdx}: Use the full product name NVIDIA NeMo Fabric on its first usage, typically in the title or H1; use NeMo Fabric thereafter.
Use fabric by itself only when referring to the CLI tool, and surround those references with backticks.
Capitalize NVIDIA correctly in public documentation.
Format commands, code elements, expressions, file names, paths, and filenames as inline code where needed.
Use title case consistently for headings in technical documentation.
Introduce code blocks, tables, and lists with complete lead-in sentences.
Use descriptive anchor text instead of raw URLs or generic link text such as here.
Prefer active voice, present tense, short sentences, and plain English.
Use consistent terminology for the same concept throughout a document.
Write procedures as imperative, parallel, easy-to-scan steps, and split long sequences into smaller tasks.
Use after instead of once when expressing temporal sequence.
Use can instead of may when the intended meaning is possibility rather than permission.
Avoid ambiguous numeric dates and ordinal dates in body text.
For learning-oriented documentation, do not force trademark symbols unless the source document explicitly requires them.
Introduce examples' code blocks with full sentences and ensure examples match current APIs and build commands.

Update relevant documentation when public behavior, adapters, examples, or workspace structure changes; keep README files, SDK/API references, adapter/example documentation, embedded examples, and integration notes current.

Files:

• skills/nemo-fabric-integrate/SKILL.md

**/*.{rs,py,html,md,mdx,toml,yaml,yml,sh,bash}

📄 CodeRabbit inference engine (CONTRIBUTING.md)

All source files must include the appropriate SPDX license header using the comment syntax for their file type.

Files:

• skills/nemo-fabric-integrate/SKILL.md

{*.md,**/*.md,**/*.mdx,**/*.ipynb}

⚙️ CodeRabbit configuration file

{*.md,**/*.md,**/*.mdx,**/*.ipynb}: Enforce the product name in user-facing prose: use "NVIDIA NeMo Fabric" on first use and "NeMo Fabric" thereafter. Flag standalone capitalized "Fabric" when it refers to the product. Do not flag the lowercase fabric CLI command, package/import/crate names, code identifiers, API symbols, configuration keys, file paths, or unrelated generic uses of the word.

Files:

• skills/nemo-fabric-integrate/SKILL.md

**/SKILL.md

⚙️ CodeRabbit configuration file

**/SKILL.md: Do not flag SKILL.md files for missing SPDX headers. Skill entrypoints intentionally start with YAML frontmatter instead.
Verify that every SKILL.md keeps valid YAML frontmatter with at least name and description fields before the Markdown body.

Files:

• skills/nemo-fabric-integrate/SKILL.md

🧠 Learnings (1)

📓 Common learnings

Learnt from: CR
Repo: NVIDIA/NeMo-Fabric

Timestamp: 2026-07-22T17:12:24.885Z
Learning: Versioned release tags must use raw Rust-compatible SemVer without a leading `v`, such as `0.1.0` or `0.1.0-rc.1`.

Learnt from: CR
Repo: NVIDIA/NeMo-Fabric

Timestamp: 2026-07-22T17:12:24.885Z
Learning: All contributors must sign off every commit with `git commit -s`; unsigned commits are not accepted.

Learnt from: CR
Repo: NVIDIA/NeMo-Fabric

Timestamp: 2026-07-22T17:12:24.885Z
Learning: Before submitting a pull request, identify an issue, run relevant tests, verify affected packages compile, update documentation, and rebase on the latest `main`.

Learnt from: CR
Repo: NVIDIA/NeMo-Fabric

Timestamp: 2026-07-22T17:12:24.885Z
Learning: Pull requests must include an overview, reviewer starting point, related issue, testing details, and breaking-change information.

Learnt from: CR
Repo: NVIDIA/NeMo-Fabric

Timestamp: 2026-07-22T17:12:24.885Z
Learning: Pull requests require at least one approving review, passing CI, and addressing feedback with additional commits without force-pushing during review.

Learnt from: CR
Repo: NVIDIA/NeMo-Fabric

Timestamp: 2026-07-22T17:12:24.885Z
Learning: Use commit messages formatted as `type: short description`, with a valid type (`feat`, `fix`, `docs`, `test`, `refactor`, `chore`, or `perf`) and a first line under 72 characters.

[dagardner-nv]

/merge