docs: Document release procedures - #172
Conversation
…Fabric Signed-off-by: David Gardner <dagardner@nvidia.com>
Signed-off-by: David Gardner <dagardner@nvidia.com>
|
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:
WalkthroughAdded ChangesRelease process
Estimated code review effort: 3 (Moderate) | ~30 minutes Sequence Diagram(s)sequenceDiagram
participant Maintainer
participant ReleaseNotesSkill
participant EvidenceCollector
participant Git
Maintainer->>ReleaseNotesSkill: Start release-note workflow
ReleaseNotesSkill->>EvidenceCollector: Request release evidence
EvidenceCollector->>Git: Resolve refs and inspect commits
Git-->>EvidenceCollector: Return commits, paths, and release-note trees
EvidenceCollector-->>ReleaseNotesSkill: Return categorized evidence
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 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: 9
🤖 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 @.agents/skills/draft-release-notes/scripts/collect_release_evidence.py:
- Around line 142-145: Remove the ancestor requirement from the ref-resolution
flow around resolve_ref and run_git. Resolve both previous and current refs,
then compute and report their merge base so divergent release branches are
accepted; retain the existing RuntimeError handling for genuine ref or Git
failures.
In @.agents/skills/prepare-code-freeze/SKILL.md:
- Line 64: Update the ordered procedure list in SKILL.md so the step currently
numbered 9 is numbered 8, restoring sequential numbering after item 7 while
preserving the existing PR instructions.
- Around line 1-4: Add the repository-standard copyright and Apache-2.0 SPDX
HTML-comment header immediately after the closing YAML frontmatter delimiter in
.agents/skills/prepare-code-freeze/SKILL.md (lines 1-4) and
.agents/skills/draft-release-notes/SKILL.md (lines 1-4), while keeping the YAML
frontmatter first.
- Around line 33-36: Update the code-freeze workflow in SKILL.md so Step 4
explicitly creates and switches to the PR branch from the latest upstream/main
using the documented branch-name pattern before Step 5 runs just set-version.
Ensure the version bump is performed on this newly checked-out code-freeze
branch, not an unrelated current branch.
In `@RELEASING.md`:
- Around line 180-181: Correct the release-history sentence in the referenced
release-notes documentation so it ends with a single period after “GitHub
Releases”; preserve the MDX front matter and JSX SPDX comment unchanged.
- Around line 6-8: Update the first product reference in RELEASING.md:6-8 by
changing the H1 to use “NVIDIA NeMo Fabric”; update
.agents/skills/prepare-code-freeze/SKILL.md:2-3 and
.agents/skills/draft-release-notes/SKILL.md:2-3 so each description’s first
product reference uses “NVIDIA NeMo Fabric,” retaining “NeMo Fabric” for
subsequent references.
- Around line 254-265: Update the release checklist UI references around
“Releases”, “Tags”, “Create release from tag”, and “Generate release notes” to
use bold formatting for the exact labels, and replace the raw PyPI registry URLs
in the post-release checks with descriptive Markdown links such as
[PyPI](https://pypi.org/) while preserving the existing verification steps.
- Around line 54-62: Update the “Release Tags” section in RELEASING.md to
explicitly document all supported prerelease forms: v<version>-alpha.<number>,
v<version>-beta.<number>, and v<version>-rc.<number>. Keep the guidance
consistent with the publication behavior described in the later CI section and
retain the leading-v requirement.
- Around line 222-249: Update the “What CI Does On A Tag Push” description to
state that stable, beta, and RC tags trigger ci_python.yml, publish_rust.yml,
and fern-docs.yml, while alpha tags trigger only ci_python.yml. Keep the
subsequent workflow responsibilities and publication details consistent with
this distinction.
🪄 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: a6c85106-99ff-43a8-8ddb-5b46a2d0e389
📒 Files selected for processing (9)
.agents/skills/README.md.agents/skills/contribute-docs/SKILL.md.agents/skills/draft-release-notes/SKILL.md.agents/skills/draft-release-notes/scripts/collect_release_evidence.py.agents/skills/maintain-ci/SKILL.md.agents/skills/maintain-packaging/SKILL.md.agents/skills/prepare-code-freeze/SKILL.mdAGENTS.mdRELEASING.md
📜 Review details
⏰ Context from checks skipped due to timeout. (8)
- GitHub Check: Test (Python 3.14, windows-amd64)
- GitHub Check: Test (Python 3.12, windows-amd64)
- GitHub Check: Test (Python 3.13, windows-amd64)
- GitHub Check: Test (Python 3.11, windows-amd64)
- GitHub Check: Test (Python 3.14, macos-arm64)
- GitHub Check: Test (Python 3.11, macos-arm64)
- GitHub Check: Test (Python 3.13, macos-arm64)
- GitHub Check: Pre-commit
🧰 Additional context used
📓 Path-based instructions (20)
**/.agents/skills/**
📄 CodeRabbit inference engine (.agents/skills/README.md)
Use this maintainer skill set for repository work involving public APIs, tests, CI, packaging, releases, documentation, and pull requests.
Files:
.agents/skills/contribute-docs/SKILL.md.agents/skills/draft-release-notes/SKILL.md.agents/skills/README.md.agents/skills/prepare-code-freeze/SKILL.md.agents/skills/maintain-ci/SKILL.md.agents/skills/maintain-packaging/SKILL.md.agents/skills/draft-release-notes/scripts/collect_release_evidence.py
**/.agents/skills/**/SKILL.md
📄 CodeRabbit inference engine (.agents/skills/README.md)
**/.agents/skills/**/SKILL.md: Name maintainer skills descriptively using task-based names, such ascontribute-apiandvalidate-change.
Begin everySKILL.mdwith YAML frontmatter containing at leastnameanddescription.
Files:
.agents/skills/contribute-docs/SKILL.md.agents/skills/draft-release-notes/SKILL.md.agents/skills/prepare-code-freeze/SKILL.md.agents/skills/maintain-ci/SKILL.md.agents/skills/maintain-packaging/SKILL.md
.agents/skills/**
📄 CodeRabbit inference engine (.agents/skills/README.md)
Ensure coding agents can auto-discover the maintainer skill set from
.agents/skills/.
.agents/skills/**: Use maintainer skills for repository contributions, including API, documentation, testing, CI, packaging, release, and PR preparation; they may reference repository internals.
Do not add consumer integration guidance to the maintainer skill set.
Files:
.agents/skills/contribute-docs/SKILL.md.agents/skills/draft-release-notes/SKILL.md.agents/skills/README.md.agents/skills/prepare-code-freeze/SKILL.md.agents/skills/maintain-ci/SKILL.md.agents/skills/maintain-packaging/SKILL.md.agents/skills/draft-release-notes/scripts/collect_release_evidence.py
**/*.{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:
AGENTS.mdRELEASING.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 spellNVIDIAin all caps; do not useNvidia,nvidia,nVidia,nVIDIA, orNV.
Usean NVIDIAbefore a noun, because the name begins with an “en” sound.
Do not add a registered trademark symbol afterNVIDIAwhen 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 withNVIDIAon 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:
AGENTS.mdRELEASING.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 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:
AGENTS.mdRELEASING.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.
Usecanfor possibility and reservemayfor permission; useafterfor temporal order; userefer tofor cross-references; prefer short direct sentences and specific verbs; avoid unnecessarypleasein 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: usefor exampleorsuch asinstead ofe.g.,and so oninstead ofetc.,that isinstead ofi.e.,compared toinstead ofvs., andby,through, orusinginstead ofvia. Use industry-standard terms such as in silico, in vitro, and in vivo when appropriate, and italicize them in running text.
Usethatwithout commas for essential clauses, andwhichwith commas for nonessential clauses.
Format dates and times clearly: spell out months in body text; use forms such asJune 12, 2025; avoid numeric or ordinal dates; capitalize days; use 12-hour time when appropriate; include a space beforea.m.orp.m.; useETandPTfor needed time zones; avoid24/7; and preferfrom 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:
AGENTS.mdRELEASING.md
**/AGENTS.md
📄 CodeRabbit inference engine (CLAUDE.md)
Follow the instructions documented in
AGENTS.mdwhen working in the repository.
Files:
AGENTS.md
**/*.{md,mdx,yml,py,rs,sh}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/SKILL.md)
Keep documentation aligned with current NeMo Fabric behavior, repository layout, entry points, commands, package names, APIs, bindings, and support claims.
Files:
AGENTS.mdRELEASING.md
**/*.{md,mdx}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/SKILL.md)
**/*.{md,mdx}: Use the full product nameNVIDIA NeMo Fabricon first use, typically in the title and H1; useNeMo Fabricthereafter. Usefabricalone only for the CLI tool and surround it with backticks.
Treat incorrect or stale commands, package names, paths, APIs, support claims, procedures, examples, terminology, or public behavior documentation as blocking issues.
CapitalizeNVIDIAcorrectly and format code, commands, paths, and filenames as inline code where needed.
Use title case for technical-documentation headings.
Introduce code blocks, tables, and lists with complete lead-in sentences; ensure examples match current APIs and build commands.
Use descriptive anchor text, avoid raw URLs and generic labels such ashere, and use repository-relative.mdxpaths for links withindocs/.
Prefer active voice, present tense, short sentences, plain English, consistent terminology, and imperative, parallel, scannable procedures.
Useafterinstead ofoncewhen expressing temporal sequence, and usecanrather thanmaywhen describing 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.
When reporting documentation-review findings, lead withMust fix,Should fix, andNice to havecategories; include file path, line reference, current problem, rationale, and a concrete rewrite or direction.In documentation and examples, reference
scripts/generate_api_docs.shas the stable public wrapper; referencescripts/docs/helper paths only when documenting internal maintenance work.
Files:
AGENTS.mdRELEASING.md
**/*.md
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Update relevant SDK, API reference, adapter, example, integration, and support documentation when the corresponding public surface changes.
Files:
AGENTS.mdRELEASING.md
**/*.{html,md}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
HTML and Markdown files must use the specified SPDX HTML-comment header.
Files:
AGENTS.mdRELEASING.md
**/*.{md,mdx,rst,yml,yaml}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
**/*.{md,mdx,rst,yml,yaml}: Keep package names, repository references, and build commands current.
Run the documentation validation commandjust docswhen the documentation site changes.
Files:
AGENTS.mdRELEASING.md
**/*.{toml,lock,json,yml,yaml,md,py,rs}
📄 CodeRabbit inference engine (.agents/skills/maintain-packaging/SKILL.md)
Keep package names, import paths, module names, generated artifact locations, CI install commands, examples, and local workflows internally consistent.
Files:
AGENTS.mdRELEASING.md
**/{README.md,*.md,*.mdx}
📄 CodeRabbit inference engine (AGENTS.md)
When public behavior, the
nemo-fabricpackage, examples, or supported bindings change, update the relevant user-facing documentation entry points, including the root README, Fern docs, adapter and integration READMEs, and examples README.
Files:
AGENTS.mdRELEASING.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.
For links between files under docs/, require paths relative to the source file with the target file's .mdx extension so they work in both Fern builds and repository browsers. Flag Fern site-root links such as NeMo Fabric overview; use the repository-relative equivalent, such as NeMo Fabric overview.
Files:
AGENTS.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 lowercasefabricCLI command, package/import/crate names, code identifiers, API symbols, configuration keys, file paths, or unrelated generic uses of the word.
Files:
AGENTS.mdRELEASING.md
.agents/skills/maintain-packaging/SKILL.md
📄 CodeRabbit inference engine (AGENTS.md)
Keep packaging implementation guidance in
.agents/skills/maintain-packaging/SKILL.md.
Files:
.agents/skills/maintain-packaging/SKILL.md
.agents/skills/draft-release-notes/scripts/collect_release_evidence.py
📄 CodeRabbit inference engine (.agents/skills/draft-release-notes/SKILL.md)
Run the read-only evidence collector with explicit previous and current release refs and the target major/minor version before drafting release notes.
Files:
.agents/skills/draft-release-notes/scripts/collect_release_evidence.py
RELEASING.md
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Keep release-process and release-history policy in
RELEASING.md.Reflect public packaging changes, release tags, registry publication procedures, and current install/import/build commands in release-facing documentation.
Keep release policy and the end-to-end maintainer workflow in
RELEASING.md.
Files:
RELEASING.md
🧠 Learnings (1)
📓 Common learnings
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:39:56.701Z
Learning: Keep documentation and example changes scoped, surface assumptions, and define focused validation before editing.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:40:02.573Z
Learning: Confirm the target release version from the release branch and package metadata, and preserve unrelated working-tree changes.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:40:02.573Z
Learning: Treat the evidence collector's grouped commits as an evidence index, not publication-ready copy.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:40:02.573Z
Learning: Run `git diff --check` and `just docs` after reviewing public claims.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:40:02.573Z
Learning: Check product names, commands, package names, support claims, and links against the current repository before handing off the draft.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:40:25.382Z
Learning: Prompt for `<next-version>` when it is not provided; this is the version that `main` adopts after the release branch is created.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:40:25.382Z
Learning: Fetch the latest `upstream/main`, create the release branch from it, and push the branch to `upstream`; if it already exists, verify that it points to the expected commit.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:40:25.382Z
Learning: Create the code-freeze PR branch from the latest `upstream/main`.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:40:25.382Z
Learning: Run `just set-version <next-version>` to update all release-versioned package surfaces on `main`.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:40:25.382Z
Learning: Validate the freeze with `cargo check --workspace --locked`, `just build-all`, `just wheels`, `just --fmt --check`, a search for remaining old-version documentation references, and `git diff --check`.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:40:25.382Z
Learning: The code-freeze PR must target `main`, not the release branch, and must mention the new release branch, nightly alpha branch configuration update, version bump, documentation updates or intentional leftovers, and the new release-branch target for release-bound PRs.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:40:25.382Z
Learning: Do not create release tags during a code freeze; create only the release branch and main PR.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:40:25.382Z
Learning: Do not leave uncommitted user changes mixed into the code-freeze PR branch.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:40:25.382Z
Learning: Use `update-project-version` for version semantics, `maintain-ci` when freeze changes affect nightly or release-branch automation, and `prepare-pr` before opening the PR.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:40:34.629Z
Learning: Use branch prefixes `feat/`, `fix/`, `docs/`, `test/`, or `refactor/`.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:40:34.629Z
Learning: Name branches after the work, never the Linear ticket; do not embed ticket IDs or slugs in branch names.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:40:34.629Z
Learning: Use Conventional Commit PR titles in the form `<type>: <summary>`; reserve `fix` for actual product bugs, not CI, documentation, or chores.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:40:34.629Z
Learning: Use signed-off commits with `git commit -s` for pull-request work.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:40:34.629Z
Learning: When creating a pull request from the current branch, target the upstream repository rather than a fork.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:40:34.629Z
Learning: If repository-local PR guidance conflicts with generic GitHub connector or plugin guidance, follow the repository-local guidance for PR body format and review handoff details.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:40:34.629Z
Learning: PR descriptions must include what changed, why, how it was tested, and any breaking changes within the repository template format.
🪛 ast-grep (0.45.0)
.agents/skills/draft-release-notes/scripts/collect_release_evidence.py
[error] 29-35: Command coming from incoming request
Context: subprocess.run(
["git", *args],
cwd=repo,
check=False,
capture_output=True,
encoding="utf-8",
)
Note: [CWE-78] Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection').
(subprocess-from-request)
[warning] 58-58: XPath query is request-/variable-derived; use parameterized XPath to prevent injection.
Context: VERSION_PATTERN.findall(content)
Note: [CWE-643] Improper Neutralization of Data within XPath Expressions ('XPath Injection').
(xpath-injection-python)
🪛 LanguageTool
.agents/skills/prepare-code-freeze/SKILL.md
[uncategorized] ~64-~64: The official name of this software platform is spelled with a capital “H”.
Context: ...on. 9. Open a PR targeting main using .github/pull_request_template.md. The PR mu...
(GITHUB)
RELEASING.md
[uncategorized] ~224-~224: The official name of this software platform is spelled with a capital “H”.
Context: ... Tag Push Pushing a valid tag triggers [.github/workflows/ci_python.yml](.github/workf...
(GITHUB)
[uncategorized] ~225-~225: The official name of this software platform is spelled with a capital “H”.
Context: ...yml](.github/workflows/ci_python.yml), [.github/workflows/publish_rust.yml`](.github/wo...
(GITHUB)
[uncategorized] ~226-~226: The official name of this software platform is spelled with a capital “H”.
Context: ...github/workflows/publish_rust.yml), and [.github/workflows/fern-docs.yml](.github/workf...
(GITHUB)
🪛 markdownlint-cli2 (0.23.1)
.agents/skills/prepare-code-freeze/SKILL.md
[warning] 64-64: Ordered list item prefix
Expected: 8; Actual: 9; Style: 1/2/3
(MD029, ol-prefix)
🪛 Ruff (0.16.0)
.agents/skills/draft-release-notes/scripts/collect_release_evidence.py
[error] 30-30: subprocess call: check for execution of untrusted input
(S603)
[error] 31-31: Starting a process with a partial executable path
(S607)
[warning] 39-39: Avoid specifying long messages outside the exception class
(TRY003)
🔇 Additional comments (5)
AGENTS.md (1)
51-51: LGTM!.agents/skills/README.md (1)
41-42: LGTM!.agents/skills/contribute-docs/SKILL.md (1)
24-25: LGTM!Also applies to: 43-43
.agents/skills/maintain-ci/SKILL.md (1)
37-38: LGTM!Also applies to: 94-97
.agents/skills/maintain-packaging/SKILL.md (1)
31-32: LGTM!Also applies to: 92-92
Signed-off-by: David Gardner <dagardner@nvidia.com>
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
RELEASING.md (2)
85-95: 🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick winMust fix — Switch to
mainbefore bumping the next release version.After the branch creation commands, the checkout remains on
release/0.2. Step 88 says to bump versions onmain, but the procedure does not show a switch to an up-to-datemainor a PR branch based on it. A maintainer can runjust set-version <next-version>on the release branch instead.Add an explicit fetch and checkout or branch-creation step before
just set-version.Based on learnings, a code freeze must create the release branch, advance
main, and prepare the code-freeze pull request.🤖 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 `@RELEASING.md` around lines 85 - 95, Update the release procedure after creating the release branch to fetch the latest remote state and switch to an up-to-date main-based branch before running just set-version <next-version>. Include the required code-freeze flow: create the release branch, advance main, and prepare the code-freeze pull request, ensuring the version bump cannot run on release/0.2.Source: Learnings
137-152: 🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick winMust fix — Make release validation complete and mandatory.
The baseline omits the required metadata check,
cargo check --workspace --locked,just build-python,just --fmt --check, andgit diff --check. It also treatsjust wheelsas optional even though wheel artifacts are a published release surface.Add these checks to the required release validation.
As per coding guidelines, version changes require targeted metadata searches, locked Rust validation,
just build-python, release wheel builds, andgit diff --check. Based on learnings, runjust --fmt --checkbefore handoff.🤖 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 `@RELEASING.md` around lines 137 - 152, Update the required release-validation commands in RELEASING.md to include targeted metadata searches, cargo check --workspace --locked, just build-python, just wheels, just --fmt --check, and git diff --check. Move the wheel build from the optional section into the mandatory baseline and retain the existing checks.Sources: Coding guidelines, Learnings
🤖 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 `@RELEASING.md`:
- Around line 171-177: Update both release procedures in RELEASING.md to replace
the git pull commands immediately before tagging with git pull --ff-only, then
add a verification step confirming the checked-out commit is the expected
release commit before each git tag command. Preserve the existing branch
checkout and tagging flow.
---
Outside diff comments:
In `@RELEASING.md`:
- Around line 85-95: Update the release procedure after creating the release
branch to fetch the latest remote state and switch to an up-to-date main-based
branch before running just set-version <next-version>. Include the required
code-freeze flow: create the release branch, advance main, and prepare the
code-freeze pull request, ensuring the version bump cannot run on release/0.2.
- Around line 137-152: Update the required release-validation commands in
RELEASING.md to include targeted metadata searches, cargo check --workspace
--locked, just build-python, just wheels, just --fmt --check, and git diff
--check. Move the wheel build from the optional section into the mandatory
baseline and retain the existing checks.
🪄 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: d8b890a1-cb4f-46bf-9c10-cb3ff2909733
📒 Files selected for processing (1)
RELEASING.md
📜 Review details
⏰ Context from checks skipped due to timeout. (14)
- GitHub Check: Test (Python 3.12, windows-amd64)
- GitHub Check: Test (Python 3.14, windows-amd64)
- GitHub Check: Test (Python 3.11, windows-amd64)
- GitHub Check: Test (Python 3.13, windows-amd64)
- GitHub Check: Test (Python 3.13, linux-arm64)
- GitHub Check: Test (Python 3.11, macos-arm64)
- GitHub Check: Test (Python 3.14, macos-arm64)
- GitHub Check: Test (Python 3.11, linux-arm64)
- GitHub Check: Test (Python 3.12, linux-arm64)
- GitHub Check: Test (Python 3.12, macos-arm64)
- GitHub Check: Test (Python 3.13, macos-arm64)
- GitHub Check: Test (Python 3.13, linux-amd64)
- GitHub Check: Test (Python 3.11, linux-amd64)
- GitHub Check: Pre-commit
🧰 Additional context used
📓 Path-based instructions (12)
**/*.{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:
RELEASING.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 spellNVIDIAin all caps; do not useNvidia,nvidia,nVidia,nVIDIA, orNV.
Usean NVIDIAbefore a noun, because the name begins with an “en” sound.
Do not add a registered trademark symbol afterNVIDIAwhen 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 withNVIDIAon 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:
RELEASING.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 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:
RELEASING.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.
Usecanfor possibility and reservemayfor permission; useafterfor temporal order; userefer tofor cross-references; prefer short direct sentences and specific verbs; avoid unnecessarypleasein 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: usefor exampleorsuch asinstead ofe.g.,and so oninstead ofetc.,that isinstead ofi.e.,compared toinstead ofvs., andby,through, orusinginstead ofvia. Use industry-standard terms such as in silico, in vitro, and in vivo when appropriate, and italicize them in running text.
Usethatwithout commas for essential clauses, andwhichwith commas for nonessential clauses.
Format dates and times clearly: spell out months in body text; use forms such asJune 12, 2025; avoid numeric or ordinal dates; capitalize days; use 12-hour time when appropriate; include a space beforea.m.orp.m.; useETandPTfor needed time zones; avoid24/7; and preferfrom 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:
RELEASING.md
**/*.{md,mdx,yml,py,rs,sh}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/SKILL.md)
Keep documentation aligned with current NeMo Fabric behavior, repository layout, entry points, commands, package names, APIs, bindings, and support claims.
Files:
RELEASING.md
**/*.{md,mdx}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/SKILL.md)
**/*.{md,mdx}: Use the full product nameNVIDIA NeMo Fabricon first use, typically in the title and H1; useNeMo Fabricthereafter. Usefabricalone only for the CLI tool and surround it with backticks.
Treat incorrect or stale commands, package names, paths, APIs, support claims, procedures, examples, terminology, or public behavior documentation as blocking issues.
CapitalizeNVIDIAcorrectly and format code, commands, paths, and filenames as inline code where needed.
Use title case for technical-documentation headings.
Introduce code blocks, tables, and lists with complete lead-in sentences; ensure examples match current APIs and build commands.
Use descriptive anchor text, avoid raw URLs and generic labels such ashere, and use repository-relative.mdxpaths for links withindocs/.
Prefer active voice, present tense, short sentences, plain English, consistent terminology, and imperative, parallel, scannable procedures.
Useafterinstead ofoncewhen expressing temporal sequence, and usecanrather thanmaywhen describing 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.
When reporting documentation-review findings, lead withMust fix,Should fix, andNice to havecategories; include file path, line reference, current problem, rationale, and a concrete rewrite or direction.
**/*.{md,mdx}: In documentation, prefer the documented public API over internal shortcuts.
Keep release-process and release-history policy inRELEASING.md; do not duplicate it in user-facing documentation or aCHANGELOG.md.
Files:
RELEASING.md
**/*.md
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Update relevant SDK, API reference, adapter, example, integration, and support documentation when the corresponding public surface changes.
Files:
RELEASING.md
**/*.{html,md}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
HTML and Markdown files must use the specified SPDX HTML-comment header.
Files:
RELEASING.md
**/*.{md,mdx,yml,yaml}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
**/*.{md,mdx,yml,yaml}: Keep package names, repository references, and build commands current in documentation and example-related configuration.
Update entry-point documentation, includingREADME.mdordocs/index.yml, when examples or documentation reading paths change.
Update relevant getting-started, reference, adapter, and example README documentation when related examples or adapters change.
Runjust docswhen the documentation site changes.
Files:
RELEASING.md
RELEASING.md
📄 CodeRabbit inference engine (.agents/skills/maintain-packaging/SKILL.md)
Reflect public packaging changes in release-facing documentation, including release tags, registry publication, and current install/import/build commands.
Files:
RELEASING.md
{RELEASING.md,.agents/skills/maintain-packaging/SKILL.md,docs/**/*}
📄 CodeRabbit inference engine (AGENTS.md)
Keep release policy and end-to-end maintainer workflow in
RELEASING.md, packaging implementation guidance in.agents/skills/maintain-packaging/SKILL.md, and do not move release-history policy into user-facing docs or add a duplicateCHANGELOG.md.
Files:
RELEASING.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 lowercasefabricCLI command, package/import/crate names, code identifiers, API symbols, configuration keys, file paths, or unrelated generic uses of the word.
Files:
RELEASING.md
🧠 Learnings (1)
📓 Common learnings
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:50:50.620Z
Learning: Use maintainer skills for repository work involving public APIs, tests, CI, packaging, releases, documentation, and pull requests; keep consumer-facing integration guidance in the top-level `skills/` directory.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:50:50.620Z
Learning: When adding a public API, maintain parity across Rust, CLI, Python, schema, adapters, and documentation.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:50:50.620Z
Learning: Production-ready harness adapters must define explicit capability, policy, packaging, lifecycle, and validation contracts.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:50:50.620Z
Learning: Maintain package metadata, native artifacts, lockfiles, and release surfaces when changing packaging.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:50:50.620Z
Learning: Synchronize release versions across packaging when updating the project version.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:50:50.620Z
Learning: Create a release branch, advance `main`, and prepare the code-freeze pull request when preparing a code freeze.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:50:50.620Z
Learning: Draft documentation release notes from verified repository evidence.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:50:50.620Z
Learning: Prepare, open, or edit pull requests with the correct scope and review handoff.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:51:01.057Z
Learning: Draft release notes from verified repository evidence; verify candidate claims in public documentation, API types, command help, or source before including them.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:51:01.057Z
Learning: State that the full release history is available in GitHub Releases; do not create a changelog or GitHub Release body from this skill.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:51:01.057Z
Learning: Confirm the target release version from the release branch and package metadata, and preserve unrelated working-tree changes.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:51:01.057Z
Learning: Run the read-only release-evidence helper with explicit previous and current release refs and the target minor version before drafting.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:51:01.057Z
Learning: Prioritize breaking changes, migrations, user-visible features, and ongoing support limitations when selecting release-note content.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:51:01.057Z
Learning: Run `git diff --check` and `just docs` after updating release notes.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:51:01.057Z
Learning: Check product names, commands, package names, support claims, and links against the current repository before handing off the draft.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:51:09.833Z
Learning: Keep changes scoped, surface assumptions, and define focused validation before editing.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:51:09.833Z
Learning: Validate workflow changes with the narrowest useful checks, beginning with `just --fmt --check`, and inspect workflow references with `rg -n "uses:|permissions:|secrets:|concurrency:|cache|just " .github/workflows`.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:51:09.833Z
Learning: When local lint passes but GitHub authorization is uncertain, inspect GitHub's permission model and the upstream action or reusable-workflow source rather than assuming local success proves remote success.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:51:09.833Z
Learning: Do not cache generated outputs when caching could hide stale behavior, unless the repository deliberately relies on that cache.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:51:19.716Z
Learning: Record the functional need, viable alternatives considered, why the selected dependency is the narrowest fit, and any unresolved licensing question; route licensing uncertainties to dependency approvers with distribution and linkage context.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:51:19.716Z
Learning: Keep changes scoped, surface assumptions, and define focused validation before editing; use the companion `karpathy-guidelines` alongside this guidance.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:51:26.701Z
Learning: Derive the release branch name as `release/<major>.<minor>`.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:51:26.701Z
Learning: Create the release branch from the latest `upstream/main`; if it already exists, verify that it points to the expected commit before continuing.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:51:26.701Z
Learning: Prompt for `<next-version>` when it was not provided; this is the version that `main` uses after the release branch is cut.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:51:26.701Z
Learning: Use `just set-version <next-version>` to bump all release-versioned package surfaces on `main`.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:51:26.701Z
Learning: Run `just build-all`, `just wheels`, `just --fmt --check`, the documentation old-version search, and `git diff --check` before opening the PR.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:51:26.701Z
Learning: The code-freeze PR must mention the new release branch, nightly alpha branch configuration update, version bump, documentation reference updates or intentional leftovers, and that release-bound PRs now target the new `release/*` branch.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:51:26.701Z
Learning: Do not create release tags during a code freeze; create only the release branch and main PR.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:51:26.701Z
Learning: Do not target the code-freeze PR at the release branch; target `main`.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:51:26.701Z
Learning: Do not leave uncommitted user changes mixed into the code-freeze PR branch.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:51:36.245Z
Learning: Use branch prefixes `feat/`, `fix/`, `docs/`, `test/`, or `refactor/`.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:51:36.245Z
Learning: Name branches after the work and never include Linear ticket IDs or slugs in the branch name.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:51:36.245Z
Learning: Use signed-off commits for pull request work with `git commit -s`.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:51:36.245Z
Learning: When creating a pull request from the current branch, target the upstream repository rather than a fork.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T22:51:36.245Z
Learning: If repository-local PR guidance conflicts with generic GitHub connector or plugin guidance, follow the repository-local guidance for PR body format and review handoff details.
🔇 Additional comments (6)
RELEASING.md (6)
6-8: Must fix — Duplicate: Use the full product name on first use.The heading is the first product reference, but it says
NeMo Fabric. Change it toNVIDIA NeMo Fabric. KeepNeMo Fabricfor later references.As per path instructions, use
NVIDIA NeMo Fabricon first use andNeMo Fabricthereafter.Source: Path instructions
58-60: Must fix — Duplicate: Document every supported prerelease tag form.The policy lists
v0.1.0-rc.1, but Line 177 emitsv0.1.0-rc1. Document the supported alpha, beta, and RC forms, including the compact RC form accepted by the repository, and use one canonical RC form in the commands.Based on repository release-tag behavior, the documented forms must match the accepted forms and publication rules.
Also applies to: 177-177
209-210: Should fix — Duplicate: Remove the extra period.Change
GitHub Releases..toGitHub Releases.As per coding guidelines, technical documentation must use precise, professional prose.
Source: Coding guidelines
249-252: Must fix — Duplicate: Describe the alpha workflow boundary.The statement says every valid tag triggers all three workflows. Alpha tags trigger only
.github/workflows/ci_python.yml; the Rust and Fern workflows exclude alpha tags. State this distinction before listing workflow responsibilities.Based on repository workflow behavior, alpha tags are excluded from Rust and Fern workflows.
279-290: Should fix — Duplicate: Format UI labels and registry links.Format the exact GitHub controls as bold labels, such as Releases, Tags, Create release from tag, and Generate release notes. Replace the raw registry URLs at Lines 289-290 with descriptive links.
As per coding guidelines, format UI labels in bold and use descriptive link text instead of raw URLs.
Source: Coding guidelines
13-35: LGTM!Also applies to: 37-52, 69-83, 97-134, 188-208, 212-218, 220-229, 238-244, 254-275
Signed-off-by: David Gardner <dagardner@nvidia.com>
Signed-off-by: David Gardner <dagardner@nvidia.com>
Signed-off-by: David Gardner <dagardner@nvidia.com>
Signed-off-by: David Gardner <dagardner@nvidia.com>
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
RELEASING.md (1)
177-184: 🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick winMust fix — Use the documented RC tag format.
Line 177 creates
v${RELEASE_VERSION}-rc${RC_NUM}, such asv0.1.0-rc1. The documented contract requiresv0.1.0-rc.1. Update both the tag name and the push command.Proposed fix
-git tag -as -m "v${RELEASE_VERSION}-rc${RC_NUM}" v${RELEASE_VERSION}-rc${RC_NUM} +git tag -as -m "v${RELEASE_VERSION}-rc.${RC_NUM}" v${RELEASE_VERSION}-rc.${RC_NUM} -git push upstream v${RELEASE_VERSION}-rc${RC_NUM} +git push upstream v${RELEASE_VERSION}-rc.${RC_NUM}🤖 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 `@RELEASING.md` around lines 177 - 184, Update the release-candidate tag references in the tagging, verification, and push commands to use the documented dotted format, placing a period between the rc marker and RC_NUM (for example, v0.1.0-rc.1). Keep the RELEASE_VERSION and RC_NUM variables unchanged.
🤖 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 `@RELEASING.md`:
- Around line 177-184: Update the release-candidate tag references in the
tagging, verification, and push commands to use the documented dotted format,
placing a period between the rc marker and RC_NUM (for example, v0.1.0-rc.1).
Keep the RELEASE_VERSION and RC_NUM variables unchanged.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Enterprise
Run ID: a5cb165a-cc58-4c6c-b798-24e2bd8f46de
📒 Files selected for processing (3)
.agents/skills/draft-release-notes/SKILL.md.agents/skills/prepare-code-freeze/SKILL.mdRELEASING.md
📜 Review details
⏰ Context from checks skipped due to timeout. (4)
- GitHub Check: Test (Python 3.11, windows-amd64)
- GitHub Check: Test (Python 3.13, windows-amd64)
- GitHub Check: Test (Python 3.14, windows-amd64)
- GitHub Check: Test (Python 3.12, windows-amd64)
🧰 Additional context used
📓 Path-based instructions (14)
.agents/skills/**
📄 CodeRabbit inference engine (AGENTS.md)
.agents/skills/**: Use maintainer skills for repository contributions involving API, documentation, testing, CI, packaging, release, and PR preparation; these skills may reference repository internals.
Do not add consumer integration guidance to maintainer skills.
Files:
.agents/skills/draft-release-notes/SKILL.md.agents/skills/prepare-code-freeze/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:
RELEASING.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 spellNVIDIAin all caps; do not useNvidia,nvidia,nVidia,nVIDIA, orNV.
Usean NVIDIAbefore a noun, because the name begins with an “en” sound.
Do not add a registered trademark symbol afterNVIDIAwhen 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 withNVIDIAon 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:
RELEASING.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 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:
RELEASING.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.
Usecanfor possibility and reservemayfor permission; useafterfor temporal order; userefer tofor cross-references; prefer short direct sentences and specific verbs; avoid unnecessarypleasein 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: usefor exampleorsuch asinstead ofe.g.,and so oninstead ofetc.,that isinstead ofi.e.,compared toinstead ofvs., andby,through, orusinginstead ofvia. Use industry-standard terms such as in silico, in vitro, and in vivo when appropriate, and italicize them in running text.
Usethatwithout commas for essential clauses, andwhichwith commas for nonessential clauses.
Format dates and times clearly: spell out months in body text; use forms such asJune 12, 2025; avoid numeric or ordinal dates; capitalize days; use 12-hour time when appropriate; include a space beforea.m.orp.m.; useETandPTfor needed time zones; avoid24/7; and preferfrom 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:
RELEASING.md
**/*.{md,mdx,yml,py,rs,sh}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/SKILL.md)
Keep documentation aligned with current NeMo Fabric behavior, repository layout, entry points, commands, package names, APIs, bindings, and support claims.
Files:
RELEASING.md
**/*.{md,mdx}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/SKILL.md)
**/*.{md,mdx}: Use the full product nameNVIDIA NeMo Fabricon first use, typically in the title and H1; useNeMo Fabricthereafter. Usefabricalone only for the CLI tool and surround it with backticks.
Treat incorrect or stale commands, package names, paths, APIs, support claims, procedures, examples, terminology, or public behavior documentation as blocking issues.
CapitalizeNVIDIAcorrectly and format code, commands, paths, and filenames as inline code where needed.
Use title case for technical-documentation headings.
Introduce code blocks, tables, and lists with complete lead-in sentences; ensure examples match current APIs and build commands.
Use descriptive anchor text, avoid raw URLs and generic labels such ashere, and use repository-relative.mdxpaths for links withindocs/.
Prefer active voice, present tense, short sentences, plain English, consistent terminology, and imperative, parallel, scannable procedures.
Useafterinstead ofoncewhen expressing temporal sequence, and usecanrather thanmaywhen describing 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.
When reporting documentation-review findings, lead withMust fix,Should fix, andNice to havecategories; include file path, line reference, current problem, rationale, and a concrete rewrite or direction.
Files:
RELEASING.md
**/*.md
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Update relevant SDK, API reference, adapter, example, integration, and support documentation when the corresponding public surface changes.
Files:
RELEASING.md
**/*.{html,md}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
HTML and Markdown files must use the specified SPDX HTML-comment header.
Files:
RELEASING.md
**/*.{md,mdx,rst,yml,yaml,py,sh,bash}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Keep package names, repository references, and build commands current.
Files:
RELEASING.md
**/*.{md,mdx,rst,py,sh,bash}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Ensure example commands match current package names and paths.
Files:
RELEASING.md
**/{docs/package.json,docs/package-lock.json,.github/workflows/*.yml,justfile,RELEASING.md}
📄 CodeRabbit inference engine (.agents/skills/maintain-packaging/SKILL.md)
Use current and consistent package names, install commands, import commands, and build commands across documentation, examples, CI workflows, recipes, and release documentation.
Files:
RELEASING.md
RELEASING.md
📄 CodeRabbit inference engine (AGENTS.md)
Keep release policy and the end-to-end maintainer workflow in
RELEASING.md.
Files:
RELEASING.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 lowercasefabricCLI command, package/import/crate names, code identifiers, API symbols, configuration keys, file paths, or unrelated generic uses of the word.
Files:
RELEASING.md
🧠 Learnings (1)
📓 Common learnings
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:18:30.306Z
Learning: Keep maintainer skills focused on developing NeMo Fabric itself, including public APIs, tests, CI, packaging, releases, documentation, and pull requests.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:18:30.306Z
Learning: Keep consumer-facing integration guidance in the top-level `skills/` directory so it can be exported separately; do not include it in the maintainer skill set.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:18:30.306Z
Learning: Use descriptive, task-based names for maintainer skills, such as `contribute-api` and `validate-change`.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:18:30.306Z
Learning: For Claude Code, expose the same maintainer skill set through `.claude/skills` as a symlink to `.agents/skills`, without mixing in consumer skills.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:18:36.637Z
Learning: Run `just docs` when the documentation site changes.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:18:42.369Z
Learning: Use verified repository evidence when drafting release notes, including changed public documentation, API types, command help, and source code.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:18:42.369Z
Learning: Confirm the target release version from the release branch and package metadata before drafting.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:18:42.369Z
Learning: Run `collect_release_evidence.py` with explicit previous and current release refs and the target minor version before reviewing release candidates.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:18:42.369Z
Learning: Treat the helper's commit groups as an evidence index, not publication-ready release-note copy.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:18:42.369Z
Learning: Prioritize breaking changes, migrations, user-visible features, and ongoing support limitations when selecting release-note content.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:18:42.369Z
Learning: Preserve unrelated working-tree changes while preparing release notes.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:18:42.369Z
Learning: Run `git diff --check` and `just docs` after reviewing claims.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:18:42.369Z
Learning: Verify product names, commands, package names, support claims, and links against the current repository before handoff.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:18:49.628Z
Learning: Keep changes scoped, surface assumptions, and define focused validation before editing; use `karpathy-guidelines` alongside this guidance.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:18:49.628Z
Learning: Run the narrowest useful validation, beginning with `just --fmt --check`. If local lint passes but GitHub authorization is uncertain, inspect GitHub's permission model and upstream action or reusable-workflow source rather than assuming local success proves remote success.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:19:04.735Z
Learning: Prompt for `<next-version>` when it is not provided; this is the version that `main` adopts after the release branch is cut.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:19:04.735Z
Learning: Create and push the release branch from the latest `upstream/main`; if it already exists, verify that it points to the expected commit before continuing.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:19:04.735Z
Learning: Create the code-freeze PR branch from the latest `upstream/main`.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:19:04.735Z
Learning: Run `just set-version <next-version>` to bump all release-versioned package surfaces on `main`.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:19:04.735Z
Learning: Leave intentional historical references unchanged, including release notes, changelogs, generated build output, and third-party dependency attribution entries.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:19:04.735Z
Learning: Run `just build-all`, `just wheels`, `just --fmt --check`, the old-version documentation search, and `git diff --check` as targeted freeze validation.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:19:04.735Z
Learning: Any remaining documentation matches for `<old-version>` must be intentional and called out in the PR description.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:19:04.735Z
Learning: The PR description must mention the new release branch, nightly alpha branch configuration update, `just set-version <next-version>` bump, documentation updates or intentional leftovers, and that release-bound PRs now target the new `release/*` branch.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:19:04.735Z
Learning: Do not create release tags; a code freeze creates only the release branch and the main PR.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:19:04.735Z
Learning: Do not target the code-freeze PR at the release branch; target `main` instead.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:19:04.735Z
Learning: Do not leave uncommitted user changes mixed into the code-freeze PR branch.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:19:13.214Z
Learning: Use branch prefixes `feat/`, `fix/`, `docs/`, `test/`, or `refactor/`.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:19:13.214Z
Learning: Name branches after the work and never include Linear ticket IDs or slugs in branch names.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:19:13.214Z
Learning: Use Conventional Commit PR titles in the form `<type>: <summary>`; reserve `fix` for actual product bugs, not CI, documentation, or chores.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:19:13.214Z
Learning: Use signed-off commits for pull-request work with `git commit -s`.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:19:13.214Z
Learning: When creating a pull request from the current branch, target the upstream repository rather than a fork.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:19:13.214Z
Learning: If repository-local PR guidance conflicts with generic GitHub connector or plugin guidance, follow the repository-local guidance for PR body format and review handoff details.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:19:13.214Z
Learning: PR descriptions must include what changed, why, how it was tested, and any breaking changes within the repository template format.
🪛 LanguageTool
.agents/skills/prepare-code-freeze/SKILL.md
[uncategorized] ~66-~66: The official name of this software platform is spelled with a capital “H”.
Context: ...on. 8. Open a PR targeting main using .github/pull_request_template.md. The PR mu...
(GITHUB)
RELEASING.md
[uncategorized] ~253-~253: The official name of this software platform is spelled with a capital “H”.
Context: ...s : | Workflow | Trigger | |---|---| | [.github/workflows/ci_python.yml](.github/workf...
(GITHUB)
[uncategorized] ~254-~254: The official name of this software platform is spelled with a capital “H”.
Context: ...yml) | For all tags including alpha | | [.github/workflows/publish_rust.yml](.github/wo...
(GITHUB)
[uncategorized] ~255-~255: The official name of this software platform is spelled with a capital “H”.
Context: ...ml) | For RC, beta and release tags | | [.github/workflows/fern-docs.yml](.github/workf...
(GITHUB)
🔇 Additional comments (11)
RELEASING.md (7)
54-60: Duplicate — Document all supported prerelease tag forms.This section still documents only RC prereleases. Add the supported alpha and beta forms, and keep the dotted RC form.
171-177: Duplicate — Use fast-forward-only pulls before tagging.Both procedures still run
git pullimmediately beforegit tag. Replace it withgit pull --ff-onlyand verify the expected release commit before each tag command.Also applies to: 231-237
249-255: Duplicate — Name stable tags explicitly.The table uses “release tags” instead of “stable tags”. State that stable, beta, and RC tags trigger the Rust and Fern workflows, while alpha tags trigger only the Python workflow.
280-295: Duplicate — Format UI controls and registry links.Use bold formatting for the exact GitHub control labels. Replace raw registry URLs with descriptive links such as
[PyPI](...).As per coding guidelines, format UI labels in bold and use descriptive link text instead of raw URLs.
Source: Coding guidelines
6-36: LGTM!
69-157: LGTM!
188-218: LGTM!.agents/skills/prepare-code-freeze/SKILL.md (3)
4-5: Duplicate — Add the required SPDX HTML-comment header.The
authorandlicensefrontmatter does not replace the repository copyright and Apache-2.0 SPDX header. Add the required HTML comment after the closing frontmatter.Source: Coding guidelines
35-38: Duplicate — Check out the code-freeze PR branch before runningjust set-version.Step 4 only names
docs/code-freeze-<major>.<minor>; it does not create or switch to that branch. Step 5 can therefore modify the current branch instead of the intended PR branch. Add an explicit checkout command and runjust set-versionthere.
8-34: LGTM!Also applies to: 39-79
.agents/skills/draft-release-notes/SKILL.md (1)
4-5: Duplicate — Add the required SPDX HTML-comment header.The
authorandlicensefrontmatter does not replace the repository copyright and Apache-2.0 SPDX header. Add the required HTML comment after the closing frontmatter.Source: Coding guidelines
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 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 `@RELEASING.md`:
- Around line 289-307: Update the post-release verification section in
RELEASING.md to require the current ${RELEASE_VERSION} for nemo-fabric-core and
nemo-fabric-cli on crates.io, and for every listed Python distribution on both
PyPI indexes. Retain the requirement that nemo-fabric-runtime has a wheel for
each supported platform, and make each check explicitly verify the current
release version rather than merely package-page availability.
- Around line 289-307: Update the Python publication guidance in RELEASING.md to
document the external publisher, its release trigger, and its owner for all
seven distributions on PyPI and NVIDIA PyPI, or add the missing publication
workflow/release-caller step that uploads them. Ensure the post-release registry
checks remain only after a concrete publication process is defined.
- Around line 282-285: Extend the release procedure after the “Generate release
notes” step to instruct reviewing the generated title and body, then selecting
“Publish release.” Add a verifiable success criterion confirming that the GitHub
release entry is created and visible for the selected tag.
🪄 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: 7e9529ab-9e89-42df-b243-bc9079263937
📒 Files selected for processing (1)
RELEASING.md
📜 Review details
⏰ Context from checks skipped due to timeout. (5)
- GitHub Check: Test (Python 3.12, windows-amd64)
- GitHub Check: Test (Python 3.11, windows-amd64)
- GitHub Check: Test (Python 3.13, windows-amd64)
- GitHub Check: Test (Python 3.14, windows-amd64)
- GitHub Check: Pre-commit
🧰 Additional context used
📓 Path-based instructions (11)
**/*.{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:
RELEASING.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 spellNVIDIAin all caps; do not useNvidia,nvidia,nVidia,nVIDIA, orNV.
Usean NVIDIAbefore a noun, because the name begins with an “en” sound.
Do not add a registered trademark symbol afterNVIDIAwhen 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 withNVIDIAon 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:
RELEASING.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 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:
RELEASING.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.
Usecanfor possibility and reservemayfor permission; useafterfor temporal order; userefer tofor cross-references; prefer short direct sentences and specific verbs; avoid unnecessarypleasein 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: usefor exampleorsuch asinstead ofe.g.,and so oninstead ofetc.,that isinstead ofi.e.,compared toinstead ofvs., andby,through, orusinginstead ofvia. Use industry-standard terms such as in silico, in vitro, and in vivo when appropriate, and italicize them in running text.
Usethatwithout commas for essential clauses, andwhichwith commas for nonessential clauses.
Format dates and times clearly: spell out months in body text; use forms such asJune 12, 2025; avoid numeric or ordinal dates; capitalize days; use 12-hour time when appropriate; include a space beforea.m.orp.m.; useETandPTfor needed time zones; avoid24/7; and preferfrom 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:
RELEASING.md
**/*.{md,mdx,yml,py,rs,sh}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/SKILL.md)
Keep documentation aligned with current NeMo Fabric behavior, repository layout, entry points, commands, package names, APIs, bindings, and support claims.
Files:
RELEASING.md
**/*.{md,mdx}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/SKILL.md)
**/*.{md,mdx}: Use the full product nameNVIDIA NeMo Fabricon first use, typically in the title and H1; useNeMo Fabricthereafter. Usefabricalone only for the CLI tool and surround it with backticks.
Treat incorrect or stale commands, package names, paths, APIs, support claims, procedures, examples, terminology, or public behavior documentation as blocking issues.
CapitalizeNVIDIAcorrectly and format code, commands, paths, and filenames as inline code where needed.
Use title case for technical-documentation headings.
Introduce code blocks, tables, and lists with complete lead-in sentences; ensure examples match current APIs and build commands.
Use descriptive anchor text, avoid raw URLs and generic labels such ashere, and use repository-relative.mdxpaths for links withindocs/.
Prefer active voice, present tense, short sentences, plain English, consistent terminology, and imperative, parallel, scannable procedures.
Useafterinstead ofoncewhen expressing temporal sequence, and usecanrather thanmaywhen describing 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.
When reporting documentation-review findings, lead withMust fix,Should fix, andNice to havecategories; include file path, line reference, current problem, rationale, and a concrete rewrite or direction.
**/*.{md,mdx}: Prefer the documented public API over internal shortcuts in documentation and examples.
Keep release-process and release-history policy inRELEASING.md; do not duplicate it in user-facing documentation orCHANGELOG.md.
Update relevant getting-started, reference, adapter, and example README documentation when corresponding examples or adapters change.
Ensure example commands match current package names and paths.
Files:
RELEASING.md
**/*.md
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Update relevant SDK, API reference, adapter, example, integration, and support documentation when the corresponding public surface changes.
Files:
RELEASING.md
**/*.{html,md}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
HTML and Markdown files must use the specified SPDX HTML-comment header.
Files:
RELEASING.md
**/*.{md,mdx,yml,yaml}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
**/*.{md,mdx,yml,yaml}: Keep package names, repository references, and build commands current.
Update entry-point documentation when examples or reading paths change, includingREADME.mdordocs/index.ymlwhen applicable.
Files:
RELEASING.md
RELEASING.md
📄 CodeRabbit inference engine (.agents/skills/maintain-packaging/SKILL.md)
Reflect public packaging changes, release tags, registry publication, and current install/import/build commands in release-facing documentation.
Keep release policy and the end-to-end maintainer workflow in RELEASING.md.
Files:
RELEASING.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 lowercasefabricCLI command, package/import/crate names, code identifiers, API symbols, configuration keys, file paths, or unrelated generic uses of the word.
Files:
RELEASING.md
🧠 Learnings (1)
📓 Common learnings
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:24:44.826Z
Learning: Keep consumer-facing integration guidance in the top-level `skills/` directory and out of the maintainer skill set.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:24:49.603Z
Learning: Run `just docs` when the documentation site changes.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:25:12.247Z
Learning: Use `karpathy-guidelines` alongside this guidance; keep changes scoped, surface assumptions, and define focused validation before editing.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:25:12.247Z
Learning: Prefer the standard library, an existing dependency, or a small local implementation when that keeps behavior clear and maintainable.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:25:12.247Z
Learning: For every new dependency, record the functional need, alternatives considered, why the dependency is the narrowest fit, and any unresolved licensing question.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:25:12.247Z
Learning: Ensure generated artifacts land where downstream consumers expect, and keep package names, import paths, module names, documentation, examples, CI references, and versions internally consistent.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:25:19.271Z
Learning: Prompt for `<next-version>` when it is not provided; this is the version that `main` uses after the release branch is cut.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:25:19.271Z
Learning: Create the release branch from the latest `upstream/main`, push it to `upstream`, and verify an existing branch points to the expected commit before continuing.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:25:19.271Z
Learning: Create the code-freeze PR branch from the latest `upstream/main`.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:25:19.271Z
Learning: Run `just build-all`, `just wheels`, `just --fmt --check`, the old-version documentation search, and `git diff --check` as targeted code-freeze validation.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:25:19.271Z
Learning: The code-freeze PR must mention the new release branch, nightly alpha branch configuration update, version bump, documentation updates or intentional leftovers, and that release-bound PRs now target the new `release/*` branch.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:25:19.271Z
Learning: Do not create release tags during code freeze; only create the release branch and main PR.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:25:19.271Z
Learning: Do not target the code-freeze PR at the release branch; target `main`.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:25:19.271Z
Learning: Do not leave uncommitted user changes mixed into the code-freeze PR branch.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:25:30.771Z
Learning: Name branches after the work, never the Linear ticket, and do not embed ticket IDs or slugs in branch names.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:25:30.771Z
Learning: Use signed-off commits for pull-request work with git commit -s.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:25:30.771Z
Learning: When creating a pull request from the current branch, target the upstream repository rather than a fork.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:25:30.771Z
Learning: If repository-local PR guidance conflicts with generic GitHub connector or plugin guidance, follow the repository-local guidance for PR body format and review handoff details.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:25:30.771Z
Learning: PR descriptions must include what changed, why, how it was tested, and any breaking changes within the repository template format.
🔇 Additional comments (1)
RELEASING.md (1)
282-285: Should fix — Format GitHub controls as UI labels.
RELEASING.md#L282-L285still places control names in quotation marks. Format Releases, Tags, Create release from tag, and Generate release notes in bold.This duplicates the previous review finding, which remains unresolved.
Source: Coding guidelines
There was a problem hiding this comment.
Actionable comments posted: 9
🤖 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 @.agents/skills/draft-release-notes/scripts/collect_release_evidence.py:
- Around line 154-157: Update the print_note_tree calls in the evidence
collection flow to pass previous_sha and current_sha instead of args.previous
and args.current, ensuring the release-notes trees use the same resolved commit
IDs as commits().
- Around line 136-148: Validate args.version as a strict major.minor value
before the evidence heading is generated, rejecting arbitrary text and malformed
versions through parser.error. Update the argument handling around
collect_release_evidence.py’s parser setup and preserve the validated version
for the existing “# Release-Note Evidence” output.
- Around line 69-70: Update the path collection in the release-evidence flow
around run_git to preserve every changed path for renames: invoke Git with
--no-renames and --name-only, then build paths from each non-empty output line
without splitting on tabs. Keep the existing repository and commit selection
unchanged.
In @.agents/skills/draft-release-notes/SKILL.md:
- Line 3: Update the description metadata in the draft-release-notes skill to
use “NVIDIA NeMo Fabric” for the first product-name reference, while retaining
“NeMo Fabric” for subsequent references.
- Around line 1-6: Add the repository-standard SPDX copyright and Apache-2.0
HTML comment immediately after the closing front-matter delimiter in SKILL.md,
preserving the existing YAML front matter unchanged and valid.
- Around line 24-26: Update the report capability description in the
release-notes skill to match collect_release_evidence.py: describe inspecting
both refs, listing release-note paths, and extracting version text, but remove
the claim that it compares release-notes pages unless the collector is extended
to generate that comparison.
In @.agents/skills/prepare-code-freeze/SKILL.md:
- Around line 21-25: Add a clean-worktree precondition before the branching and
version-update steps in the prepare-code-freeze workflow: run git status
--porcelain, proceed only when it is empty, and stop with a clear message
otherwise. Ensure this check occurs before fetching, creating the release
branch, or invoking just set-version.
In `@RELEASING.md`:
- Around line 249-250: Update the workflow-table lead-in in RELEASING.md from
“Pushing a valid tag triggers :” to “Pushing a valid tag triggers the workflows
below:”, removing the extra space and specifying the triggered object.
- Around line 177-184: Update the release-candidate tag references in the
documented git tag, git tag listing, git show, and git push commands to use the
`-rc.${RC_NUM}` suffix with a dot, consistently preserving the documented
`v<version>-rc.<number>` format.
🪄 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: 2fa2b1f4-9ee6-4327-8400-7d54318f943d
📒 Files selected for processing (9)
.agents/skills/README.md.agents/skills/contribute-docs/SKILL.md.agents/skills/draft-release-notes/SKILL.md.agents/skills/draft-release-notes/scripts/collect_release_evidence.py.agents/skills/maintain-ci/SKILL.md.agents/skills/maintain-packaging/SKILL.md.agents/skills/prepare-code-freeze/SKILL.mdAGENTS.mdRELEASING.md
📜 Review details
🧰 Additional context used
📓 Path-based instructions (16)
.agents/skills/**
📄 CodeRabbit inference engine (.agents/skills/README.md)
Coding agents discover maintainer skills from
.agents/skills/.
.agents/skills/**: Keep maintainer skills under.agents/skills/; they may reference repository internals and contribution commands.
Do not add consumer integration guidance to the maintainer skill set.
Files:
.agents/skills/README.md.agents/skills/maintain-packaging/SKILL.md.agents/skills/maintain-ci/SKILL.md.agents/skills/contribute-docs/SKILL.md.agents/skills/prepare-code-freeze/SKILL.md.agents/skills/draft-release-notes/SKILL.md.agents/skills/draft-release-notes/scripts/collect_release_evidence.py
.agents/skills/maintain-packaging/SKILL.md
📄 CodeRabbit inference engine (AGENTS.md)
Keep packaging implementation guidance in
.agents/skills/maintain-packaging/SKILL.md.
Files:
.agents/skills/maintain-packaging/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:
AGENTS.mdRELEASING.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 spellNVIDIAin all caps; do not useNvidia,nvidia,nVidia,nVIDIA, orNV.
Usean NVIDIAbefore a noun, because the name begins with an “en” sound.
Do not add a registered trademark symbol afterNVIDIAwhen 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 withNVIDIAon 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:
AGENTS.mdRELEASING.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 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:
AGENTS.mdRELEASING.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.
Usecanfor possibility and reservemayfor permission; useafterfor temporal order; userefer tofor cross-references; prefer short direct sentences and specific verbs; avoid unnecessarypleasein 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: usefor exampleorsuch asinstead ofe.g.,and so oninstead ofetc.,that isinstead ofi.e.,compared toinstead ofvs., andby,through, orusinginstead ofvia. Use industry-standard terms such as in silico, in vitro, and in vivo when appropriate, and italicize them in running text.
Usethatwithout commas for essential clauses, andwhichwith commas for nonessential clauses.
Format dates and times clearly: spell out months in body text; use forms such asJune 12, 2025; avoid numeric or ordinal dates; capitalize days; use 12-hour time when appropriate; include a space beforea.m.orp.m.; useETandPTfor needed time zones; avoid24/7; and preferfrom 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:
AGENTS.mdRELEASING.md
**/AGENTS.md
📄 CodeRabbit inference engine (CLAUDE.md)
Follow the instructions documented in
AGENTS.mdwhen working in the repository.
Files:
AGENTS.md
**/*.{md,mdx,yml,py,rs,sh}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/SKILL.md)
Keep documentation aligned with current NeMo Fabric behavior, repository layout, entry points, commands, package names, APIs, bindings, and support claims.
Files:
AGENTS.mdRELEASING.md
**/*.{md,mdx}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/SKILL.md)
**/*.{md,mdx}: Use the full product nameNVIDIA NeMo Fabricon first use, typically in the title and H1; useNeMo Fabricthereafter. Usefabricalone only for the CLI tool and surround it with backticks.
Treat incorrect or stale commands, package names, paths, APIs, support claims, procedures, examples, terminology, or public behavior documentation as blocking issues.
CapitalizeNVIDIAcorrectly and format code, commands, paths, and filenames as inline code where needed.
Use title case for technical-documentation headings.
Introduce code blocks, tables, and lists with complete lead-in sentences; ensure examples match current APIs and build commands.
Use descriptive anchor text, avoid raw URLs and generic labels such ashere, and use repository-relative.mdxpaths for links withindocs/.
Prefer active voice, present tense, short sentences, plain English, consistent terminology, and imperative, parallel, scannable procedures.
Useafterinstead ofoncewhen expressing temporal sequence, and usecanrather thanmaywhen describing 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.
When reporting documentation-review findings, lead withMust fix,Should fix, andNice to havecategories; include file path, line reference, current problem, rationale, and a concrete rewrite or direction.
**/*.{md,mdx}: Prefer documented public APIs over internal shortcuts in documentation and examples.
Keep release-process and release-history policy inRELEASING.md, rather than duplicating it in user-facing documentation or aCHANGELOG.md.
**/*.{md,mdx}: Verify every release-note claim against changed public documentation, API types, command help, or source before including it.
Prioritize breaking changes, migrations, user-visible features, and ongoing support limitations in the curated...
Files:
AGENTS.mdRELEASING.md
**/*.md
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Update relevant SDK, API reference, adapter, example, integration, and support documentation when the corresponding public surface changes.
Files:
AGENTS.mdRELEASING.md
**/*.{html,md}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
HTML and Markdown files must use the specified SPDX HTML-comment header.
Files:
AGENTS.mdRELEASING.md
**/*.{md,mdx,yml,yaml}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Keep package names, repository references, and build commands current.
Files:
AGENTS.mdRELEASING.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.
For links between files under docs/, require paths relative to the source file with the target file's .mdx extension so they work in both Fern builds and repository browsers. Flag Fern site-root links such as NeMo Fabric overview; use the repository-relative equivalent, such as NeMo Fabric overview.
Files:
AGENTS.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 lowercasefabricCLI command, package/import/crate names, code identifiers, API symbols, configuration keys, file paths, or unrelated generic uses of the word.
Files:
AGENTS.mdRELEASING.md
{docs/**/*,.github/workflows/**/*,justfile,RELEASING.md}
📄 CodeRabbit inference engine (.agents/skills/maintain-packaging/SKILL.md)
Keep documentation, examples, CI, local recipes, and release-facing material aligned with current install, import, build, and package names.
Files:
RELEASING.md
RELEASING.md
📄 CodeRabbit inference engine (AGENTS.md)
Keep release policy and the end-to-end maintainer workflow in
RELEASING.md.
Files:
RELEASING.md
🧠 Learnings (1)
📓 Common learnings
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:28:54.782Z
Learning: Confirm the target release version from the release branch and package metadata.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:28:54.782Z
Learning: Run `collect_release_evidence.py` with explicit previous and current release refs and the target minor version before drafting release notes.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:28:54.782Z
Learning: Treat the helper's commit groups as an evidence index, not publication-ready copy.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:28:54.782Z
Learning: Preserve unrelated working-tree changes while preparing release notes.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:28:54.782Z
Learning: Run `git diff --check` and `just docs`, and verify product names, commands, package names, support claims, and links against the current repository before handoff.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:29:01.669Z
Learning: Keep CI changes scoped, surface assumptions, and define focused validation before editing.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:29:01.669Z
Learning: When GitHub authorization is uncertain, inspect GitHub's permission model and the upstream action or reusable-workflow source rather than treating local lint success as proof of remote correctness.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:29:10.433Z
Learning: Prefer the standard library, an existing dependency, or a small local implementation when that keeps behavior clear and maintainable.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:29:10.433Z
Learning: When multiple dependencies satisfy the requirement, prefer a maintained OSS option with clear SPDX metadata, a smaller transitive graph, and permissive licensing terms.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:29:10.433Z
Learning: Inspect resolved transitive dependency graphs, not only direct package licenses.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:29:10.433Z
Learning: Treat UNKNOWN, non-SPDX/custom, proprietary, source-available, copyleft, and network-copyleft terms as explicit review points; route them to dependency approvers with distribution and linkage context.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:29:10.433Z
Learning: Record the functional need, viable alternatives considered, why the selected dependency is the narrowest fit, and unresolved licensing questions.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:29:10.433Z
Learning: New dependencies must be necessary, maintained, and narrower than viable alternatives.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:29:10.433Z
Learning: Call out licensing uncertainties for dependency approver review.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:29:10.433Z
Learning: Include regenerated attribution files when they change.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:29:15.563Z
Learning: Derive the release branch name as `release/<major>.<minor>` from the target release version.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:29:15.563Z
Learning: Create the release branch from the latest `upstream/main`, and verify an existing remote release branch points where expected before continuing.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:29:15.563Z
Learning: Prompt for `<next-version>` when it is not provided; this is the version that `main` adopts after the release branch is cut.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:29:15.563Z
Learning: Create the code-freeze PR branch from the latest `upstream/main`.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:29:15.563Z
Learning: Run `just set-version <next-version>` to bump all release-versioned package surfaces on `main`.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:29:15.563Z
Learning: Validate the freeze with `cargo check --workspace --locked`, `just build-all`, `just wheels`, `just --fmt --check`, a search for remaining old-version references, and `git diff --check`.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:29:15.563Z
Learning: The code-freeze PR must target `main`, not the release branch, and must mention the new release branch, nightly alpha branch configuration update, version bump, documentation reference updates or intentional leftovers, and that release-bound PRs now target the new `release/*` branch.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:29:15.563Z
Learning: Do not create release tags during code freeze; create only the release branch and main PR.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:29:15.563Z
Learning: Do not leave uncommitted user changes mixed into the code-freeze PR branch.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:29:23.663Z
Learning: Use branch prefixes `feat/`, `fix/`, `docs/`, `test/`, or `refactor/`; name branches after the work and never include Linear ticket IDs or slugs.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:29:23.663Z
Learning: Use Conventional Commit PR titles in the form `<type>: <summary>`; reserve `fix` for actual product bugs, not CI, documentation, or chores.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:29:23.663Z
Learning: Use signed-off commits for pull-request work with `git commit -s`.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:29:23.663Z
Learning: When creating a pull request from the current branch, target the upstream repository rather than a fork.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:29:23.663Z
Learning: If repository-local PR guidance conflicts with generic GitHub connector or plugin guidance, follow the repository-local guidance for PR body format and review handoff details.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:29:23.663Z
Learning: PR descriptions must include what changed, why, how it was tested, and any breaking changes within the repository template format.
🪛 ast-grep (0.45.0)
.agents/skills/draft-release-notes/scripts/collect_release_evidence.py
[warning] 58-58: XPath query is request-/variable-derived; use parameterized XPath to prevent injection.
Context: VERSION_PATTERN.findall(content)
Note: [CWE-643] Improper Neutralization of Data within XPath Expressions ('XPath Injection').
(xpath-injection-python)
[error] 29-35: Command coming from incoming request
Context: subprocess.run(
["git", *args],
cwd=repo,
check=False,
capture_output=True,
encoding="utf-8",
)
Note: [CWE-78] Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection').
(subprocess-from-request)
🪛 LanguageTool
.agents/skills/prepare-code-freeze/SKILL.md
[uncategorized] ~66-~66: The official name of this software platform is spelled with a capital “H”.
Context: ...on. 8. Open a PR targeting main using .github/pull_request_template.md. The PR mu...
(GITHUB)
RELEASING.md
[uncategorized] ~253-~253: The official name of this software platform is spelled with a capital “H”.
Context: ...s : | Workflow | Trigger | |---|---| | [.github/workflows/ci_python.yml](.github/workf...
(GITHUB)
[uncategorized] ~254-~254: The official name of this software platform is spelled with a capital “H”.
Context: ...yml) | For all tags including alpha | | [.github/workflows/publish_rust.yml](.github/wo...
(GITHUB)
[uncategorized] ~255-~255: The official name of this software platform is spelled with a capital “H”.
Context: ...ml) | For RC, beta and release tags | | [.github/workflows/fern-docs.yml](.github/workf...
(GITHUB)
🪛 Ruff (0.16.0)
.agents/skills/draft-release-notes/scripts/collect_release_evidence.py
[error] 30-30: subprocess call: check for execution of untrusted input
(S603)
[error] 31-31: Starting a process with a partial executable path
(S607)
[warning] 39-39: Avoid specifying long messages outside the exception class
(TRY003)
🔇 Additional comments (21)
.agents/skills/draft-release-notes/scripts/collect_release_evidence.py (1)
142-145: Duplicate — Allow divergent release branches.Line 144 retains the ancestor restriction. It rejects valid release branches that diverged after code freeze. The previous review already provides the required correction.
Source: Learnings
RELEASING.md (7)
56-60: Duplicate — Document all supported prerelease tag forms.The section still lists only
v0.1.0-rc.1. Document the supported alpha, beta, and RC forms and keep the publication behavior consistent with CI.
171-176: Duplicate — Use fast-forward-only pulls before tagging.Replace both
git pullcommands withgit pull --ff-only, then verify that the checked-out commit is the intended release commit before each tag command.Also applies to: 231-235
280-285: Duplicate — Publish the GitHub Release entry.After generating the notes, review the title and body and select Publish release. The current procedure stops before creating the GitHub Release entry.
289-307: Duplicate — Verify the current release version.Require
${RELEASE_VERSION}fornemo-fabric-core,nemo-fabric-cli, and every listed Python distribution on both indexes. Retain the platform-wheel checks.
257-277: Duplicate — Define the Python publication process.The document describes GitHub Actions wheel artifacts but does not define the owner or trigger that publishes the seven Python distributions to PyPI and NVIDIA PyPI. Add that process or remove these registry checks until publication is defined.
Also applies to: 289-307
194-202: 🗄️ Data Integrity & IntegrationUse an explicit current release ref for evidence collection.
--current HEADdepends on the active checkout and can include unrelated commits. Pass the exact release branch, tag, or commit that matches the target package metadata.Based on learnings, run
collect_release_evidence.pywith explicit previous and current release refs before drafting release notes.Source: Learnings
1-55: LGTM!Also applies to: 61-160, 185-193, 203-218, 220-230, 236-246, 251-256, 286-288, 308-310
.agents/skills/prepare-code-freeze/SKILL.md (5)
1-6: Duplicate — Add the SPDX Markdown header.Keep the YAML frontmatter first, then add the repository copyright and Apache-2.0 HTML-comment header after Line 6.
As per coding guidelines, Markdown files must use the specified SPDX HTML-comment header.
Source: Coding guidelines
2-3: Duplicate — Use the full product name on first use.Change the first
NeMo Fabricreference in the description toNVIDIA NeMo Fabric. UseNeMo Fabricafterward.As per coding guidelines, Markdown documentation must use the full product name on first use.
Source: Coding guidelines
35-38: Duplicate — Create and switch to the code-freeze PR branch.Step 4 only gives a branch name. Add the checkout command from
upstream/mainbefore Step 5 runsjust set-version. Otherwise, the version bump can modify the wrong branch.
66-72: 🗄️ Data Integrity & IntegrationMake the nightly alpha configuration step explicit.
The workflow requires the PR to mention a nightly alpha branch configuration update, but it does not define how to decide whether the update is required, which configuration to change, or how to validate it. Add a concrete check or delegate the step to
maintain-ciwith an explicit success criterion.Based on learnings, the code-freeze workflow must decide whether frozen-line nightly alpha tags are required.
Source: Learnings
7-20: LGTM!Also applies to: 26-34, 39-65
AGENTS.md (1)
51-51: LGTM!.agents/skills/README.md (1)
41-42: LGTM!.agents/skills/contribute-docs/SKILL.md (2)
24-25: LGTM!
43-43: LGTM!.agents/skills/maintain-ci/SKILL.md (2)
37-38: LGTM!
94-97: LGTM!.agents/skills/maintain-packaging/SKILL.md (2)
31-32: LGTM!
92-92: LGTM!
Signed-off-by: David Gardner <dagardner@nvidia.com>
|
Fern docs preview: https://nvidia-preview-pull-request-172.docs.buildwithfern.com/nemo/fabric |
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 `@CONTRIBUTING.md`:
- Around line 76-80: Align the release-tag examples in the SemVer guidance with
the executable contract in justfile by using unprefixed values such as 0.1.0 and
0.1.0-rc.1, and update the prohibition accordingly. Keep the guidance consistent
with the tags accepted by the release commands.
🪄 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: 58c5dba0-84c0-4938-a647-b8e8b5566bd2
📒 Files selected for processing (1)
CONTRIBUTING.md
📜 Review details
⏰ Context from checks skipped due to timeout. (7)
- GitHub Check: Preview docs
- GitHub Check: Test (Python 3.11, windows-amd64)
- GitHub Check: Test (Python 3.13, windows-amd64)
- GitHub Check: Test (Python 3.14, windows-amd64)
- GitHub Check: Pre-commit
- GitHub Check: Test (Python 3.12, windows-amd64)
- GitHub Check: Test (Python 3.13, macos-arm64)
🧰 Additional context used
📓 Path-based instructions (10)
**/*.{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:
CONTRIBUTING.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 spellNVIDIAin all caps; do not useNvidia,nvidia,nVidia,nVIDIA, orNV.
Usean NVIDIAbefore a noun, because the name begins with an “en” sound.
Do not add a registered trademark symbol afterNVIDIAwhen 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 withNVIDIAon 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:
CONTRIBUTING.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 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:
CONTRIBUTING.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.
Usecanfor possibility and reservemayfor permission; useafterfor temporal order; userefer tofor cross-references; prefer short direct sentences and specific verbs; avoid unnecessarypleasein 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: usefor exampleorsuch asinstead ofe.g.,and so oninstead ofetc.,that isinstead ofi.e.,compared toinstead ofvs., andby,through, orusinginstead ofvia. Use industry-standard terms such as in silico, in vitro, and in vivo when appropriate, and italicize them in running text.
Usethatwithout commas for essential clauses, andwhichwith commas for nonessential clauses.
Format dates and times clearly: spell out months in body text; use forms such asJune 12, 2025; avoid numeric or ordinal dates; capitalize days; use 12-hour time when appropriate; include a space beforea.m.orp.m.; useETandPTfor needed time zones; avoid24/7; and preferfrom 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:
CONTRIBUTING.md
**/*.{md,mdx,yml,py,rs,sh}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/SKILL.md)
Keep documentation aligned with current NeMo Fabric behavior, repository layout, entry points, commands, package names, APIs, bindings, and support claims.
Files:
CONTRIBUTING.md
**/*.{md,mdx}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/SKILL.md)
**/*.{md,mdx}: Use the full product nameNVIDIA NeMo Fabricon first use, typically in the title and H1; useNeMo Fabricthereafter. Usefabricalone only for the CLI tool and surround it with backticks.
Treat incorrect or stale commands, package names, paths, APIs, support claims, procedures, examples, terminology, or public behavior documentation as blocking issues.
CapitalizeNVIDIAcorrectly and format code, commands, paths, and filenames as inline code where needed.
Use title case for technical-documentation headings.
Introduce code blocks, tables, and lists with complete lead-in sentences; ensure examples match current APIs and build commands.
Use descriptive anchor text, avoid raw URLs and generic labels such ashere, and use repository-relative.mdxpaths for links withindocs/.
Prefer active voice, present tense, short sentences, plain English, consistent terminology, and imperative, parallel, scannable procedures.
Useafterinstead ofoncewhen expressing temporal sequence, and usecanrather thanmaywhen describing 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.
When reporting documentation-review findings, lead withMust fix,Should fix, andNice to havecategories; include file path, line reference, current problem, rationale, and a concrete rewrite or direction.Documentation and public text should follow NVIDIA technical-writing style.
**/*.{md,mdx}: Prefer documented public APIs over internal shortcuts in documentation and examples.
Update relevant getting-started, reference, example, and adapter README documentation when corresponding examples or adapters change.
Runjust docswhen the documentation site changes.For documentation-site changes, run
just docsto regenerate Python and Rust API references and validate the Fern configuration.
Files:
CONTRIBUTING.md
**/*.{md,mdx,yml}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Keep package names, repository references, and build commands current.
Files:
CONTRIBUTING.md
**/{README.md,*.md,*.mdx}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
If a change affects public behavior, adapters, examples, or workspace structure, update the corresponding documentation in the same branch.
Files:
CONTRIBUTING.md
**/*.md
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Markdown files must include the specified SPDX copyright and Apache-2.0 license header using an HTML comment.
Files:
CONTRIBUTING.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 lowercasefabricCLI command, package/import/crate names, code identifiers, API symbols, configuration keys, file paths, or unrelated generic uses of the word.
Files:
CONTRIBUTING.md
🧠 Learnings (1)
📓 Common learnings
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:40:23.388Z
Learning: Changes to public API surfaces must maintain parity across Rust, CLI, Python, schema, adapters, and documentation.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:40:23.388Z
Learning: Production-ready harness adapters must include explicit capability, policy, packaging, lifecycle, and validation contracts.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:40:23.388Z
Learning: Small bug fixes should remain reviewable and avoid widening scope.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:40:23.388Z
Learning: Documentation and examples must be changed in step with public behavior.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:40:23.388Z
Learning: Choose and run the appropriate validation matrix for each change.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:40:23.388Z
Learning: Release versions must be bumped and synchronized across packaging surfaces.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:40:23.388Z
Learning: Prepare code freezes by creating a release branch, advancing `main`, and preparing the code-freeze pull request.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:40:23.388Z
Learning: Draft documentation release notes from verified repository evidence.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:40:23.388Z
Learning: Prepare, open, or edit pull requests with the appropriate scope and review handoff.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:40:28.187Z
Learning: Keep documentation and example changes scoped, surface assumptions, and define focused validation before editing.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:40:35.674Z
Learning: Preserve unrelated working-tree changes while preparing release notes.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:40:35.674Z
Learning: Keep complete PR-by-PR release history in GitHub Releases rather than duplicating it in the documentation release-notes page.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:40:42.727Z
Learning: Keep changes scoped, surface assumptions, and define focused validation before editing.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:40:53.968Z
Learning: For each new dependency, record the functional need, viable alternatives considered, why the selected dependency is the narrowest fit, and any unresolved licensing question.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:41:00.761Z
Learning: Prompt for `<next-version>` when it is not provided; this is the version that `main` adopts after the release branch is cut.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:41:00.761Z
Learning: Fetch the latest `upstream/main`, create `release/<major>.<minor>` from it, and push the branch to `upstream`; if it already exists, verify that it points to the expected commit.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:41:00.761Z
Learning: Create the code-freeze PR branch from the latest `upstream/main`.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:41:00.761Z
Learning: Run `just set-version <next-version>` to bump all release-versioned package surfaces on `main`.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:41:00.761Z
Learning: Validate the freeze with `cargo check --workspace --locked`, `just build-all`, `just wheels`, `just --fmt --check`, an old-version documentation search, and `git diff --check`; document any intentional remaining old-version references in the PR.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:41:00.761Z
Learning: The code-freeze PR must mention the new release branch, nightly alpha branch configuration update, version bump, documentation updates or intentional leftovers, and that release-bound PRs target the new `release/*` branch.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:41:00.761Z
Learning: Do not create release tags during code freeze; code freeze creates only the release branch and the main PR.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:41:00.761Z
Learning: Do not target the code-freeze PR at the release branch; target `main`.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:41:00.761Z
Learning: Do not leave uncommitted user changes mixed into the code-freeze PR branch.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:41:08.895Z
Learning: Keep consumer skills under `skills/` separate from maintainer skills under `.agents/skills/`; do not mix consumer integration guidance with repository-internal contribution steps.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:41:08.895Z
Learning: Use branch prefixes `feat/`, `fix/`, `docs/`, `test/`, or `refactor/`; name branches after the work and never include Linear ticket IDs or slugs.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:41:08.895Z
Learning: Use Conventional Commit PR titles in the form `<type>: <summary>`; reserve `fix` for actual product bugs, not CI, documentation, or chores.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:41:08.895Z
Learning: Use signed-off commits for pull request work with `git commit -s`.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:41:08.895Z
Learning: When creating a pull request from the current branch, target the upstream repository rather than a fork.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:41:08.895Z
Learning: PR descriptions must include what changed, why, how it was tested, and any breaking changes within the repository template format.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:41:08.895Z
Learning: If repository-local PR guidance conflicts with generic GitHub connector or plugin guidance, follow the repository-local guidance for PR body format and review handoff details.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:41:16.897Z
Learning: Before submitting a pull request, run relevant tests, verify affected packages compile, update documentation, and rebase on the latest `main`.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:41:16.897Z
Learning: All pull requests require at least one approving review, and CI must pass before merging.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:41:16.897Z
Learning: During review, address feedback with additional commits and do not force-push.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:41:16.897Z
Learning: Use commit messages in the format `type: short description`, using an approved type, with the first line under 72 characters.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-03T23:41:16.897Z
Learning: Release tags must use SemVer with a leading `v`, such as `v0.1.0` or `v0.1.0-rc.1`; unprefixed tags are prohibited.
Signed-off-by: Anuradha Karuppiah <26330987+AnuradhaKaruppiah@users.noreply.github.com>
|
@coderabbitai review |
✅ Action performedReview finished.
|
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.agents/skills/draft-release-notes/SKILL.md (1)
62-70: 📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick winMust fix — Run the required documentation checks.
When
docs/about-nemo-fabric/release-notes.mdxchanges, this workflow must also usecontribute-docsandreview-doc-stylefor documentation-only changes. The current step runs onlyjust docs, so it does not apply the repository’s required documentation workflow. Add both skills and keepjust docsfor the docs-site build.As per coding guidelines, “For documentation-only changes, use
contribute-docsandreview-doc-style; runjust docsfor docs-site or generated-reference changes.”🤖 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 @.agents/skills/draft-release-notes/SKILL.md around lines 62 - 70, Update the Validate section of the release-notes workflow so changes to docs/about-nemo-fabric/release-notes.mdx invoke both contribute-docs and review-doc-style, while retaining just docs for docs-site or generated-reference validation.Source: Coding guidelines
♻️ Duplicate comments (3)
.agents/skills/draft-release-notes/scripts/collect_release_evidence.py (2)
146-147: 🗄️ Data Integrity & Integration | 🟠 MajorMust fix — Use resolved commit IDs for every evidence read.
These lines resolve
previous_shaandcurrent_sha, butprint_note_tree()still receivesargs.previousandargs.currentat Lines 158-159. A branch can move after ref resolution, causing the report to combine commit metadata from one revision with release-note contents from another. Pass the resolved IDs toprint_note_tree().Proposed fix
- print_note_tree(repo, "Previous", args.previous) - print_note_tree(repo, "Current", args.current) + print_note_tree(repo, "Previous", previous_sha) + print_note_tree(repo, "Current", current_sha)🤖 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 @.agents/skills/draft-release-notes/scripts/collect_release_evidence.py around lines 146 - 147, Update the print_note_tree() call to pass the resolved previous_sha and current_sha values instead of args.previous and args.current, ensuring all evidence reads use the same immutable commit IDs resolved by resolve_ref().
148-148: 🎯 Functional Correctness | 🟠 MajorMust fix — Accept valid divergent release refs.
--is-ancestorrejects comparisons between release lines that diverged after a code freeze. Resolve both refs, compute their merge base, and report it without requiringprevious_shato be an ancestor ofcurrent_sha. Keep merge-base errors inside the existingtryblock so unrelated histories still produce anargparseerror.Based on learnings, release branches are created from
upstream/mainand release-bound changes target the release branch; later release branches can diverge from earlier release branches.Proposed fix
previous_sha = resolve_ref(repo, args.previous) current_sha = resolve_ref(repo, args.current) - run_git(repo, "merge-base", "--is-ancestor", previous_sha, current_sha) + merge_base = run_git(repo, "merge-base", previous_sha, current_sha).strip() ... - print(f"- Merge base: `{run_git(repo, 'merge-base', previous_sha, current_sha).strip()[:12]}`") + print(f"- Merge base: `{merge_base[:12]}`")🤖 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 @.agents/skills/draft-release-notes/scripts/collect_release_evidence.py at line 148, Update the release-ref comparison around run_git so both previous_sha and current_sha are resolved, then compute and report their merge base without requiring previous_sha to be an ancestor of current_sha. Keep merge-base failures within the existing try block so unrelated histories continue to surface as argparse errors.Source: Learnings
.agents/skills/draft-release-notes/SKILL.md (1)
3-6: 📐 Maintainability & Code Quality | 🟠 MajorMust fix — Add the required SPDX HTML-comment header.
The front matter declares
license: Apache-2.0, but the file has no SPDX HTML comment after the closing delimiter on Line 6. Add the repository-standard copyright and Apache-2.0 header without changing the front matter.As per coding guidelines, “Markdown files must include the specified SPDX copyright and Apache-2.0 license header using HTML comment syntax.”
Proposed fix
license: Apache-2.0 --- +<!-- SPDX-FileCopyrightText: Copyright (c) 2026, NVIDIA CORPORATION & AFFILIATES. All rights reserved. +SPDX-License-Identifier: Apache-2.0 --> + # Draft Release Notes🤖 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 @.agents/skills/draft-release-notes/SKILL.md around lines 3 - 6, Add the repository-standard SPDX copyright and Apache-2.0 license HTML comment immediately after the closing front-matter delimiter in SKILL.md, while preserving the existing front matter unchanged.Source: Coding guidelines
🤖 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 @.agents/skills/draft-release-notes/SKILL.md:
- Line 3: Update the front-matter description in the draft-release-notes skill
so the docs/about-nemo-fabric/release-notes.mdx path is wrapped in inline
backticks, while preserving the rest of the description unchanged.
In `@RELEASING.md`:
- Around line 188-201: Update the RC and stable release procedures before both
git tag commands to validate every release-versioned surface: Cargo.toml,
pyproject.toml, and the derived runtime metadata, ensuring each resolves to
RELEASE_VERSION. Keep the checks executable and aligned with the repository’s
current version-resolution behavior, while preserving the existing branch,
commit, and tag validations.
- Around line 203-206: Update both remote-tag checks in the release instructions
to capture the exit status from git ls-remote, continue only when Git returns
status 2 for no matching tag, and abort before creating the local tag for every
other nonzero status. Preserve the existing failure for an already-existing
remote tag.
---
Outside diff comments:
In @.agents/skills/draft-release-notes/SKILL.md:
- Around line 62-70: Update the Validate section of the release-notes workflow
so changes to docs/about-nemo-fabric/release-notes.mdx invoke both
contribute-docs and review-doc-style, while retaining just docs for docs-site or
generated-reference validation.
---
Duplicate comments:
In @.agents/skills/draft-release-notes/scripts/collect_release_evidence.py:
- Around line 146-147: Update the print_note_tree() call to pass the resolved
previous_sha and current_sha values instead of args.previous and args.current,
ensuring all evidence reads use the same immutable commit IDs resolved by
resolve_ref().
- Line 148: Update the release-ref comparison around run_git so both
previous_sha and current_sha are resolved, then compute and report their merge
base without requiring previous_sha to be an ancestor of current_sha. Keep
merge-base failures within the existing try block so unrelated histories
continue to surface as argparse errors.
In @.agents/skills/draft-release-notes/SKILL.md:
- Around line 3-6: Add the repository-standard SPDX copyright and Apache-2.0
license HTML comment immediately after the closing front-matter delimiter in
SKILL.md, while preserving the existing front matter unchanged.
🪄 Autofix
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: 38af1281-968a-4835-909f-daac86da9891
📒 Files selected for processing (5)
.agents/skills/README.md.agents/skills/draft-release-notes/SKILL.md.agents/skills/draft-release-notes/scripts/collect_release_evidence.pyCONTRIBUTING.mdRELEASING.md
📜 Review details
⏰ Context from checks skipped due to timeout. (4)
- GitHub Check: Test (Python 3.13, windows-amd64)
- GitHub Check: Test (Python 3.14, windows-amd64)
- GitHub Check: Test (Python 3.11, windows-amd64)
- GitHub Check: Test (Python 3.12, windows-amd64)
🧰 Additional context used
📓 Path-based instructions (14)
.agents/skills/**
📄 CodeRabbit inference engine (.agents/skills/README.md)
Coding agents must auto-discover the maintainer skill set from
.agents/skills/.Keep maintainer guidance for API, documentation, testing, CI, packaging, release, and PR preparation under
.agents/skills/; it may reference repository internals.
Files:
.agents/skills/README.md.agents/skills/draft-release-notes/SKILL.md.agents/skills/draft-release-notes/scripts/collect_release_evidence.py
**/*.{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:
CONTRIBUTING.mdRELEASING.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 spellNVIDIAin all caps; do not useNvidia,nvidia,nVidia,nVIDIA, orNV.
Usean NVIDIAbefore a noun, because the name begins with an “en” sound.
Do not add a registered trademark symbol afterNVIDIAwhen 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 withNVIDIAon 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:
CONTRIBUTING.mdRELEASING.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 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:
CONTRIBUTING.mdRELEASING.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.
Usecanfor possibility and reservemayfor permission; useafterfor temporal order; userefer tofor cross-references; prefer short direct sentences and specific verbs; avoid unnecessarypleasein 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: usefor exampleorsuch asinstead ofe.g.,and so oninstead ofetc.,that isinstead ofi.e.,compared toinstead ofvs., andby,through, orusinginstead ofvia. Use industry-standard terms such as in silico, in vitro, and in vivo when appropriate, and italicize them in running text.
Usethatwithout commas for essential clauses, andwhichwith commas for nonessential clauses.
Format dates and times clearly: spell out months in body text; use forms such asJune 12, 2025; avoid numeric or ordinal dates; capitalize days; use 12-hour time when appropriate; include a space beforea.m.orp.m.; useETandPTfor needed time zones; avoid24/7; and preferfrom 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:
CONTRIBUTING.mdRELEASING.md
**/*.{md,mdx,yml,py,rs,sh}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/SKILL.md)
Keep documentation aligned with current NeMo Fabric behavior, repository layout, entry points, commands, package names, APIs, bindings, and support claims.
Files:
CONTRIBUTING.mdRELEASING.md
**/*.{md,mdx}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/SKILL.md)
**/*.{md,mdx}: Use the full product nameNVIDIA NeMo Fabricon first use, typically in the title and H1; useNeMo Fabricthereafter. Usefabricalone only for the CLI tool and surround it with backticks.
Treat incorrect or stale commands, package names, paths, APIs, support claims, procedures, examples, terminology, or public behavior documentation as blocking issues.
CapitalizeNVIDIAcorrectly and format code, commands, paths, and filenames as inline code where needed.
Use title case for technical-documentation headings.
Introduce code blocks, tables, and lists with complete lead-in sentences; ensure examples match current APIs and build commands.
Use descriptive anchor text, avoid raw URLs and generic labels such ashere, and use repository-relative.mdxpaths for links withindocs/.
Prefer active voice, present tense, short sentences, plain English, consistent terminology, and imperative, parallel, scannable procedures.
Useafterinstead ofoncewhen expressing temporal sequence, and usecanrather thanmaywhen describing 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.
When reporting documentation-review findings, lead withMust fix,Should fix, andNice to havecategories; include file path, line reference, current problem, rationale, and a concrete rewrite or direction.
**/*.{md,mdx}: Keep release-process and release-history policy inRELEASING.md, not in user-facing documentation or a duplicateCHANGELOG.md.
Runjust docswhen the documentation site changes.For documentation-heavy changes, prefer small targeted commits that separate entry-point, reference, example, and maintenance updates.
Files:
CONTRIBUTING.mdRELEASING.md
**/*.{md,mdx,py}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Prefer the documented public API over internal shortcuts in documentation and examples.
Files:
CONTRIBUTING.mdRELEASING.md
**/*.{md,mdx,yml,yaml,py,sh}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Keep package names, repository references, and build or example commands current.
Files:
CONTRIBUTING.mdRELEASING.md
**/*.{md,mdx,yml,yaml}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Update entry-point documentation, including
README.mdordocs/index.yml, when examples or documentation reading paths change.
Files:
CONTRIBUTING.mdRELEASING.md
**/*.md
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Markdown files must include the specified SPDX copyright and Apache-2.0 license header using HTML comment syntax.
Files:
CONTRIBUTING.mdRELEASING.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 lowercasefabricCLI command, package/import/crate names, code identifiers, API symbols, configuration keys, file paths, or unrelated generic uses of the word.
Files:
CONTRIBUTING.mdRELEASING.md
RELEASING.md
📄 CodeRabbit inference engine (.agents/skills/maintain-packaging/SKILL.md)
Reflect public packaging changes, release tags, registry publication, and release-facing commands in
RELEASING.md.
Files:
RELEASING.md
{RELEASING.md,.agents/skills/maintain-packaging/SKILL.md,CHANGELOG.md}
📄 CodeRabbit inference engine (AGENTS.md)
Keep release policy and end-to-end maintainer workflow in
RELEASING.md, packaging implementation guidance in.agents/skills/maintain-packaging/SKILL.md, and do not add a duplicateCHANGELOG.mdor move release-history policy into user-facing docs.
Files:
RELEASING.md
🧠 Learnings (1)
📓 Common learnings
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-07T17:21:13.793Z
Learning: Maintainer skills should cover repository work including public API changes, Python tests, CI, packaging, releases, documentation, validation, and pull-request workflows.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-07T17:21:32.276Z
Learning: Keep changes scoped, surface assumptions, and define focused validation before editing.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-07T17:21:41.804Z
Learning: Prefer the standard library, an existing dependency, or a small local implementation when that keeps behavior clear and maintainable.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-07T17:21:41.804Z
Learning: When multiple dependencies satisfy a requirement, prefer a maintained OSS option with clear SPDX metadata, a smaller transitive graph, and permissive licensing such as Apache-2.0, MIT, BSD, or ISC.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-07T17:21:41.804Z
Learning: Inspect resolved transitive dependency graphs and licenses, not only direct package licenses.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-07T17:21:41.804Z
Learning: Treat `UNKNOWN`, non-SPDX/custom, proprietary or source-available, copyleft, and network-copyleft licenses as explicit review points; route them to dependency approvers with distribution and linkage context rather than silently accepting or rejecting them.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-07T17:21:41.804Z
Learning: Record the functional need, viable alternatives considered, why the selected dependency is the narrowest fit, and any unresolved licensing question.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-07T17:21:50.098Z
Learning: Fetch the latest `upstream/main` and create and push the release branch `release/<major>.<minor>` from it; if the branch already exists, verify its expected commit before continuing.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-07T17:21:50.098Z
Learning: Create the code-freeze PR branch from the latest `upstream/main`, and do not mix uncommitted user changes into it.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-07T17:21:50.098Z
Learning: Run `just set-version <next-version>` to bump all release-versioned package surfaces on `main`.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-07T17:21:50.098Z
Learning: Run the required validation checks: `just build-all`, `just wheels`, `just --fmt --check`, the old-version documentation search, and `git diff --check`.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-07T17:21:50.098Z
Learning: The code-freeze PR must target `main`, not the release branch, and must mention the new release branch, nightly alpha configuration update, version bump, documentation reference changes or intentional leftovers, and the new target for release-bound PRs.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-07T17:21:50.098Z
Learning: Do not create release tags during a code freeze; create only the release branch and the main code-freeze PR.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-07T17:21:50.098Z
Learning: Use `update-project-version` for version semantics, `maintain-ci` when nightly or release-branch automation changes, and `prepare-pr` before opening the PR.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-07T17:22:01.324Z
Learning: Use branch prefixes `feat/`, `fix/`, `docs/`, `test/`, or `refactor/`; name branches after the work rather than Linear ticket IDs or slugs.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-07T17:22:01.324Z
Learning: Use Conventional Commit PR titles in the form `<type>: <summary>`; reserve `fix` for actual product bugs, not CI, documentation, or chores.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-07T17:22:01.324Z
Learning: Use signed-off commits for pull-request work with `git commit -s`.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-07T17:22:01.324Z
Learning: When creating a pull request from the current branch, target the upstream repository rather than a fork.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-07T17:22:01.324Z
Learning: If repository-local PR guidance conflicts with generic GitHub connector or plugin guidance, follow the repository-local guidance for PR body format and review handoff details.
Learnt from: CR
Repo: NVIDIA/NeMo-Fabric
Timestamp: 2026-08-07T17:22:01.324Z
Learning: PR descriptions must state what changed, why it changed, how it was tested, and any breaking changes while preserving the repository template format.
🔇 Additional comments (9)
CONTRIBUTING.md (1)
76-80: Must fix — Document all supported prerelease tag forms.This section lists only
v0.1.0-rc.1as a prerelease. The repository also supports-alpha.<number>and-beta.<number>tags. Alpha tags trigger only the Python workflow. Beta and RC tags also trigger Rust and Fern publication workflows.Add all supported forms and their workflow boundaries, or refer to the canonical guidance in
RELEASING.md.As per coding guidelines, release-tag guidance must remain aligned with current repository behavior.
Source: Coding guidelines
RELEASING.md (1)
97-119: LGTM!Also applies to: 182-187, 208-217, 221-263, 265-285, 294-303, 340-352
.agents/skills/README.md (1)
41-42: LGTM!.agents/skills/draft-release-notes/scripts/collect_release_evidence.py (2)
69-70: 🗄️ Data Integrity & IntegrationVerify rename path handling.
The supplied snippet does not include this implementation. If the collector still parses
git --name-statusby keeping only the last tab-separated field, a rename from a public path to a non-public path drops the old path from the public-surface report. Preserve both endpoints, or use--no-renames --name-only.#!/bin/bash set -euo pipefail file=.agents/skills/draft-release-notes/scripts/collect_release_evidence.py sed -n '28,72p' "$file" rg -n -C 5 -- 'diff-tree|name-status|name-only|split' "$file"
134-139: LGTM!.agents/skills/draft-release-notes/SKILL.md (4)
8-12: LGTM!
14-30: LGTM!
32-60: LGTM!
72-73: LGTM!
|
/merge |
3 participants
Overview
prepare-code-freezeanddraft-release-notesskills from Relay.RELEASING.mddocument from RelayWhere should the reviewer start?
.agents/skills/prepare-code-freeze/SKILL.md.agents/skills/draft-release-notes/SKILL.mdRelated Issues: (use one of the action keywords Closes / Fixes / Resolves / Relates to)
Closes FABRIC-159
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
Documentation
vprefix for release tags.