Generated banner for Launch Nemo Rl
Generated logo for Launch Nemo Rl

Launch Nemo Rl

NVIDIAOfficialPublished by NVIDIA

  • Skill
  • Tool integration
  • Cloud and DevOps
  • Apache-2.0
  • Medium risk

From the author

Playbook for launching, monitoring, stopping, and debugging NeMo-RL recipes on a Kubernetes cluster via the nrl-k8s CLI. Covers ephemeral vs long-lived RayCluster modes, iterating on runs, and debugging hung or failed training jobs.
— the description by NVIDIA

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a comprehensive guide for using the nrl-k8s CLI to launch, monitor, and debug NeMo-RL training recipes on Kubernetes. It covers the lifecycle management of RayClusters, including ephemeral RayJob runs for one-shot tasks and long-lived clusters for iterative development. The playbook details how to pair recipe and infrastructure configurations, manage hardware profiles, handle code synchronization, and troubleshoot common issues like hung jobs or configuration drift.

What it does

  • Launches NeMo-RL training jobs in either ephemeral or long-lived RayCluster modes.
  • Manages the lifecycle of RayClusters, including creation, monitoring, and teardown.
  • Provides observability tools for checking job status, tailing logs, and accessing the Ray dashboard.
  • Supports configuration of hardware profiles, scheduler settings, and shared filesystem mounts.
  • Facilitates debugging of failed or stuck training runs through log access and status inspection.
  • Includes a dev pod utility for remote code syncing and in-cluster debugging.

When to use it

  • When you need to submit a NeMo-RL training job to a Kubernetes cluster.
  • When iterating on training recipes and requiring a persistent RayCluster for faster feedback.
  • When you need to debug a stuck or failed training run on the cluster.
  • When you need to manage the lifecycle of RayClusters or auxiliary deployments.

Advantages

  • Standardizes the launch process for NeMo-RL recipes across different hardware profiles.
  • Supports both one-shot ephemeral runs and persistent development environments.
  • Provides clear patterns for handling configuration overrides without modifying base files.
  • Offers robust observability for tracking job progress and accessing logs.

Usage examples

“Launch a new NeMo-RL training job as an ephemeral RayJob.”
The agent validates the recipe and infra files, then submits a RayJob to the cluster, automatically tearing down the cluster upon completion.
“How do I debug a training run that seems stuck?”
The agent uses nrl-k8s status and job logs commands to inspect the RayCluster state, worker pod phases, and driver logs to identify the bottleneck.
“Set up a long-lived cluster for iterative development.”
The agent runs the nrl-k8s run command with the --raycluster flag, allowing you to submit multiple training jobs to the same persistent cluster.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/nvidia/launch-nemo-rl/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip launch-nemo-rl.zip -d .agents/skills

Documentation by NVIDIA

launch-nemo-rl — running NeMo-RL recipes on Kubernetes via nrl-k8s

This is the playbook for the nrl-k8s CLI at infra/nrl_k8s/. Follow it when the user asks to launch / iterate / debug a NeMo-RL recipe on a Kubernetes cluster. Verify current state (kubectl, git log, the recipe + infra files) before acting — the cluster is shared and the cost of a wrong action is high.

1. One command, two modes

There is a single top-level submission command: nrl-k8s run. It has two lifecycle modes.

ModeInvocationWhen to useCluster after?
Ephemeral (default)nrl-k8s runOne-shot. KubeRay applies a RayJob, runs, tears the cluster down. Best for most runs.No (auto)
Long-livednrl-k8s run --rayclusterDev loop. Reuses a matching live cluster, applies if absent, warns + reuses on drift (pass --recreate to replace). Then submits daemons and training. First-choice for iteration.Yes

Ask: Do I need this cluster after the run? If yes, use --raycluster. Otherwise use the default (ephemeral).

The rest of the CLI is observability / stage-by-stage control:

CommandPurpose
nrl-k8s checkValidate a recipe + infra pair; optionally write the fully-resolved manifests (-o).
nrl-k8s statusPer-role RayCluster state, head pod phase, worker pod phases, daemon job status.
nrl-k8s cluster up/down/list/dashboardManage RayClusters independently of a run (e.g. render a manifest with --dry-run).
nrl-k8s job list/logs/stopObservability over Ray Jobs already submitted to a role's cluster.
nrl-k8s logsTail a role's pod / daemon logs without needing a submission id.

2. Recipe + infra pair

Every launch takes two files. Pass the infra with --infra, not merged inline:

nrl-k8s run infra/nrl_k8s/examples/<recipe>.yaml \
  --infra infra/nrl_k8s/examples/<recipe>.<profile>.infra.yaml
  • Recipe (e.g. qwen3_30b_math_8n_4gpu.yaml) — NeMo-RL config: model, GRPO/SFT knobs, cluster.{gpus_per_node,num_nodes}. Uses defaults: to inherit from examples/configs/recipes/llm/....

  • Infra (e.g. *.<profile>.infra.yaml) — K8s/Ray shape: namespace, image, service account, RayCluster spec under kuberay:, optional Deployments under deployments:, submit.submitter, launch.{mode,codeSource,codePath,entrypoint}. Pair names follow <recipe>.<profile>[.prod].infra.yaml where <profile> names the hardware target (e.g. gb300).

Example pairs in infra/nrl_k8s/examples/ — read the neighbouring files to see the current conventions for the target profile.

3. Long-lived mode flags

Three independent dimensions. --mode is a macro that picks defaults; individual flags override it.

--mode interactive   → --submitter portForward  --code-source upload  (tails logs)
--mode batch         → --submitter exec         --code-source image   (returns after nohup)
  • Submitter: portForward uses kubectl port-forward + Ray Job SDK (gets a submission_id the dashboard tracks). exec uses kubectl exec + nohup on the head pod (no submission_id; driver appears as type=DRIVER in the dashboard).

  • Code source: upload stages a working_dir from the laptop (Ray 100 MiB cap). image / lustre expect code on the pod's filesystem — paired with --code-path (typically /opt/nemo-rl), which is a subPath of the shared-filesystem PVC mount in the standard infra examples.

  • Wait: --wait tails logs until terminal; --no-wait returns as soon as the driver is running.

Other long-lived-only flags:

  • --replace — stop any running training / daemon job before submitting new ones (suffixes daemon submissionIds with a timestamp so Ray accepts the resubmit).

  • --recreate — delete + re-apply a RayCluster whose live spec has drifted from the rendered manifest (default is warn + reuse).

  • --skip-daemons — bring up all declared clusters but only submit training. Use on disagg recipes where gym/generation are already healthy.

Gotcha: on infra where the entrypoint does cd /opt/nemo-rl (or another in-image / Lustre path) and loads the recipe from there, --code-source upload does NOT override the recipe on the pod — the uploaded working_dir sits in /tmp/ray/... but the entrypoint cds away from it. To actually test a local recipe change, either sync your edits to the shared filesystem mounted into the pods or flip the Hydra overrides in the entrypoint.

4. Ephemeral mode flags (--rayjob)

When --rayjob is set, run branches into the RayJob code path. Relevant flags:

  • --rayjob-name NAME — RayJob metadata name (defaults to the training cluster name).

  • --shutdown / --no-shutdown — default true: KubeRay deletes the RayCluster once the Ray Job reaches a terminal state.

  • --ttl SECONDS — default 3600s: keep the RayJob object around after the run finishes for post-mortem log access.

  • --wait / --no-wait — default wait: poll jobDeploymentStatus until Complete/Failed. --no-wait returns as soon as the RayJob is applied.

  • --timeout SECONDS — default 86400s (24h): bound the --wait poll.

  • --dry-run — render the RayJob manifest and print it; do not apply.

--replace / --recreate / --skip-daemons are silently ignored in --rayjob mode (KubeRay owns lifecycle).

5. Iterating on a config without touching the shared filesystem

When the recipe on the pod filesystem has the wrong value for your experiment, use Hydra overrides on the entrypoint instead of forking the recipe. Pattern:

entrypoint: |
  set -eu
  cd /opt/nemo-rl
  RUN_ID="\${RAY_JOB_SUBMISSION_ID:-\${NRL_K8S_RUN_ID:-$(date -u +%Y%m%d-%H%M%S)}}"
  python -u examples/run_grpo.py \
    --config infra/nrl_k8s/examples/<recipe>.yaml \
    logger.wandb_enabled=true \
    logger.wandb.project=<project> \
    "logger.wandb.name=<run-name>-\${RUN_ID}"

Escape ${…} with a backslash. OmegaConf otherwise interprets it as interpolation and errors on shell-style ${VAR:-default}. RUN_ID resolves to RAY_JOB_SUBMISSION_ID (injected by KubeRay in rayjob mode) → NRL_K8S_RUN_ID (injected by the CLI in long-lived mode) → local timestamp — so the name is unique across either path.

6. Per-profile concerns (hardware + scheduler + DRA)

Every infra YAML encodes a hardware/scheduler profile. The concrete examples in infra/nrl_k8s/examples/ are authoritative for the profiles they target — read the neighbouring infra file before writing a new one. Things that commonly vary:

  • Per-node GPUs (e.g. 4 vs 8) — must match cluster.gpus_per_node in the recipe, otherwise workers stay Pending.

  • Node selectors — head pods usually land on a CPU-only node pool; GPU workers match on nvidia.com/gpu.product or a node-group label.

  • Scheduler — KAI (schedulerName: kai-scheduler + kai.scheduler/queue label) with topology annotations (kai.scheduler/topology, kai.scheduler/topology-required-placement) gang-schedules workers into one clique. Without it, pods may land on different racks and NVLink/RoCE won't span them.

  • DRA claims — ComputeDomain + RoCE are attached via resourceClaims referencing ResourceClaimTemplates. The CLI auto-creates/deletes these when the worker pod spec contains DRA claim references — no manual setup needed.

  • Secrets — always via secretKeyRef (wandb-api-key, image pull secret). Never embed.

  • Shared filesystem mounts — typically a Lustre PVC mounted twice: once at the code path (e.g. /opt/nemo-rl with a user-scoped subPath) and once at a workspace root (e.g. /mnt/rl-workspace) for datasets, HF cache, and checkpoints.

Before applying an infra, verify prereqs exist in the target namespace:

kubectl get pvc <workspace-pvc>
kubectl get secret <wandb-secret> <image-pull-secret>
kubectl get sa <service-account>

7. End-to-end workflows

7a. Fresh one-shot run (rayjob)
# From the NeMo-RL repo root:
nrl-k8s check <recipe> --infra <infra>                               # validate first
nrl-k8s run <recipe> --infra <infra> --rayjob --dry-run              # render RayJob manifest
nrl-k8s run <recipe> --infra <infra> --rayjob --no-wait              # apply, returns fast

Watch status + teardown (works even after your laptop disconnects because KubeRay owns the lifecycle):

kubectl get rayjob -n default <name> -w
kubectl get raycluster -n default                                    # empty = teardown succeeded
7b. Dev loop (long-lived)
nrl-k8s run <recipe> --infra <infra> --run-id $(date +%Y%m%d-%H%M%S)
# Edits in the recipe? Just re-run — reuses the live cluster.
# Pod spec changed? Add --recreate to delete + re-apply.
# Disagg recipe with gym/gen already healthy? --skip-daemons.
7c. First-time disaggregated bring-up
nrl-k8s run <recipe> --infra <disagg-infra> --mode batch --code-source image
7d. Cluster-only lifecycle
nrl-k8s cluster up   <recipe> --infra <infra> --target kuberay.training --wait
nrl-k8s cluster up   <recipe> --infra <infra> --target kuberay.training --dry-run   # render manifest
nrl-k8s cluster down <recipe> --infra <infra> --target kuberay.training --wait
nrl-k8s cluster down <recipe> --infra <infra>                                       # tear down all
nrl-k8s cluster list -n default
nrl-k8s cluster dashboard <cluster-name>                                  # port-forward + browser
7e. Deployments (e.g. nemo-skills sandbox)
# Bring up just the deployment
nrl-k8s cluster up <recipe> --infra <infra> --target deployments.nemo_skills
# Tear down just the deployment
nrl-k8s cluster down <recipe> --infra <infra> --target deployments.nemo_skills
# Tear down everything (RayClusters + Deployments)
nrl-k8s cluster down <recipe> --infra <infra>

The deployments: section in infra YAML declares Kubernetes Deployments managed alongside RayClusters. The CLI patches image, imagePullSecrets, and serviceAccountName from the top-level infra keys (same as RayClusters). Deployments start in parallel with cluster bring-up — no ordering dependency.

8. Monitoring a run

# Status
nrl-k8s status <recipe> --infra <infra>
kubectl get rayjob,raycluster -n default

# Follow the driver
nrl-k8s job list <recipe> --infra <infra> --role training
nrl-k8s job logs <run-id> <recipe> --infra <infra> --role training -f

When the nrl-k8s job logs -f subprocess dies (kubectl port-forward i/o timeout after ~15 min idle), just re-run it. The training job keeps going.

To fetch driver logs for a terminal job (SUCCEEDED/FAILED) or a RayJob via the dashboard API:

RC=$(kubectl get rayjob -n default <rayjob-name> -o jsonpath='{.status.rayClusterName}')
kubectl port-forward -n default svc/${RC}-head-svc 18266:8265 &
curl -s http://localhost:18266/api/jobs/                              # lists jobs, find submission_id
curl -s "http://localhost:18266/api/jobs/<submission_id>/logs"        # full driver log

type=DRIVER with submission_id=null means an exec-submitter run (no dashboard log endpoint — use nrl-k8s job logs instead). type=SUBMISSION has submission_id set and /api/jobs/<id>/logs works.

Wandb URL appears in the driver log on the first wandb.init call; grep grep -oE 'https://wandb\.ai/[A-Za-z0-9_./-]+'.

9. Stopping things

What to stopCommand
One training runnrl-k8s job stop <run-id> <recipe> --infra <infra> --role training
All running Ray jobs on a cluster (+ submit new)nrl-k8s run <recipe> --infra <infra> --replace
A long-lived RayClusternrl-k8s cluster down <recipe> --infra <infra> --target kuberay.training --wait
A RayJob (ephemeral)kubectl delete rayjob <name> -n default — only if shutdownAfterJobFinishes didn't fire

Confirm before deleting shared infra. The cost of cluster down on someone else's cluster is high.

10. Verifying RayJob teardown

After a run --rayjob completes with --shutdown (default), KubeRay should delete the RayCluster:

kubectl get rayjob   -n default <rayjob-name>                        # jobDeploymentStatus = Complete
kubectl get raycluster -n default | grep <rayjob-name>               # no output = torn down

The RayJob object itself sticks around for --ttl seconds (default 3600s) so you can still fetch logs.

11. Common gotchas

  • OmegaConf interpolation eats ${VAR} in recipe/infra YAML. Escape shell variables with \${VAR} so OmegaConf passes them through to the pod shell verbatim.

  • Megatron optimizer configs don't carry foreach / fused. Overrides like ~policy.optimizer.kwargs.foreach ~policy.optimizer.kwargs.fused (valid for DTensor configs) break on Megatron recipes. Omit them for Megatron.

  • DTensor vs Megatron — MoE recipes typically use megatron_cfg.enabled=true; ensure dtensor_cfg.enabled=false in inherited defaults.

  • Shared filesystem vs git divergence — codeSource: image|lustre reads from the pod filesystem. If your local edits aren't on the shared filesystem the pods mount, the run is testing the on-disk version, not yours. Either sync via a helper pod (head pod exec is often blocked) or override via Hydra flags.

  • Ephemeral-storage + readinessProbe are injected by kuberay/CDI webhooks at pod-apply time. Do NOT add them to the inline RayCluster spec.

  • Node taints vary per cluster. tolerations: [{operator: Exists}] on workers is defensive and worth keeping.

  • Dashboard blank page — Ray 2.52 installs dashboard assets as symlinks by default; nrl-k8s cluster dashboard <name> auto-reinstalls ray[default] --link-mode=copy to fix it. Bake ENV UV_LINK_MODE=copy in the image to avoid this entirely.

  • kubectl exec is usually blocked in automation — route around with kubectl get ... -o yaml, kubectl logs, and kubectl port-forward + Ray dashboard APIs.

12. Checklist before calling a run "done"

Before reporting a launch as successful, verify:

  1. kubectl get rayjob/raycluster -n default shows the expected objects.

  2. nrl-k8s job list (or curl /api/jobs/) shows the job in RUNNING / SUCCEEDED.

  3. Driver log contains wandb.ai/<project>/runs/<id> (if wandb is enabled) — share the URL with the user.

  4. At least one Processed prompts: 100% line appears (confirms generation is wired).

  5. For --rayjob mode only: after jobDeploymentStatus=Complete, confirm kubectl get raycluster | grep <name> is empty (teardown worked).

13. Dev pod

nrl-k8s dev manages a lightweight CPU pod on the cluster for code syncing, debugging, and running kubectl/nrl-k8s from within the cluster.

# One-time: set up secrets (HF token, wandb, SSH key, rclone)
nrl-k8s dev setup-secrets --ssh-key ~/.ssh/id_rsa --add-rclone

# Create pod and exec in (idempotent — reuses existing pod)
nrl-k8s dev connect

# Switch image (must stop first — image change is warned but not auto-applied)
nrl-k8s dev stop
nrl-k8s dev connect --image nvcr.io/nvidian/nemo-rl:v0.7.0

# Tear down
nrl-k8s dev stop

The dev pod:

  • Runs on a CPU-only node (anti-affinity to GPU nodes)

  • Mounts the shared rl-workspace PVC at /mnt/rl-workspace

  • Sets USER env var to the nrl-k8s username (so $USER and getpass.getuser() work correctly despite running as root)

  • Installs kubectl, rclone (if configured) on first boot

  • Injects SSH keys and tokens via envFrom on a per-user K8s Secret

The pod's default service account needs an edit RoleBinding in the namespace for kubectl to work inside. dev connect checks this and prints the required YAML if missing.

14. Where things live in the repo

  • CLI code: infra/nrl_k8s/src/nrl_k8s/ (cli.py, orchestrate.py, manifest.py, rayjob.py, k8s.py, submitters/, schema.py).

  • Tests: infra/nrl_k8s/tests/unit/ — run with uv run --extra test pytest -x -q from infra/nrl_k8s/.

  • Recipe + infra examples: infra/nrl_k8s/examples/.

  • Base recipes this tool wraps: examples/configs/recipes/llm/… and examples/nemo_gym/….

Files

LICENSE

Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved.


                                 Apache License
                           Version 2.0, January 2004
                        http://www.apache.org/licenses/

   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

   1. Definitions.

      "License" shall mean the terms and conditions for use, reproduction,
      and distribution as defined by Sections 1 through 9 of this document.

      "Licensor" shall mean the copyright owner or entity authorized by
      the copyright owner that is granting the License.

      "Legal Entity" shall mean the union of the acting entity and all
      other entities that control, are controlled by, or are under common
      control with that entity. For the purposes of this definition,
      "control" means (i) the power, direct or indirect, to cause the
      direction or management of such entity, whether by contract or
      otherwise, or (ii) ownership of fifty percent (50%) or more of the
      outstanding shares, or (iii) beneficial ownership of such entity.

      "You" (or "Your") shall mean an individual or Legal Entity
      exercising permissions granted by this License.

      "Source" form shall mean the preferred form for making modifications,
      including but not limited to software source code, documentation
      source, and configuration files.

      "Object" form shall mean any form resulting from mechanical
      transformation or translation of a Source form, including but
      not limited to compiled object code, generated documentation,
      and conversions to other media types.

      "Work" shall mean the work of authorship, whether in Source or
      Object form, made available under the License, as indicated by a
      copyright notice that is included in or attached to the work
      (an example is provided in the Appendix below).

      "Derivative Works" shall mean any work, whether in Source or Object
      form, that is based on (or derived from) the Work and for which the
      editorial revisions, annotations, elaborations, or other modifications
      represent, as a whole, an original work of authorship. For the purposes
      of this License, Derivative Works shall not include works that remain
      separable from, or merely link (or bind by name) to the interfaces of,
      the Work and Derivative Works thereof.

      "Contribution" shall mean any work of authorship, including
      the original version of the Work and any modifications or additions
      to that Work or Derivative Works thereof, that is intentionally
      submitted to Licensor for inclusion in the Work by the copyright owner
      or by an individual or Legal Entity authorized to submit on behalf of
      the copyright owner. For the purposes of this definition, "submitted"
      means any form of electronic, verbal, or written communication sent
      to the Licensor or its representatives, including but not limited to
      communication on electronic mailing lists, source code control systems,
      and issue tracking systems that are managed by, or on behalf of, the
      Licensor for the purpose of discussing and improving the Work, but
      excluding communication that is conspicuously marked or otherwise
      designated in writing by the copyright owner as "Not a Contribution."

      "Contributor" shall mean Licensor and any individual or Legal Entity
      on behalf of whom a Contribution has been received by Licensor and
      subsequently incorporated within the Work.

   2. Grant of Copyright License. Subject to the terms and conditions of
      this License, each Contributor hereby grants to You a perpetual,
      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
      copyright license to reproduce, prepare Derivative Works of,
      publicly display, publicly perform, sublicense, and distribute the
      Work and such Derivative Works in Source or Object form.

   3. Grant of Patent License. Subject to the terms and conditions of
      this License, each Contributor hereby grants to You a perpetual,
      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
      (except as stated in this section) patent license to make, have made,
      use, offer to sell, sell, import, and otherwise transfer the Work,
      where such license applies only to those patent claims licensable
      by such Contributor that are necessarily infringed by their
      Contribution(s) alone or by combination of their Contribution(s)
      with the Work to which such Contribution(s) was submitted. If You
      institute patent litigation against any entity (including a
      cross-claim or counterclaim in a lawsuit) alleging that the Work
      or a Contribution incorporated within the Work constitutes direct
      or contributory patent infringement, then any patent licenses
      granted to You under this License for that Work shall terminate
      as of the date such litigation is filed.

   4. Redistribution. You may reproduce and distribute copies of the
      Work or Derivative Works thereof in any medium, with or without
      modifications, and in Source or Object form, provided that You
      meet the following conditions:

      (a) You must give any other recipients of the Work or
          Derivative Works a copy of this License; and

      (b) You must cause any modified files to carry prominent notices
          stating that You changed the files; and

      (c) You must retain, in the Source form of any Derivative Works
          that You distribute, all copyright, patent, trademark, and
          attribution notices from the Source form of the Work,
          excluding those notices that do not pertain to any part of
          the Derivative Works; and

      (d) If the Work includes a "NOTICE" text file as part of its
          distribution, then any Derivative Works that You distribute must
          include a readable copy of the attribution notices contained
          within such NOTICE file, excluding those notices that do not
          pertain to any part of the Derivative Works, in at least one
          of the following places: within a NOTICE text file distributed
          as part of the Derivative Works; within the Source form or
          documentation, if provided along with the Derivative Works; or,
          within a display generated by the Derivative Works, if and
          wherever such third-party notices normally appear. The contents
          of the NOTICE file are for informational purposes only and
          do not modify the License. You may add Your own attribution
          notices within Derivative Works that You distribute, alongside
          or as an addendum to the NOTICE text from the Work, provided
          that such additional attribution notices cannot be construed
          as modifying the License.

      You may add Your own copyright statement to Your modifications and
      may provide additional or different license terms and conditions
      for use, reproduction, or distribution of Your modifications, or
      for any such Derivative Works as a whole, provided Your use,
      reproduction, and distribution of the Work otherwise complies with
      the conditions stated in this License.

   5. Submission of Contributions. Unless You explicitly state otherwise,
      any Contribution intentionally submitted for inclusion in the Work
      by You to the Licensor shall be under the terms and conditions of
      this License, without any additional terms or conditions.
      Notwithstanding the above, nothing herein shall supersede or modify
      the terms of any separate license agreement you may have executed
      with Licensor regarding such Contributions.

   6. Trademarks. This License does not grant permission to use the trade
      names, trademarks, service marks, or product names of the Licensor,
      except as required for reasonable and customary use in describing the
      origin of the Work and reproducing the content of the NOTICE file.

   7. Disclaimer of Warranty. Unless required by applicable law or
      agreed to in writing, Licensor provides the Work (and each
      Contributor provides its Contributions) on an "AS IS" BASIS,
      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
      implied, including, without limitation, any warranties or conditions
      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
      PARTICULAR PURPOSE. You are solely responsible for determining the
      appropriateness of using or redistributing the Work and assume any
      risks associated with Your exercise of permissions under this License.

   8. Limitation of Liability. In no event and under no legal theory,
      whether in tort (including negligence), contract, or otherwise,
      unless required by applicable law (such as deliberate and grossly
      negligent acts) or agreed to in writing, shall any Contributor be
      liable to You for damages, including any direct, indirect, special,
      incidental, or consequential damages of any character arising as a
      result of this License or out of the use or inability to use the
      Work (including but not limited to damages for loss of goodwill,
      work stoppage, computer failure or malfunction, or any and all
      other commercial damages or losses), even if such Contributor
      has been advised of the possibility of such damages.

   9. Accepting Warranty or Additional Liability. While redistributing
      the Work or Derivative Works thereof, You may choose to offer,
      and charge a fee for, acceptance of support, warranty, indemnity,
      or other liability obligations and/or rights consistent with this
      License. However, in accepting such obligations, You may act only
      on Your own behalf and on Your sole responsibility, not on behalf
      of any other Contributor, and only if You agree to indemnify,
      defend, and hold each Contributor harmless for any liability
      incurred by, or claims asserted against, such Contributor by reason
      of your accepting any such warranty or additional liability.

   END OF TERMS AND CONDITIONS

   APPENDIX: How to apply the Apache License to your work.

      To apply the Apache License to your work, attach the following
      boilerplate notice, with the fields enclosed by brackets "[]"
      replaced with your own identifying information. (Don't include
      the brackets!)  The text should be enclosed in the appropriate
      comment syntax for the file format. We also recommend that a
      file or class name and description of purpose be included on the
      same "printed page" as the copyright notice for easier
      identification within third-party archives.

   Copyright [yyyy] [name of copyright owner]

   Licensed under the Apache License, Version 2.0 (the "License");
   you may not use this file except in compliance with the License.
   You may obtain a copy of the License at

       http://www.apache.org/licenses/LICENSE-2.0

   Unless required by applicable law or agreed to in writing, software
   distributed under the License is distributed on an "AS IS" BASIS,
   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   See the License for the specific language governing permissions and
   limitations under the License.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Declares allowed tools, Needs network access, Needs a command-line tool, Needs Python, Needs Node.js

Security

What our scanner noticed· Medium risk

  • Large base64-encoded blobs
  • References to credential files
  • Instructions that use the network

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
NVIDIA
Publisher
NVIDIA (Official)
Source
NVIDIA/skills · skills/launch-nemo-rl · commit fce3cca
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE-APACHE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by NVIDIA.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download launch-nemo-rl.zip