docs: require issues before contribution PRs

[willkill07]

Overview

Require contributors to open or identify an issue before submitting enhancement or bug-fix pull requests. External contributors should use GitHub issues; NVIDIA contributors may use GitHub or Linear issues.

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

Details

• Updated the root contribution guide and docs-site workflow guide with the issue requirement.
• Documented that NVIDIA contributors may use Linear issues.
• Updated the docs-contribution skill to preserve the same guidance.

Where should the reviewer start?

Start with the PR checklist changes in CONTRIBUTING.md and docs/contribute/workflow-and-reviews.mdx.

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

• Relates to: RELAY-379

Summary by CodeRabbit

• Documentation
  • Updated contribution guidance to require an issue to be opened or identified before submitting a pull request.
  • Clarified the checklist for external contributors and NVIDIA contributors, including acceptable issue-tracking options.
  • Renumbered and refreshed the review checklist to keep submission steps clear and consistent.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Enterprise

Run ID: ef4da0d5-7e32-436d-bcd1-476c36bf8f4a

📥 Commits

Reviewing files that changed from the base of the PR and between cc3e5f1 and f0e1b9b.

📒 Files selected for processing (3)

• .agents/skills/contribute-docs/SKILL.md
• CONTRIBUTING.md
• docs/contribute/workflow-and-reviews.mdx

📜 Recent review details

🧰 Additional context used

📓 Path-based instructions (20)

.agents/skills/**

⚙️ CodeRabbit configuration file

.agents/skills/**:

Maintainer Skills

This directory is the maintainer-only skill set for developing NeMo Relay
itself.

Use these skills for repository work such as:

• Changing core or binding APIs
• Maintaining integrations, packaging, CI, and docs
• Extending middleware or observability internals
• Validating library changes across bindings

Consumer-facing NeMo Relay usage skills live in the top-level skills/
directory so they can be exported separately for integrators and end users.

Files:

• .agents/skills/contribute-docs/SKILL.md

.agents/skills/contribute-docs/**

⚙️ CodeRabbit configuration file

.agents/skills/contribute-docs/**: ---
name: contribute-docs
description: Contribute documentation or example changes that stay aligned with NeMo Relay public behavior
author: NVIDIA Corporation and Affiliates
license: Apache-2.0

Contribute Docs Or Examples

Companion Guidance

Use karpathy-guidelines alongside this skill for implementation or review
work. Keep changes scoped, surface assumptions, and define focused validation
before editing.

Use this skill for docs-only or example-heavy changes.

Rules

• Prefer the documented public API, not internal shortcuts
• Keep package names, repo references, and build commands current
• Update entry-point docs when examples or reading paths change
• Keep release-process and release-notes guidance in repo-maintainer docs such as
  RELEASING.md, not as user-facing docs pages or CHANGELOG.md
• Keep stable user-facing wrappers at scripts/ root in docs and examples;
  only point at namespaced helper paths when documenting internal maintenance
  work
• When detailed dynamic plugin guides exist, keep Rust native plugin examples,
  Python worker plugin examples, and grpc-v1 protocol details on separate
  pages.
• Dynamic plugin manifests in docs/examples should use
  compat.relay = ">=0.5,<1.0" unless deliberately narrower.
• In MDX files, top-of-file comments must use JSX comment delimiters:
  {/* to open and */} to close. Do not use HTML comments for MDX SPDX
  headers.

Checklist

• README.md or docs/index.md updated when entry points changed
• Relevant getting-started or reference docs updated
• Example commands still match current package names and paths
• Relevant package or crate README.md files updated when examples or binding guidance changed
• Dynamic plugin entry pages link to native, worker, Rust example, Python
  example, and protocol pages when those pages exist
• New or regenerated MDX files use {/* ... */} for top-of-file SPDX comments
• Rel...

Files:

• .agents/skills/contribute-docs/SKILL.md

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

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

**/*.{md,rst,html,txt}: Always spell NVIDIA in all caps. Do not use Nvidia, nvidia, nVidia, nVIDIA, or NV.
Use an NVIDIA before a noun because the name starts with an 'en' sound.
Do not add a registered trademark symbol after NVIDIA when referring to the company.
Use trademark symbols with product names only when the document type or legal guidance requires them.
Verify official capitalization, spacing, and hyphenation for product names.
Precede NVIDIA product names with NVIDIA on first mention when it is natural and accurate.
Do not rewrite product names for grammar or title-case rules.
Preserve third-party product names according to the owner's spelling.
Include the company name and full model qualifier on first use when it helps identify the model.
Preserve the official capitalization and punctuation of model names.
Use shorter family names only after the full name is established.
Spell out a term on first use and put the acronym in parentheses unless the acronym is widely understood by the intended audience.
Use the acronym on later mentions after it has been defined.
For long documents, reintroduce the full term if readers might lose context.
Form plurals of acronyms with s, not an apostrophe, such as GPUs.
In headings, common acronyms can remain abbreviated. Spell out the term in the first or second sentence of the body.
Common terms such as CPU, GPU, PC, API, and UI usually do not need to be spelled out for developer audiences.

Files:

• CONTRIBUTING.md

**/*.{md,rst,html}

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

Link the first mention of a product name when the destination helps the reader.

Files:

• CONTRIBUTING.md

**/*.md

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

Documentation must be updated if activation or usage changed

**/*.md: Use title case consistently in technical documentation headings
Avoid quotation marks, ampersands, and exclamation marks in headings
Keep product, event, research, and whitepaper names in their official title case
Use title case for table headers
Do not force social-media sentence case into technical docs
Format code elements, commands, parameters, package names, and expressions in monospace
Format directories, file names, and paths in monospace using backticks
Use angle brackets inside monospace for variables inside paths, such as /home/<username>/.login
Format error messages and strings in quotation marks, keeping literal code strings in code formatting when clearer
Format UI buttons, menus, fields, and labels in bold
Use angle brackets between UI labels for menu paths, such as File > Save As
Use italics for new terms on first use, sparingly and only when introducing the term
Use italics for publication titles
Format keyboard shortcuts in plain text, such as Press Ctrl+Alt+Delete
Use owner/repo link text for GitHub repositories, preferring [NVIDIA/NeMo](link) over prose references like 'the GitHub repo'
Introduce every code block with a complete sentence
Do not make a code block complete the grammar of the previous sentence
Do not continue a sentence after a code block
Use syntax highlighting when the format supports it for code blocks
Avoid the word 'snippet' unless the surrounding docs already use it as a term of art
Keep inline method, function, and class references consistent with nearby docs, omitting empty parentheses for prose readability when no call is shown
Use descriptive anchor text that matches the destination title when possible for links
Avoid raw URLs in running text
Avoid generic anchor text such as 'here,' 'this page,' and 'read more'
Include acronyms in link text when a linked term includes an acronym
Do not link long sentences or multiple sentences
Avoid links ...

Files:

• CONTRIBUTING.md

**/{docs,examples,**/*.md,*.patch,*.diff,.github,*.sh,*.yaml,*.yml}

📄 CodeRabbit inference engine (.agents/skills/rename-surfaces/SKILL.md)

Update documentation, examples, CI configuration, and patch artifacts when performing rename operations

Files:

• CONTRIBUTING.md

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

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

Spell NVIDIA in all caps. Do not use Nvidia, nvidia, or NV.

Files:

• CONTRIBUTING.md

**/*.{md,rst}

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

**/*.{md,rst}: Format commands, code elements, expressions, package names, file names, and paths as inline code.
Use descriptive link text. Avoid raw URLs and weak anchors such as "here" or "read more."
Use title case consistently for technical documentation headings.
Introduce code blocks, lists, tables, and images with complete sentences.
Write procedures as imperative steps. Keep steps parallel and split long procedures into smaller tasks.
Prefer active voice, present tense, short sentences, contractions, and plain English.
Use can for possibility and reserve may for permission.
Use after for temporal relationships instead of once.
Prefer refer to over see when the wording points readers to another resource.
Avoid culture-specific idioms, unnecessary Latinisms, jokes, and marketing exaggeration in technical docs.
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 include commas in thousands.
Do not add trademark symbols to learning-oriented docs unless the source, platform, or legal guidance explicitly requires them.

Files:

• CONTRIBUTING.md

{docs/**,README.md,CONTRIBUTING.md}

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

{docs/**,README.md,CONTRIBUTING.md}: For docs-only changes, run targeted checks only if commands, package names, or examples changed. Use just docs for docs-site builds and just docs-linkcheck when links changed
Run docs site build with just docs

Files:

• CONTRIBUTING.md
• docs/contribute/workflow-and-reviews.mdx

{docs/**,README.md,CONTRIBUTING.md,**/*.md}

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

Run docs link validation with just docs-linkcheck when links change

Files:

• CONTRIBUTING.md
• docs/contribute/workflow-and-reviews.mdx

{docs/**,README.md,**/Cargo.toml,**/package.json,**/*.md}

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

Ensure renamed public surfaces are reflected consistently in manifests and docs for large or public-facing changes

Files:

• CONTRIBUTING.md
• docs/contribute/workflow-and-reviews.mdx

**/*.{rs,py,js,ts,tsx,jsx,go,sh,toml,yaml,yml,md}

📄 CodeRabbit inference engine (AGENTS.md)

Keep SPDX headers on source, docs, scripts, and configuration files. The project is Apache-2.0.

Files:

• CONTRIBUTING.md

**/*.{md,mdx}

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

**/*.{md,mdx}: Prefer the documented public API, not internal shortcuts
Keep package names, repo references, and build commands current
When documenting contribution workflow, require an issue before external contribution PRs and note that NVIDIA contributors may use a GitHub or Linear issue
Keep stable user-facing wrappers at scripts/ root in docs and examples; only point at namespaced helper paths when documenting internal maintenance work
When detailed dynamic plugin guides exist, keep Rust native plugin examples, Python worker plugin examples, and grpc-v1 protocol details on separate pages
Dynamic plugin manifests in docs/examples should use compat.relay = ">=0.5,<1.0" unless deliberately narrower
Example commands still match current package names and paths

Files:

• CONTRIBUTING.md
• docs/contribute/workflow-and-reviews.mdx

**

⚙️ CodeRabbit configuration file

**:

AGENTS.md

This file provides guidance to agents, including Claude Code and OpenAI Codex, when working in this repository.

Project Overview

NeMo Relay is a multi-language agent runtime framework for execution scopes, lifecycle events, middleware, plugins, and observability around tool and LLM calls. The core runtime is Rust. Primary supported bindings are Rust, Python, and Node.js. Go and the raw C FFI are experimental and source-first.

The shared runtime model is:

1. Scope stacks decide where work belongs and which scope-local behavior is visible.
2. Middleware registries decide what guardrails and intercepts run around managed calls.
3. Plugins install reusable runtime behavior from configuration.
4. Events record runtime behavior in ATOF form.
5. Subscribers and exporters consume events in-process or export them to ATIF, OpenTelemetry, OpenInference, or other backends.

Repository Structure

The repository layout separates the Rust runtime, language bindings,
documentation, integrations, and agent-facing skills.

crates/
  core/       # Rust core runtime crate, published as nemo-relay
  adaptive/   # Adaptive runtime primitives and plugin components
  python/     # PyO3 native extension for the Python package
  ffi/        # Raw C ABI layer used by downstream bindings such as Go
  node/       # NAPI Node.js binding and JavaScript/TypeScript entry points
python/
  nemo_relay/  # Python wrapper package: scopes, tools, LLM, middleware, typed helpers, plugins, adaptive helpers
  tests/      # Python tests
go/
  nemo_relay/  # Experimental Go CGo binding and tests
fern/         # Fern documentation site
scripts/      # Stable wrappers and helper scripts; build/test/docs entry points live in justfile
skills/       # Published Codex/agent skills for NeMo Relay usage patterns

Prerequisites

Insta...

Files:

• CONTRIBUTING.md
• docs/contribute/workflow-and-reviews.mdx

{docs/**,README.md,CONTRIBUTING.md,RELEASING.md,SECURITY.md}

⚙️ CodeRabbit configuration file

{docs/**,README.md,CONTRIBUTING.md,RELEASING.md,SECURITY.md}: Review documentation for technical accuracy against the current API, command correctness, and consistency across language bindings.
Flag stale examples, missing SPDX headers where required, and instructions that no longer match CI or pre-commit behavior.

Files:

• CONTRIBUTING.md
• docs/contribute/workflow-and-reviews.mdx

{docs/**,README.md}

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

Verify README and docs entry points still match current package names and paths for large or public-facing changes

Files:

• docs/contribute/workflow-and-reviews.mdx

{docs/**,examples/**,README.md}

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

Verify examples still run with documented commands for large or public-facing changes

Files:

• docs/contribute/workflow-and-reviews.mdx

**/*.mdx

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

MDX top-of-file SPDX comments must use {/* ... */} delimiters instead of HTML comment delimiters (Must-Fix)

**/*.mdx: In MDX files, top-of-file comments must use JSX comment delimiters: {/* to open and */} to close; do not use HTML comments for MDX SPDX headers
New or regenerated MDX files use {/* ... */} for top-of-file SPDX comments

Files:

• docs/contribute/workflow-and-reviews.mdx

{RELEASING.md,CHANGELOG.md,docs/**/*.{md,mdx}}

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

{RELEASING.md,CHANGELOG.md,docs/**/*.{md,mdx}}: Keep release-process and release-notes guidance in repo-maintainer docs such as RELEASING.md, not as user-facing docs pages or CHANGELOG.md
Release-policy docs still point to GitHub Releases as the only release-history source of truth

Files:

• docs/contribute/workflow-and-reviews.mdx

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

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

docs/**/*.{md,mdx}: Relevant getting-started or reference docs updated
Dynamic plugin entry pages link to native, worker, Rust example, Python example, and protocol pages when those pages exist

Files:

• docs/contribute/workflow-and-reviews.mdx

🧠 Learnings (1)

📓 Common learnings

Learnt from: CR
Repo: NVIDIA/NeMo-Relay

Timestamp: 2026-07-01T21:45:55.672Z
Learning: Run `just docs` when the docs site changed; `./scripts/build-docs.sh html` remains the compatibility wrapper

Learnt from: CR
Repo: NVIDIA/NeMo-Relay

Timestamp: 2026-07-01T21:46:09.457Z
Learning: Use the branch name prefixes `feat/`, `fix/`, `docs/`, `test/`, or `refactor/` according to the type of work being done.

Learnt from: CR
Repo: NVIDIA/NeMo-Relay

Timestamp: 2026-07-01T21:46:09.457Z
Learning: Use raw Rust-compatible SemVer release tags without a leading `v` (for example `0.1.0` or `0.1.0-rc.1`).

Learnt from: CR
Repo: NVIDIA/NeMo-Relay

Timestamp: 2026-07-01T21:46:09.457Z
Learning: Ensure every commit in a pull request includes a Developer Certificate of Origin sign-off.

Learnt from: CR
Repo: NVIDIA/NeMo-Relay

Timestamp: 2026-07-01T21:46:09.457Z
Learning: Use `SONAR_IGNORE_START` / `SONAR_IGNORE_END` only for documented false positives, keep the ignored block as small as possible, add a brief explanation comment, and mention it in the PR description for reviewer sign-off.

Learnt from: CR
Repo: NVIDIA/NeMo-Relay

Timestamp: 2026-07-01T21:46:09.457Z
Learning: Keep commit messages in the form `type: short description` with an optional body, using one of the approved types and keeping the first line under 72 characters.

Learnt from: CR
Repo: NVIDIA/NeMo-Relay

Timestamp: 2026-07-01T21:46:09.457Z
Learning: Before making significant changes, read the architecture documentation in `docs/` and understand the layered architecture (Core Rust, FFI/C, PyO3, and NAPI bindings).

🔇 Additional comments (3)

.agents/skills/contribute-docs/SKILL.md (1)

23-23: LGTM!

CONTRIBUTING.md (1)

217-222: LGTM!

docs/contribute/workflow-and-reviews.mdx (1)

32-36: LGTM!

---

Walkthrough

Documentation updates require contributors to open or identify an issue before submitting a pull request. Changes span the contribute-docs skill rules, CONTRIBUTING.md's "Before Submitting" checklist, and workflow-and-reviews.mdx, with checklist items renumbered accordingly.

Changes

Issue-linking requirement in contribution docs

Layer / File(s)	Summary
Add issue requirement to checklists and rules .agents/skills/contribute-docs/SKILL.md, CONTRIBUTING.md, docs/contribute/workflow-and-reviews.mdx	Adds a rule requiring external PRs to reference an issue (NVIDIA contributors may use GitHub or Linear), and inserts a new first checklist step in CONTRIBUTING.md and workflow-and-reviews.mdx requiring an issue before PR submission, with remaining steps renumbered.

Estimated code review effort: 1 (Trivial) | ~3 minutes

Possibly related PRs

• NVIDIA/NeMo-Relay#45: Updates the prepare-pr agent skill to require the PR template's "Related Issues" section, enforcing the same issue-linking requirement introduced here.

Suggested labels: documentation

Suggested reviewers: none identified

Poem

A rabbit hops with checklist in paw,
"First find an issue," is the new law.
Docs renumbered, rules refined,
Before you submit, leave an issue behind. 🐇

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title follows Conventional Commits and accurately summarizes the docs-only change.
Description check	✅ Passed	The description matches the template with overview, details, reviewer guidance, checklist items, and a related issue reference.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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

[github-actions]

Fern docs preview: https://nvidia-preview-pull-request-343.docs.buildwithfern.com/nemo/relay (​https://nvidia-preview-pull-request-343.docs.buildwithfern.com/nemo/relay​)

[lvojtku]

Approved without comments

[willkill07]

/merge