Maintain Packaging

Maintain Release And Packaging Surfaces

Companion Guidance

Use karpathy-guidelines alongside this skill for implementation or review

work. Keep changes scoped, surface assumptions, and define focused validation

before editing.

Use this skill when a change affects how NeMo Relay is built, packaged, named, or

consumed outside the source tree.

Audit Areas

• Rust Cargo.toml package names and workspace metadata
• Python packaging in pyproject.toml
• Python worker plugin SDK packaging in python/plugin/pyproject.toml
• Go module path in go/nemo_relay/go.mod
• Node workspace metadata in root package.json and package-lock.json
• Node package metadata in crates/node/package.json
• FFI header and library naming
• CI workflows, install commands, and example commands
• justfile build, test, clean, version, and package recipes for plugin crates

and packages

• Release tags, release-note surfaces, and registry-facing version translation

Checklist

• [ ] Package names, import paths, and module names are internally consistent
• [ ] Generated artifacts still land where downstream consumers expect
• [ ] Docs and examples use the current install/import/build commands
• [ ] CI references the same package names as local workflows
• [ ] Public packaging changes are reflected in release-facing docs
• [ ] nemo-relay-plugin Rust and Python packages track the project SemVer

policy and Python wheels use valid PEP 440 translation

• [ ] Release tags still use raw SemVer without a leading v
• [ ] Release history and release notes still point to GitHub Releases, not CHANGELOG.md or docs pages

References

• pyproject.toml
• python/plugin/pyproject.toml
• go/nemo_relay/go.mod
• package.json
• package-lock.json
• crates/node/package.json
• RELEASING.md
• .github/workflows/ci_python.yml
• .github/workflows/ci.yaml
• .gitlab-ci.yml
• maintain-dynamic-plugins