What does this skill do, and when should you use it?
This skill creates the first runnable version of a workflows/agentic environment by forking the closest existing environment. It covers YAML, assets, tasks, the environment class, runtime, and validation. It is not intended for scene polishing, optional props or cameras, or baking bridge edits. Full validation requires a GPU host that can launch Isaac Sim.
Resolves the workflow root and clones i4h-workflows with Git when needed; loads repository, contract, and authoring references; inspects the source environment YAML, environment class, assets, task, runtime, and policy stack; creates the environment YAML, asset Python file, task Python file, environment class, and runtime; then runs Python compilation, environment listing, arena dry-run, and policy dry-run checks, followed by the required real build, bridge readiness, object validation, and viewport-capture gate.
- An I4H workflow developer needs to create a new task environment from the closest working implementation.
- An environment author needs to preserve an existing inline-scene or registry-asset architecture while scaffolding a new environment.
- A robotics developer needs the standard YAML, assets, task, environment-class, and runtime surfaces generated together.
- A team with a GPU Isaac Sim host needs to validate that a newly scaffolded environment builds and renders sensibly.
How do you install this skill?
- Do not treat static checks, dry-runs, or the attached evaluation report as proof that an environment was built successfully; real bridge and visual validation require a usable GPU/Isaac Sim host.
- Review pinned revisions, dependency integrity, and execution permissions before cloning and running the external i4h-workflows repository; obtain explicit confirmation and keep a recoverable copy before live edits or baking.
- The core workflow depends on overseas GitHub access and NVIDIA/Isaac Sim infrastructure; separately verify mainland-China network reachability, model retrieval, and mirror alternatives.
- Add Instructions, Examples, a changelog, maintenance ownership, and an update path, and clarify the relationship between the Apache-2.0 skill license and NOASSERTION repository metadata.
- Shell / CLI
- Network access
- Local filesystem
GitPythonIsaac SimGPU host
Install it from the NVIDIA/skills collection with: npx skills add nvidia/skills --skill i4h-workflow-create --yes. Alternatively, run npx skills add nvidia/skills and select the skill and destination interactively. The source does not document a specific installation directory.
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/NVIDIA/skills.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/skills/i4h-workflow-create" ~/.claude/skills/
rm -rf "$tmp"Generated from the source repository and skill path; it copies only this skill's folder. If the author's install steps above differ, follow those first. To scope it to one project, replace ~/.claude/skills with that project's .claude/skills.
How do you use this skill?
After i4h-workflow-setup has provided .venv, third-party checkouts, and Isaac Sim launch support, ask the agent to create a new workflows/agentic environment. Provide an environment ID, source environment or enough information to choose one, scene and asset source, robot owner, policy stack, model or checkpoint, cameras, objects, destinations, and success rule. The skill follows the nearest existing pattern and creates the environment surfaces. The documented checks include py_compile, workflows/agentic/policy/run.sh --list-envs, arena --dry-run, and policy --dry-run.
What are this skill's strengths and limitations?
- Keeps the scope focused on new-environment scaffolding.
- Defines five core output surfaces and standard validation commands.
- Uses the nearest working implementation instead of inventing a new architecture.
- Includes concrete constraints for sorting tasks, static destinations, G1 WBC environments, and cameras.
- Creates one environment per invocation.
- Requires a known source environment or enough design information to select one.
- Full build and visual validation require a GPU host capable of launching Isaac Sim.
- A dry-run does not prove that tasks, assets, or the scene instantiate correctly, and the skill provides no validation results itself.
- Scene polish, extra props, camera baking, and bridge edits belong to the separate scene-edit workflow.
How does this skill compare with similar options?
Side by side with related skills; every score comes from the same FSRS standard.
| Skill | FS score | Stars | Last updated | License |
|---|---|---|---|---|
| I4H Workflow Environment Creator this page ✓ NVIDIA · Official | 50 · Use with care | ★ 3.6k | 13d ago | Apache-2.0 |
| Isaac for Healthcare Dataset Replay ✓ NVIDIA · Official | 48 · Use with care | ★ 3.6k | 13d ago | Apache-2.0 |
| I4H Scene Editing Workflow ✓ NVIDIA · Official | 52 · Use with care | ★ 3.6k | 13d ago | Apache-2.0 |
| Isaac for Healthcare Workflow Validator ✓ NVIDIA · Official | 52 · Use with care | ★ 3.6k | 13d ago | Apache-2.0 |
| I4H Policy Fine-Tuning ✓ NVIDIA · Official | 48 · Use with care | ★ 3.6k | 13d ago | Apache-2.0 |
How did FollowSkills review this skill?
The skill scopes creation work, forbids unnecessary shared edits, avoids commits, and discloses cloning an external repository, running scripts, launching Isaac Sim, and using a bridge service. However, external code is cloned and executed by default, live bridge edits and baking have external effects, and there is no explicit stepwise confirmation, isolation, rollback plan, or dependency-integrity verification, so points are deducted.
The documentation provides detailed paths, configuration contracts, static checks, bridge validation, diagnostics, and stop commands, including instructions to report blockers. However, key paths depend on a virtual environment, third-party checkouts, GPU access, Isaac Sim, and an external repository; no committed test suite or independently reproducible execution evidence covers the main paths, so the static ceiling applies.
The intended use, non-fit boundary for scene editing, recipe routing, and required inputs are fairly clear. However, Chinese-language support is not described, and the core workflow depends on GitHub, Isaac Sim, and a GPU host, with insufficient evidence of fit for mainland-China network and infrastructure conditions, so points are deducted.
The skill has a version, Apache-2.0 license, author metadata, layered references, prerequisites, limitations, validation guidance, and troubleshooting. The benchmark explicitly reports missing Instructions and Examples sections; maintenance ownership, changelog, stable version policy, and update path are incomplete, while repository license metadata is NOASSERTION, so points are deducted.
The creation contract, five-file output surface, configuration requirements, task success rule, and validation gate provide directly actionable scaffolding guidance, and the included three-task evaluation report indicates some positive-task benefit. However, the sample is only three tasks with no negative-trigger set, the report is not independently reproducible evidence, and real usefulness still depends on heavyweight Isaac Sim bridge validation; the static ceiling of 7 applies and uncertainty reduces the score.
The selected skill and its referenced files are auditable and include commands, checks, evaluation data, and known static findings. However, there are no independently verifiable third-party links, committed key-path tests, or corroboration from multiple evidence sources, so only limited credit is justified.
Open a dimension to read why it scored that way
Evidence confidence：Low — Mostly static review, author material or a limited demo; useful for discovery, not high-risk decisions.
See the full review method →