Official agent skill

I4h Workflow Train Rl

by NVIDIA in NVIDIA/skills

A skill your agent uses when training, evaluating, or exporting Workflow policies with online RSL-RL or RLinf, including RL checkpoint and Workflow handoff.

OfficialApache-2.0Auto-check passedAI & LLM Engineering

Install I4h Workflow Train Rl

skills CLI
$ npx skills add NVIDIA/skills --skill i4h-workflow-train-rl -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install NVIDIA/skills i4h-workflow-train-rl --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/NVIDIA/skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/i4h-workflow-train-rl .claude/skills/i4h-workflow-train-rl && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
i4h-workflow-train-rl
GitHub stars
3.5k
Used in
1 other repo
Token cost
~3.8k tokens
SKILL.md length
1,533 words
Files
6
Skills in repo
380
Repo updated
First seen
Licence
Apache-2.0

At a glance

A skill your agent uses when training, evaluating, or exporting Workflow policies with online RSL-RL or RLinf, including RL checkpoint and Workflow handoff.

  • Works in 5 steps: Resolve the checkout, confirm Workflow… → For a maintained profile, proceed… → Confirm the Workflow, Scene,… → …
  • Exporting Workflow policies with online RSL-RL
  • SKILL.md covers Purpose, Requirements, Instructions and Resolve the checkout, plus 9 more sections
  • Calls git; reaches github.com

What it does

I4h Workflow Train Rl is an agent skill from NVIDIA/skills, published by the product's own GitHub organization. Use when training, evaluating, or exporting Workflow policies with online RSL-RL or RLinf, including RL checkpoint and Workflow handoff.

Its SKILL.md is about 3.8k tokens, which your agent loads only when the skill is triggered. The skill folder holds 7 other files (for example `BENCHMARK.md`, `agents/openai.yaml` and `evals/evals.json`).

It sits in AI & LLM Engineering. It works with CUDA. The repository describes itself as: Agent Skills for NVIDIA products — install into Claude Code, Codex, and other coding agents to run Physical AI, robotics, simulation, CUDA, and RAG workflows end to end. The licence is Apache-2.0.

When your agent uses it

  • Exporting Workflow policies with online RSL-RL
  • Including RL checkpoint and Workflow handoff

Example prompts

  • “/i4h-workflow-train-rl”

Requirements

  • Python 3

Workflow steps

5 steps, taken from the first numbered list in SKILL.md.

  1. Resolve the checkout, confirm Workflow setup is complete, and select training, evaluation, or export from the request. Evaluation/export…
  2. For a maintained profile, proceed directly to profile and contract checks. Only a request to author a new RL-backed Workflow takes the…
  3. Confirm the Workflow, Scene, observations, actions, rewards, resets, termination, trainer, and runtime Task contracts, then dry-run…
  4. For training, preflight the selected trainer runtime and train in the foreground. For evaluation/export, go directly to the matching…
  5. Evaluate before export and validate the export through the normal Workflow runner when those stages are in scope. Report any required…

What it can do on your machine

Read from SKILL.md and the folder at commit 67a13c0. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • git

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Hosts in commands or code, which the agent is likely to contact:

    • github.com

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

I4h Workflow Train Rl loads about 3.8k tokens when it runs. Until then it costs about 40 tokens; SKILL.md has 1,533 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~40
When it runs · the whole SKILL.md, loaded when a task matches
~3.8k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from NVIDIA/skills at commit 67a13c0, republished under its Apache-2.0 licence (© NVIDIA). 1,533 words, ~3,755 tokens.

Download SKILL.mdSave it as .claude/skills/i4h-workflow-train-rl/SKILL.md (or your agent's skills folder). This skill also uses 5 other files; get the full folder from GitHub.
name
i4h-workflow-train-rl
description
Use when training, evaluating, or exporting Workflow policies with online RSL-RL or RLinf, including RL checkpoint and Workflow handoff.
license
Apache-2.0
metadata.author
Isaac for Healthcare Team <isaac-for-healthcare-support@nvidia.com>
metadata.version
0.8.0
metadata.verification-request
2026-09-21
metadata.tags
isaac-for-healthcare, i4h, reinforcement-learning, rsl-rl, rlinf

Train a Workflow Policy with RL

Purpose

Resolve a maintained online-RL profile, verify its Scene/objective/model contracts, run the selected vectorized trainer, evaluate and export its artifact, and hand that artifact to normal Workflow policy validation.

Requirements

  • Run the Workflow setup skill first so its uv environments and pinned third-party checkouts are available.
  • Use a CUDA-capable Isaac Lab/Arena runtime for the RSL-RL workflow.
  • For Trocar, provide a local GR00T N1.5 3B base or SFT checkpoint and two visible local GPUs for the isolated controller and simulator runtimes. A compatible checkpoint is a complete local Hugging Face directory that the pinned GR00T N1.5/RLinf loader accepts without conversion; it must retain the N1.5 3B architecture and support the maintained three-camera plus 28-joint observation mapping and 28-D policy action head. Reject another model family, an exported inference-only Task artifact, or a checkpoint whose config changes those interfaces.

Instructions

  1. Resolve the checkout, confirm Workflow setup is complete, and select training, evaluation, or export from the request. Evaluation/export with an existing checkpoint skips training; never start a new training run to satisfy those requests.
  2. For a maintained profile, proceed directly to profile and contract checks. Only a request to author a new RL-backed Workflow takes the authoring branch below; return to these checks after adding its profile.
  3. Confirm the Workflow, Scene, observations, actions, rewards, resets, termination, trainer, and runtime Task contracts, then dry-run training or evaluation with its exact checkpoint and options. Export uses profile/contract checks and has no dry-run mode.
  4. For training, preflight the selected trainer runtime and train in the foreground. For evaluation/export, go directly to the matching commands below using the supplied checkpoint or run bundle.
  5. Evaluate before export and validate the export through the normal Workflow runner when those stages are in scope. Report any required validation that could not be completed.

Resolve the checkout

Before resolving the checkout, use the maintained repository below or an alternative already selected by the user or trusted project configuration. Check an existing checkout's origin and working-tree changes before executing its scripts; an inherited environment variable alone does not establish trust in an alternative source. Honor any requested revision and preserve local changes. If the source is unexpected, stop and resolve it before cloning or launching.

bash
export I4H_WORKFLOWS_REPO_URL="${I4H_WORKFLOWS_REPO_URL:-https://github.com/isaac-for-healthcare/i4h-workflows}"
I4H_REPO_DIR_NAME="${I4H_WORKFLOWS_REPO_URL%/}"
I4H_REPO_DIR_NAME="${I4H_REPO_DIR_NAME##*/}"
I4H_REPO_DIR_NAME="${I4H_REPO_DIR_NAME##*:}"
I4H_REPO_DIR_NAME="${I4H_REPO_DIR_NAME%.git}"
[ -n "$I4H_REPO_DIR_NAME" ] || { echo "Cannot derive a checkout name from I4H_WORKFLOWS_REPO_URL" >&2; exit 2; }
ROOT="${I4H_WORKFLOWS:-$(git rev-parse --show-toplevel 2>/dev/null)}"
if [ ! -d "$ROOT/workflows/i4h_workflows" ]; then
  ROOT="${I4H_WORKFLOWS:-$HOME/$I4H_REPO_DIR_NAME}"
  [ -d "$ROOT/workflows/i4h_workflows" ] || git clone "$I4H_WORKFLOWS_REPO_URL" "$ROOT" || exit 2
fi
[ -d "$ROOT/workflows/i4h_workflows" ] && [ -x "$ROOT/run.sh" ] || { echo "Incomplete workflow checkout: $ROOT" >&2; exit 2; }
export I4H_WORKFLOWS="$ROOT"
cd "$ROOT" || exit 2

Treat this resolver as part of the skill contract. I4H_WORKFLOWS_REPO_URL selects the clone source; I4H_WORKFLOWS selects or reuses a checkout. Never replace an existing checkout.

Resolve the profile and contracts

bash
./train.sh rl list
./train.sh rl show <workflow>
./run.sh show <workflow> --mode policy

Read the profile under ./rl/profiles/, its referenced declarative trainer config under ./rl/config/, Workflow, Scene manifest and implementation, Arena objective config, embodiment, and runtime policy Task manifest before a long run.

Select the maintained path from the profile:

WorkflowTrainerStarting artifactTraining observations/actionsExport and runtime
ultrasound_probe_reachRSL-RL PPONone; train from scratch34-D joint/probe/target state → 6-D relative EE poseTorchScript policy.pt → rsl_rl/ultrasound_probe_reach in-process Task
assemble_trocarRLinf PPO actor/criticLocal GR00T N1.5 SFT/base checkpointThree cameras + 28 arm/hand joints → 28 policy actions padded to the 43-D Scene actionNative RLinf run bundle → GR00T inference export → existing remote gr00t_n15/assemble_trocar Task

For ultrasound_probe_reach, require the target to be sampled from verified upper-torso surface points, the table and phantom to remain fixed, success to require both position and orientation tolerance for consecutive steps, and the exported Task observation order to match training exactly.

For assemble_trocar, require Unitree G1 with Dex3 hands, front and both wrist cameras, the current 87-value body state (29 positions + 29 velocities + 29 torques), 14 Dex3 joint positions, the 28-D GR00T arm/hand mapping, the 15-value body-action prefix, and the maintained g1_trocar reward/termination contract. Do not copy another Trocar environment into the training tree.

Author a new RL-backed Workflow

  1. Create and visibly validate the Workflow and Scene before adding training. Keep assets, embodiment, observations, actions, rewards, resets, termination, and success in their normal Arena and Workflow owners.
  2. Add ./rl/profiles/<workflow>.yaml using the schema below. The filename and workflow value must match.
  3. Add one declarative YAML trainer config under ./rl/config/; use <workflow>_<algorithm>_<backend>.yaml and point trainer_config to it as ../config/<file>.yaml.
  4. Reuse a generic backend under ./rl/i4h_rl/backends/. Add ./rl/i4h_rl/adapters/<workflow>.py only when the maintained Scene needs workflow-specific observation, action, registration, or evaluation conversion. Do not add workflow branches to cli.py, sim_server.py, or a package __init__.py.
  5. Train and evaluate the native checkpoint, export it into a reusable in-process or remote policy Task, add that Task to the Workflow's policy TaskGraph, and validate simulator success through the normal Workflow runner. Compare the runtime observation/action values with training, not only their dimensions and ordering: preserve coordinate frames, quaternion convention, normalization, action scaling, previous-action state, and reset semantics.
yaml
schema_version: 1
workflow: <workflow>
scene: <scene>
trainer: <rsl_rl-or-rlinf>
algorithm: ppo
adapter_module: i4h_rl.adapters.<workflow>
trainer_config: ../config/<workflow>_ppo_<backend>.yaml
train_task_id: <trainer-environment-id>
eval_task_id: <trainer-evaluation-environment-id>
task_description: <short instruction>
action_dof: <scene-action-width>
policy_action_dof: <policy-action-width>
state_dof: <state-observation-width>
cameras: []
default_num_envs: <positive-integer>
default_epochs: <positive-integer>
simulation:
  env_spacing: <positive-metres>
  presets: physx
  enable_cameras: false

Run ./train.sh rl show <workflow> and a training/evaluation --dry-run immediately. The CLI calls RLProfile.load in rl/i4h_rl/profile.py, validate_workflow_contract in contract.py, and the selected backend's validate_profile before launch. These checks cover profile fields and sources, backend support, dimensions, Scene cameras, and backend-specific task/config contracts. Require the applicable checks to exit successfully; if the checkout lacks these checks or a contract fails, stop before starting the simulator and report the failing check.

Dry-run

RSL-RL from scratch:

bash
./train.sh rl ultrasound_probe_reach \
  --num-envs 128 \
  --epochs 400 \
  --dry-run

RLinf foundation-policy post-training:

bash
./train.sh rl assemble_trocar \
  --model-path /absolute/path/to/gr00t-sft-checkpoint \
  --num-envs 64 \
  --epochs 1000 \
  --dry-run

These examples are training dry-runs. For evaluation use --eval --checkpoint <path> --dry-run; export rejects --dry-run, so check the profile with show and inspect the checkpoint and output destination before using the export command below. Inspect the resolved Scene, trainer, task IDs, observation/action dimensions, environment count, iteration/epoch count, config path, starting model when required, and explicit overrides. Keep user-requested resource values exact.

Show full SKILL.md (638 more words)Show less

Preflight and train

The lightweight rl uv project owns profile resolution and command orchestration. Its trainer configs are YAML and do not import Isaac Lab. RSL-RL backend integration runs in the Arena environment because its trainer and simulator dependencies are compatible. Set its runtime explicitly only when the prepared Arena environment is not appropriate:

bash
export I4H_RL_PYTHON=/absolute/path/to/arena-rsl-runtime-python

Train the compact RSL-RL example:

bash
./train.sh rl ultrasound_probe_reach \
  --num-envs 128 \
  --epochs 400

Resolve TRAIN_RUN from the timestamped run dir: path printed by the training command. Do not guess or select a run by recency.

Trocar uses two isolated processes on one host because GR00T N1.5/RLinf requires Python 3.11 while the current Isaac Sim/Arena runtime requires Python 3.12. The model controller defaults to tasks/gr00t_n15/.venv/bin/python on physical GPU 0, the simulator defaults to arena/.venv/bin/python on physical GPU 1, and observations/actions cross a local Unix-socket data bridge. Override those runtimes when needed:

bash
export I4H_RL_PYTHON=/absolute/path/to/gr00t-rlinf-python
export I4H_RL_SIM_PYTHON=/absolute/path/to/isaac-sim-arena-python

Train the GR00T/RLinf profile only with a compatible local starting checkpoint, the pinned RLinf checkout, and two visible GPUs:

bash
./train.sh rl assemble_trocar \
  --model-path /absolute/path/to/gr00t-sft-checkpoint \
  --num-envs 64 \
  --epochs 1000

Keep training in the foreground. Preserve the run directory and exact command on failure. Do not silently lower environment counts or epochs. The current RSL-RL launcher does not expose resume or distributed multi-GPU training; a second GPU is not used automatically. Trocar's two GPUs isolate the model and simulator processes rather than distributing one trainer across both GPUs.

Evaluate, export, and hand off

For an evaluation/export-only request, set TRAIN_RUN or the checkpoint argument from the user-supplied artifact; the timestamped paths below are examples, not instructions to pick the newest run. Evaluate the RSL-RL checkpoint over independent randomized episodes:

bash
TRAIN_RUN="$PWD/runs/ultrasound_probe_reach/YYYYMMDD_HHMMSS"

./train.sh rl ultrasound_probe_reach \
  --eval \
  --checkpoint "$TRAIN_RUN/model_final.pt" \
  --episodes 20

Export a simulator-compatible TorchScript actor, then validate the concrete Workflow Task:

bash
./train.sh rl export ultrasound_probe_reach \
  --checkpoint "$TRAIN_RUN/model_final.pt" \
  --output-dir "$TRAIN_RUN/exported"

./run.sh ultrasound_probe_reach --policy \
  --checkpoint "$TRAIN_RUN/exported/policy.pt" \
  --episodes 20

Successful RLinf training writes checkpoint.json in the run directory. It points to the native FSDP checkpoint and records the starting GR00T model, so evaluation accepts the run bundle directly without repeating --model-path. A successful evaluation must write evaluation.json with non-empty TensorBoard metrics and at least one trajectory. Export also discovers the resolved RLinf training config stored in that run bundle:

bash
TRAIN_RUN="$PWD/runs/assemble_trocar/YYYYMMDD_HHMMSS"

./train.sh rl assemble_trocar \
  --eval \
  --checkpoint "$TRAIN_RUN" \
  --video

./train.sh rl export assemble_trocar \
  --checkpoint "$TRAIN_RUN" \
  --output-dir "$TRAIN_RUN/exported"

./run.sh assemble_trocar --policy \
  --checkpoint "$TRAIN_RUN/exported" \
  --episodes 1

Treat the native trainer checkpoint as the training result and evaluate it before export. The GR00T inference export is runtime packaging for the remote Task, not a substitute for checkpoint evaluation. Require exit status 0, requested evaluation episodes when the trainer exposes them, non-empty metrics, expected checkpoint/export artifacts, and normal Workflow simulator success. Never claim success from loss curves or training exit alone.

Troubleshooting

Report the first missing runtime dependency, checkpoint path, registration failure, observation/action mismatch, non-finite loss, CUDA memory error, distributed/Ray/FSDP error, environment construction failure, or missing success artifact. Preserve the failed run directory and exact command. Retry once with the same configuration only after a diagnosed transient or missing-dependency failure has been resolved within the task. If it persists, or the failure is a contract mismatch, non-finite loss, or resource exhaustion, stop and report the blocker and preserved artifacts. Do not change the Scene objective or resource settings without user direction.

Limitations

The maintained profiles are ultrasound_probe_reach with RSL-RL and assemble_trocar with RLinf. RSL-RL resume, RSL-RL evaluation video, and distributed multi-GPU launch are not yet exposed. Trocar currently requires two visible local GPUs and its Unix-socket simulator bridge is single-host; a distributed simulator/controller deployment is not exposed. This skill does not perform supervised LeRobot fine-tuning or make unsupported workflows trainable.

Examples

  • Train the ultrasound probe reach policy with PPO and evaluate 20 episodes. → dry-run the RSL-RL profile, train from scratch, evaluate randomized episodes, export TorchScript, and validate the Workflow Task.
  • RL post-train the Trocar policy from my local GR00T checkpoint. → dry-run the RLinf profile, verify the G1/camera/action mapping, train, export a loadable GR00T checkpoint, and validate the remote policy Task.

Completion gate

Report the Workflow and Scene, trainer/profile/config, starting checkpoint when applicable, observation/action/reward/reset/termination contract, requested and completed resources, run directory, evaluation metrics, checkpoint and export artifacts, exact Workflow validation command and success rate, exit status, and any remaining runtime or hardware limitation.

© NVIDIA, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 5 other files in skills/i4h-workflow-train-rl of NVIDIA/skills.

  • SKILL.md
  • BENCHMARK.md
  • agents/openai.yaml
  • evals/evals.json
  • skill-card.md
  • skill.oms.sig

Open the folder on GitHubat commit 67a13c0

Used in 1 other repository

We found 1 copy of this SKILL.md (exact, near-identical or edited) in other folders, from 1 other GitHub owner. This page covers the copy in NVIDIA/skills, which our catalogue first saw on October 7, 2026.

Compare with similar skills

I4h Workflow Train Rl next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

I4h Workflow Train Rl compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
I4h Workflow Train Rl this skillNVIDIA/skills3.5k1 repos~3.8kAutomated safety check: PassApache-2.0
Esmfold2JimLiu/science-skills2274 repos~2.5kAutomated safety check: PassApache-2.0
MUSA GPU Training Optimizeropen-infra-skills/infra-skills141—~1.7kAutomated safety check: PassApache-2.0
Benchmark TuneMesh-LLM/mesh-llm3.5k—~1.6kAutomated safety check: PassApache-2.0
Cuda Kernel OptimizerKernelFlow-ops/cuda-optimized-skill212—~4.3kAutomated safety check: PassMIT
DGX Spark Training Gotchaswshobson/agents40k1 repos~2kAutomated safety check: PassMIT

Similar skills

  • Esmfold2

    JimLiu/science-skills

    Biohub ESMFold2 / ESMFold2-Fast all-atom co-folding (Candido et al.

    227 GitHub starsUsed in 4 repos~2.5k tokens
    AI & LLM EngineeringAuto-check passed
  • MUSA GPU Training Optimizer

    open-infra-skills/infra-skills

    Profiles, benchmarks and tunes AI training workloads on Moore Threads MUSA GPUs with a measurement-first process that keeps model behavior unchanged.

    141 GitHub stars~1.7k tokensUpdated 2 mo ago
    AI & LLM EngineeringAuto-check passed
  • Benchmark Tune

    Mesh-LLM/mesh-llm

    A skill your agent uses when running, debugging, interpreting, or documenting mesh-llm benchmark tune model-serving throughput trials, including choosing…

    3.5k GitHub stars~1.6k tokensUpdated today
    AI & LLM EngineeringAuto-check passed
  • Cuda Kernel Optimizer

    KernelFlow-ops/cuda-optimized-skill

    Iteratively optimize a CUDA/CUTLASS/Triton kernel only when strict on-device compilation, correctness, timing, and NCU evidence gates pass.

    212 GitHub stars~4.3k tokensUpdated 1 mo ago
    AI & LLM EngineeringAuto-check passed
  • Preflight checks and diagnosis for ten known failure modes of ML training on NVIDIA DGX Spark's GB10, spanning launch errors, memory, thermals, bandwidth and precision.

    40k GitHub starsUsed in 1 repo~2k tokens
    AI & LLM EngineeringAuto-check passed
  • Areno Develop Kernel

    inclusionAI/AReno

    Develop, optimize, debug, and validate an AReno CUDA, Triton, fused, attention, convolution, routing, or MoE operator.

    323 GitHub stars~498 tokensUpdated 13 days ago
    AI & LLM EngineeringAuto-check passed

More from NVIDIA/skills

All 380 skills in this repo
  • Official

    A skill your agent uses when the user wants to deploy, run, debug, tear down, or call the REST API of the RTVI-CV 2D detection / tracking microservice.

    3.5k GitHub starsUsed in 1 repo~4.5k tokens
    Auto-check passed
  • Official

    Generates, validates, compares and explains HOLOLINK_def.svh macro files for the HSB IP, using bundled Python scripts and asking before it writes anything.

    3.5k GitHub stars~2.9k tokensUpdated today
    Auto-check passed
  • Official

    Runs and validates an end-to-end Mission Control demo in a locally installed Isaac Sim, with a Nova Carter robot driven through a Python server.

    3.5k GitHub stars~4.8k tokensUpdated today
    Auto-check passed
  • Orchestrates defect image generation for PCBA, metal surface and glass inspection with NVIDIA Cosmos AnomalyGen on OSMO, from cold-start Day 0 to real-photo Day 1 labeling.

    3.5k GitHub stars~5k tokensUpdated today
    Auto-check: notes
  • Orchestrates video data augmentation and auto-labeling workflows on OSMO, from flow selection and preflight checks to submission, monitoring and output download.

    3.5k GitHub stars~4.7k tokensUpdated today
    Auto-check: notes
  • Official

    Runs NVIDIA TAO Data Services KPI analysis on object detection results, comparing predictions to ground truth and writing per-class precision, recall and AP to a CSV.

    3.5k GitHub stars~2.7k tokensUpdated today
    Auto-check: notes

Works with

Questions about I4h Workflow Train Rl

What does I4h Workflow Train Rl do?

A skill your agent uses when training, evaluating, or exporting Workflow policies with online RSL-RL or RLinf, including RL checkpoint and Workflow handoff. I4h Workflow Train Rl is an agent skill from NVIDIA/skills, published by the product's own GitHub organization. Use when training, evaluating, or exporting Workflow policies with online RSL-RL or RLinf, including RL checkpoint and Workflow handoff.

When should I use I4h Workflow Train Rl?

I4h Workflow Train Rl fits situations like: exporting Workflow policies with online RSL-RL; including RL checkpoint and Workflow handoff.

How do I install I4h Workflow Train Rl in Claude Code?

Run `npx skills add NVIDIA/skills --skill i4h-workflow-train-rl -a claude-code`. Or copy the skill folder (skills/i4h-workflow-train-rl in NVIDIA/skills) into .claude/skills/i4h-workflow-train-rl in your project. Claude Code loads it when a task matches its description.

How do I install I4h Workflow Train Rl in Codex?

Run `npx skills add NVIDIA/skills --skill i4h-workflow-train-rl -a codex`. Or copy the skill folder (skills/i4h-workflow-train-rl in NVIDIA/skills) into .agents/skills/i4h-workflow-train-rl in your project. Codex loads it when a task matches its description.

Can I use I4h Workflow Train Rl in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add NVIDIA/skills --skill i4h-workflow-train-rl -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/i4h-workflow-train-rl, .gemini/skills/i4h-workflow-train-rl, .github/skills/i4h-workflow-train-rl and .opencode/skills/i4h-workflow-train-rl in your project.

What does I4h Workflow Train Rl need to run?

Going by SKILL.md and its folder, I4h Workflow Train Rl needs the command-line tools its instructions call (git). Our summary lists: Python 3.

Does I4h Workflow Train Rl access the network?

SKILL.md names 1 domain. In commands or code: github.com; the agent is likely to contact it when it follows the instructions. This is read from the text; nothing was executed.

Is I4h Workflow Train Rl safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does I4h Workflow Train Rl use?

I4h Workflow Train Rl is published under the Apache-2.0 licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does I4h Workflow Train Rl use?

About 3.8k tokens (SKILL.md is roughly 15k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to I4h Workflow Train Rl?

Skills that share tags, products or a category with I4h Workflow Train Rl: Esmfold2 (JimLiu/science-skills, 227 stars), MUSA GPU Training Optimizer (open-infra-skills/infra-skills, 141 stars), Benchmark Tune (Mesh-LLM/mesh-llm, 3.5k stars) and Cuda Kernel Optimizer (KernelFlow-ops/cuda-optimized-skill, 212 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains I4h Workflow Train Rl?

NVIDIA (a GitHub organization, an official publisher) maintains it in NVIDIA/skills, which has 3,539 GitHub stars. The repository holds 380 skills in this directory. The repository was last updated on October 7, 2026.

Source: NVIDIA/skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.