Official agent skill

I4h Workflow Validate

by NVIDIA in NVIDIA/skills

Run the root-level workflow runtime policy or rule-based rollouts and verify simulator success.

OfficialApache-2.0Auto-check passed

Install I4h Workflow Validate

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

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

GitHub CLI
$ gh skill install NVIDIA/skills i4h-workflow-validate --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-validate .claude/skills/i4h-workflow-validate && 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-validate
GitHub stars
3.5k
Used in
1 other repo
Token cost
~2.6k tokens
SKILL.md length
1,164 words
Files
5
Skills in repo
380
Repo updated
First seen
Licence
Apache-2.0

At a glance

Run the root-level workflow runtime policy or rule-based rollouts and verify simulator success.

  • Works in 4 steps: Resolve the base checkout and a live… → Run the unified launcher in the… → Require the final episode success summary. → …
  • Local controllers
  • SKILL.md covers Purpose, Instructions, Resolve live support and Foreground execution rule, plus 6 more sections
  • Calls git and uv; reaches github.com

What it does

I4h Workflow Validate is an agent skill from NVIDIA/skills, published by the product's own GitHub organization. Run the root-level workflow runtime policy or rule-based rollouts and verify simulator success. Use for evaluation, checkpoints, or local controllers; do not use for replay or dataset annotation.

Its SKILL.md is about 2.6k tokens, which your agent loads only when the skill is triggered. The skill folder holds 5 other files (for example `BENCHMARK.md`, `evals/evals.json` and `skill-card.md`).

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

  • Local controllers
  • Do not use for replay
  • Dataset annotation

Example prompts

  • “/i4h-workflow-validate”

Requirements

  • Python 3

Workflow steps

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

  1. Resolve the base checkout and a live workflow run mode.
  2. Run the unified launcher in the foreground.
  3. Require the final episode success summary.
  4. Inspect visible behavior and every rollout artifact; for an authored or changed collision-excluding success rule, also verify the…

What it can do on your machine

Read from SKILL.md and the folder at commit 0e0d506. 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
    • uv

    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 Validate loads about 2.6k tokens when it runs. Until then it costs about 54 tokens; SKILL.md has 1,164 words of instructions outside code blocks.

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

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 0e0d506, republished under its Apache-2.0 licence (© NVIDIA). 1,164 words, ~2,593 tokens.

Download SKILL.mdSave it as .claude/skills/i4h-workflow-validate/SKILL.md (or your agent's skills folder). This skill also uses 4 other files; get the full folder from GitHub.
name
i4h-workflow-validate
description
Run the root-level workflow runtime policy or rule-based rollouts and verify simulator success. Use for evaluation, checkpoints, or local controllers; do not use for replay or dataset annotation.
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, simulation, evaluation

Validate a Workflow

Purpose

Run the selected workflow run mode through the unified launcher, inspect the completed recording, and report simulator success.

Instructions

  1. Resolve the base checkout and a live workflow run mode.
  2. Run the unified launcher in the foreground.
  3. Require the final episode success summary.
  4. Inspect visible behavior and every rollout artifact; for an authored or changed collision-excluding success rule, also verify the collision-negative case below.

Resolve live support

Use the maintained repository below or a source selected by the user or trusted project configuration. An inherited environment variable alone does not authorize another source. Honor requested revisions and preserve local changes.

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
git remote get-url origin || exit 2
git status --short || exit 2

Check that the reported origin is the intended source and review local changes before executing repository scripts. Stop on an unexpected source or unreviewed launcher changes. Then discover supported modes:

bash
./run.sh list

Treat the resolver above 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.

Treat ./run.sh list output as the complete authoritative workflow-by-mode table; it is dependency-light and faster than scanning workflow modules. Do not duplicate that mutable table in this skill. Map the user's natural name to a listed workflow id, then choose only a mode shown on that same line:

User intentRequired live modeLauncher argument
Ordinary learned-policy evaluationpolicy--policy
Requested or only available local controllerrule-based--rule-based
Explicit named alternative such as N1.7matching listed mode such as policy_n17--mode <name>

Inspect ./run.sh show <workflow> --mode <mode>, the workflow module, Scene manifest, and selected Task manifest when model, prompt, checkpoint, goal, or step-cap behavior matters.

Use precise readiness language:

  • Structurally valid: show, per-mode lint, and lint --all pass.
  • Launchable: the selected simulator mode starts and every required backend/checkpoint preloads.
  • Rollout-validated: the requested episodes complete and the recorded success evidence passes inspection.

Do not report “validated” without stating which level was actually reached.

Foreground execution rule

Keep run.sh as this agent's foreground tool call. Do not use a subagent, monitor task, shell backgrounding, nohup, tmux, or a detached process. Poll a yielded session until exit and inspect the final episode summary before responding. When the selected Task is remote, the policy backend subprocess internally owned by run.sh is expected; a simulator-compatible exported RSL-RL Task runs in-process.

Run visibly by default. If the user explicitly requests headless execution, or a documented environment constraint makes it necessary, say so before launch and include --headless; never switch to headless silently.

Use the requested episode count; if omitted, state that this is a one-episode smoke check and set N=1. Keep the launcher's per-episode --attempts 3 budget distinct from the bounded whole-run recovery below.

Policy:

bash
./run.sh <workflow> --policy \
  --episodes <N> --attempts 3 \
  --record verify.hdf5

Rule-based:

bash
./run.sh <workflow> --rule-based \
  --episodes <N> --attempts 3 \
  --record verify.hdf5

The launcher creates a unique canonical run directory and anchors the relative verify.hdf5 inside it. Resolve RUN_DIR from the ==> run dir ... line or machine-readable run.json; do not recreate the launcher's timestamp. Use --run-dir "$RUN_DIR" only when a caller-selected location must be shared with another stage; the launcher creates it. Absolute recording paths remain supported.

For another declared mode, use --mode <name>. For “300 timesteps,” pass --episode-steps 300.

Supplied-checkpoint preflight

Resolve the supplied checkpoint to an existing absolute path and pass that same path with --checkpoint. Run ./run.sh show <workflow> --mode <mode> to identify the selected policy Task. Read its manifest and loader under tasks/<project>/i4h_tasks/<project>/ and compare the checkpoint's model/export metadata with the required model, format, observation ordering/dimensions, and action mapping. Stop if the path or contract is unresolved; do not infer compatibility from a filename.

For a remote Task, use its declared backend's --preload-only option to load the checkpoint and exit before starting a simulator. For example, the gr00t_n15/assemble_trocar Task uses:

bash
uv run --project tasks/gr00t_n15 python -m i4h_tasks.gr00t_n15.server \
  --namespace assemble_trocar --preload gr00t_n15/assemble_trocar \
  --checkpoint /absolute/path/to/checkpoint --preload-only

For another Task, resolve its own backend project, server entrypoint, and Task id from the live declarations; do not reuse the example's model family. Require exit status 0 and no loader error. During the normal foreground rollout, also require ready for specs in the run directory's backend log and successful runtime observation/action contract checks. Successful loading alone does not establish Scene compatibility.

An in-process RSL-RL Task instead requires the exported TorchScript policy.pt. Pass it to the selected foreground policy command above; the Task loads it with torch.jit.load on entry and checks its output shape on the first policy step. Require successful loading and a valid first policy step before reporting it launchable, then complete the requested episodes. Do not pass a native trainer checkpoint to this runtime Task.

show, lint, and --dry-run are structural checks: they do not load policy checkpoints. If the loader/runtime check cannot run, report only the structural checks actually completed, not checkpoint compatibility or rollout validation.

Never raise the Scene manifest's cap. --episode-steps may only lower it. Remote inference waits do not consume simulation steps. Use a unique --namespace when another run of the same workflow is active.

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

Verify

Require exit status 0 and final N/N episodes succeeded. A failed attempt followed by a successful retry counts as a successful requested episode; report attempts and retries.

bash
RUN_DIR="<absolute run_dir from run.json or launcher output>"
uv run --project tools/dataset i4h-dataset inspect "$RUN_DIR/verify.hdf5" --segments

Check episode metadata, action/state widths, declared cameras, executed-node segments, and success flags against the Scene/Task contracts and final summary. Missing, corrupt, or inconsistent data blocks rollout validation; report the failed check. For visible runs, observe Scene/camera behavior and final task outcome. On failure, use the first actionable backend, contract, graph, or simulator error; never switch modes or increase the cap silently. After a crash, stop the retained foreground session and verify its child processes exit. ./stop.sh all affects every run in this checkout; use it only when all those runs are within the requested cleanup scope.

After authoring or changing a collision-excluding success rule, use the Scene's contact setup to test the configured body pair. Require non-zero filtered force, rejected success, and cleared collision history after reset. Record sensor names, force-matrix shape, maximum force, and outcome in the saved evidence. Initialization or zero force alone is insufficient. If the test cannot run, report the validation gap.

Troubleshooting

Correct the first actionable error within scope, then retry the whole run once with the same mode, cap, and episode count. If it recurs or cannot be fixed, stop and report it with the run directory. Per-episode attempts do not reset this whole-run retry budget.

Prerequisites

Require synced simulator assets and any backend/checkpoint declared by the selected run mode.

Limitations

Only modes from run.sh list are supported, and a runtime step override may lower but never raise the validated Scene cap.

Examples

  • Evaluate scissor pick and place for 2 episodes. → run policy mode for two successful episodes, record, inspect, and report attempts plus visible outcome.
  • Run surgical_reach_psm in rule-based mode for 1 episode. → use only the declared local-controller mode.

Completion gate

Report workflow, mode, model/checkpoint source, requested successes, attempts/retries, completion steps, visible outcome, HDF5 path and inspection, collision-negative/reset evidence when applicable, final exit status, and first unresolved failure if any.

© 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 4 other files in skills/i4h-workflow-validate of NVIDIA/skills.

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

Open the folder on GitHubat commit 0e0d506

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 Validate 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 Validate compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
I4h Workflow Validate this skillNVIDIA/skills3.5k1 repos~2.6kAutomated safety check: PassApache-2.0
Implementing Policy As Code With Open Policy Agentmukul975/Anthropic-Cybersecurity-Skills34k—~2.6kAutomated safety check: NotesApache-2.0
Codex Rules Referencecode-yeongyu/oh-my-openagent70k—~269Automated safety check: PassCustom licence
Rules Distillationaffaan-m/ECC274k2 repos~2.3kAutomated safety check: PassMIT
Policy Acknowledgementsickn33/agentic-awesome-skills47k1 repos~3.4kAutomated safety check: PassMIT
Commercial Policyalirezarezvani/claude-skills28k—~3.6kAutomated safety check: PassMIT

Similar skills

  • Implementing Policy As Code With Open Policy Agent

    mukul975/Anthropic-Cybersecurity-Skills

    Implements policy-as-code enforcement with Open Policy Agent (OPA) and Gatekeeper for Kubernetes and CI/CD pipelines, covering writing Rego policies, deploying OPA Gatekeeper as a Kubernetes…

    34k GitHub stars~2.6k tokensUpdated 1 mo ago
    DevOps & CloudAuto-check: notes
  • Codex Rules Reference

    code-yeongyu/oh-my-openagent

    Explains how the Codex Rules plugin injects project instructions and file-specific rules into a session, which rule files it reads and which settings control it.

    70k GitHub stars~269 tokensUpdated today
    Agent WorkflowsAuto-check passed
  • Rules Distillation

    affaan-m/ECC

    Scans installed skills for principles that recur across them and proposes rule-file changes: append, revise, add a section, create a file or leave as covered.

    274k GitHub starsUsed in 2 repos~2.3k tokens
    Agent WorkflowsAuto-check passed
  • Policy Acknowledgement

    sickn33/agentic-awesome-skills

    Policy acknowledgement register: employee, policy and version, sent and due dates, acknowledged date and flag, days overdue, reminder sent and status.

    47k GitHub starsUsed in 1 repo~3.4k tokens
    Auto-check passed
  • Commercial Policy

    alirezarezvani/claude-skills

    A skill your agent uses when designing or revising a company's commercial policy — the rules of engagement governing discounts off list price, approver thresholds, exception flows, and the deal…

    28k GitHub stars~3.6k tokensUpdated 1 mo ago
    DevelopmentAuto-check passed
  • Implementing GCP Vpc Firewall Rules

    mukul975/Anthropic-Cybersecurity-Skills

    Implements and audits GCP VPC firewall rules using gcloud, covering auditing overly permissive rules, creating restrictive ingress/egress rules, hierarchical firewall policies, and monitoring rule…

    34k GitHub stars~3k tokensUpdated 1 mo ago
    DevOps & CloudAuto-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

Questions about I4h Workflow Validate

What does I4h Workflow Validate do?

Run the root-level workflow runtime policy or rule-based rollouts and verify simulator success. I4h Workflow Validate is an agent skill from NVIDIA/skills, published by the product's own GitHub organization. Run the root-level workflow runtime policy or rule-based rollouts and verify simulator success.

When should I use I4h Workflow Validate?

I4h Workflow Validate fits situations like: local controllers; do not use for replay; dataset annotation.

How do I install I4h Workflow Validate in Claude Code?

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

How do I install I4h Workflow Validate in Codex?

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

Can I use I4h Workflow Validate 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-validate -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-validate, .gemini/skills/i4h-workflow-validate, .github/skills/i4h-workflow-validate and .opencode/skills/i4h-workflow-validate in your project.

What does I4h Workflow Validate need to run?

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

Does I4h Workflow Validate 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 Validate 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 Validate use?

I4h Workflow Validate 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 Validate use?

About 2.6k tokens (SKILL.md is roughly 10k 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 Validate?

Skills that share tags, products or a category with I4h Workflow Validate: Implementing Policy As Code With Open Policy Agent (mukul975/Anthropic-Cybersecurity-Skills, 34k stars), Codex Rules Reference (code-yeongyu/oh-my-openagent, 70k stars), Rules Distillation (affaan-m/ECC, 274k stars) and Policy Acknowledgement (sickn33/agentic-awesome-skills, 47k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains I4h Workflow Validate?

NVIDIA (a GitHub organization, an official publisher) maintains it in NVIDIA/skills, which has 3,534 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.