nemo-relay-migrate-from-flow

Migrates codebases from NeMo Flow to NeMo Relay across Python, Rust, Node.js, Go, and C FFI surfaces.

3.2k|370|Updated Feb 25, 2026
One-click install
npx skills add https://github.com/NVIDIA/skills --skill nemo-relay-migrate-from-flow
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: nemo-relay-migrate-from-flow
Source: https://github.com/NVIDIA/skills/tree/main/skills/nemo-relay-migrate-from-flow
Command: npx skills add https://github.com/NVIDIA/skills --skill nemo-relay-migrate-from-flow

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) components.

What problem does it solve?

Rebranding or migrating a multi-language codebase from NeMo Flow to NeMo Relay requires renaming identifiers, package names, import paths, config paths, environment variables, and FFI symbols consistently without breaking builds or touching unrelated domain words like bare "flow". Doing this by hand across Python, Rust, Node.js, Go, and C surfaces is error-prone and tedious.

Core Features & Use Cases

  • Dry-run migration helper: The bundled migrate_from_nemo_flow.py script reports all planned text edits and path renames before any write, and requires --write plus an exact --confirm-root to apply changes.
  • Multi-language rename map: Covers Python packages and imports, Rust crates and use paths, Node.js package entry points, Go module paths, C FFI headers/symbols/macros, CLI config paths, and environment variables.
  • Safety guardrails: Skips symlinks, lockfiles, vendor/build directories, and credential-bearing dotenv files; refuses writes to filesystem roots or home directories; uses atomic no-replace renames anchored to directory handles.
  • Legacy config handling: Detects project-local .nemo-flow/config.toml and .nemo-flow/plugins.toml and flags them for manual migration instead of blindly renaming them.
  • Use Case: A team with a monorepo containing Rust crates, a Python package, and Go services needs everything renamed from NeMo Flow to NeMo Relay; the agent runs the helper in dry-run mode, reviews the report with the user, then applies the migration and advises on lockfile regeneration.

Quick Start

Ask your agent to migrate the project at a given path from NeMo Flow to NeMo Relay, starting with a dry run of the migration helper before applying any changes.

Frequently Asked Questions about nemo-relay-migrate-from-flow

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I migrate a project from NeMo Flow to NeMo Relay?

Run the bundled migrate_from_nemo_flow.py helper in dry-run mode against your project root with --rename-paths to preview all text edits and renames. After reviewing the report, rerun with --write --rename-paths and --confirm-root set to the same path to apply the migration.

How do I rename nemo_flow imports across Python, Rust, and Go code?

The migration helper rewrites explicit identifiers automatically: nemo_flow to nemo_relay in Python, nemo-flow crates and use paths in Rust, and github.com/NVIDIA/NeMo-Flow/go/nemo_flow import paths in Go. Afterward, regenerate lockfiles with your package manager such as Cargo, uv/pip, npm, or go mod tidy.

Does the migration rename bare 'flow' or 'Flow' words in my code?

No. The helper only rewrites explicit NeMo Flow identifiers, package names, config paths, headers, environment variables, and FFI prefixes. Bare occurrences of flow, Flow, or FlowError are left untouched since they may be domain terms or intentional compatibility names.

What happens to .nemo-flow/config.toml during migration?

Project-local .nemo-flow/config.toml and .nemo-flow/plugins.toml are detected and reported as requiring manual migration. They are never renamed into .nemo-relay automatically; you must move reviewed settings to a supported user or explicit Relay configuration path yourself.

Is the migration script safe to run with --write on my repository?

Write mode requires repeating the reviewed root via --confirm-root and refuses filesystem roots and home directories. It anchors writes to directory handles without following symlinks, uses atomic no-replace renames, skips credential-bearing dotenv files, and exits nonzero if any mutation fails.

When should I not use the NeMo Flow migration helper?

Do not use it for NeMo Relay performance tuning, configuration questions, or any task that is not a Flow-to-Relay rename migration. Also avoid --write when the dry-run report includes unreviewed or secret-bearing configuration files; apply those changes manually instead.