Imported from nvidia/skills (
skills/i4h-workflow/SKILL.md). Install upstream withnpx skills add nvidia/skills --skill i4h-workflow. Copyright stays with the author (Apache-2.0).
i4h Workflows
Purpose
Orient the user from live repository facts, then hand execution to the narrowest stage skill.
Instructions
- Run the base-checkout resolver.
- Read live support and
DESIGN.md. - Use only current architecture facts in the answer.
- Use the narrowest stage skill for execution.
Resolve the checkout
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"
fi
export I4H_WORKFLOWS="$ROOT"
cd "$ROOT"
Treat this resolver as part of the skill contract: a hosted copy may run outside the base repository, so never assume the current checkout contains workflows/i4h_workflows. I4H_WORKFLOWS_REPO_URL selects the clone source. When I4H_WORKFLOWS is unset, derive the fallback directory from that URL; set I4H_WORKFLOWS only to reuse or choose a specific destination. Never replace an existing checkout.
Inspect before answering
Read ./DESIGN.md for architecture and skills/i4h-workflow/references/repo-map.md for ownership. Discover current support instead of copying a static table:
./run.sh list
If discovery fails because setup is incomplete, report that limitation and route to i4h-workflow-setup.
Explain the design
Keep the summary precise:
- A Scene owns the simulated world, assets, embodiment, cameras, randomization, adapters, and reset hooks.
- A Task owns one reusable capability. It reads
ctx.scene, writesctx.act, and never advances the simulator. - A Workflow selects one Scene, exposes run-mode-specific
TaskGraphbuilders, and owns goal semantics. A run mode answers how that workflow should run; code and CLI use the shorter termmode. - The Engine schedules graph nodes; the shared
SimulationRunneralone resets, steps, renders, records, retries whole episodes, and prints run summaries. - Online RL is a separate training lifecycle: its trainer owns vectorized stepping and returns a checkpoint to the normal policy Task and
SimulationRunnervalidation path. - Simulator-compatible exported RSL-RL actors may run as in-process Tasks; incompatible foundation-model policy stacks remain remote.
- Remote policy stacks run out of process and communicate over Zenoh; offline dataset tools remain independent of the simulator.
- Python owns behavior. Manifests carry facts across dependency boundaries.
Do not describe retired environment YAMLs, per-mode runners, or separate policy/Arena launchers.
Route the next action
| Goal | Skill |
|---|---|
| Install, sync, or repair dependencies | i4h-workflow-setup |
| Create a new workflow/environment | i4h-workflow-create |
| Edit an existing scene, camera, task, or success rule | i4h-workflow-scene-edit |
| Record demonstrations | i4h-workflow-dataset-teleop |
| Replay HDF5 | i4h-workflow-dataset-replay |
| Augment HDF5 | i4h-workflow-dataset-mimic |
| Grade/filter HDF5 with a VLM | i4h-workflow-dataset-annotate |
| Convert HDF5 to LeRobot | i4h-workflow-dataset-convert |
| Inspect LeRobot in a browser | i4h-lerobot-viz |
| Fine-tune a manifest-backed policy task | i4h-workflow-finetune |
| RL post-train a supported policy in simulation | i4h-workflow-train-rl |
| Run policy or rule-based rollouts | i4h-workflow-validate |
| Run the maintained complete pipeline | i4h-workflow-e2e |
For Stop all, do not load a stage skill. Run ./stop.sh all from the repository root and report the stopped process count.
Troubleshooting
If discovery fails, verify the resolved checkout and run setup. If a mode is absent, report it as unsupported.
Prerequisites
Require a readable base checkout or network access to clone it.
Limitations
This router does not install, author, simulate, process data, train, or evaluate.
Examples
What does the i4h workflow include, and where should I start?→ inspect live support, summarizeDESIGN.md, and recommend one stage skill.
Completion gate
Answer with the live workflow/mode list, a short architecture summary, and one concrete next skill. If the requested workflow or mode is absent from run.sh list, say it is unsupported instead of inventing a command.