
i4h Workflow - Create Env
OfficialFreeEfficiently scaffold new agentic environments for workflows.
Free · Opens the source repo
What i4h Workflow - Create Env does
The i4h Workflow - Create Env skill is designed for developers and designers working with agentic environments in the Isaac Sim framework. This skill allows users to create a new environment by forking an existing one, providing a structured approach to environment scaffolding. It focuses on generating the necessary YAML configuration, assets, tasks, and runtime files required to set up a functional environment without delving into scene edits or additional visual enhancements. This makes it particularly useful for those looking to quickly prototype and test new environments based on existing patterns.
To use this skill effectively, users should have a clear understanding of the source environment they wish to fork. The skill provides a systematic workflow that guides users through resolving components such as environment IDs, robot owners, and policy stacks. By following the outlined steps, users can ensure that the new environment is minimal yet runnable, allowing for rapid iteration and development. The skill emphasizes validation checks to ensure that the environment builds correctly and meets the necessary criteria before proceeding to more complex scene edits.
This skill is particularly beneficial for teams working on robotics and simulation projects where quick iterations of environments are crucial. It streamlines the process of setting up new environments, allowing developers to focus on functionality and performance rather than getting bogged down in the details of scene creation. It is an essential tool for those looking to enhance their development workflow in the context of agentic environments.
However, it is important to note that this skill should not be used for polishing existing scenes or making visual enhancements, as it is strictly focused on the scaffolding of new environments. For tasks that require scene editing or the addition of new visual elements, users should leverage the i4h Workflow - Scene Edit skill instead. This clear delineation ensures that users can choose the right tool for their specific needs, optimizing their workflow and productivity.
When to use it
Use this skill when you need to create a new agentic environment quickly by forking an existing one without scene edits.
When not to use it
Avoid using this skill for enhancing existing scenes or adding visual elements; it is not designed for that purpose.
What you can build with it
Creating a New Robotics Environment
Use this skill to quickly scaffold a new robotics environment based on an existing setup, allowing for rapid testing and iteration.
Prototyping for Simulation Projects
Ideal for simulation developers needing to prototype environments efficiently without the overhead of scene editing.
Setting Up for New Tasks
When introducing new tasks into an existing framework, this skill helps in creating the necessary environment structure swiftly.
How to install i4h Workflow - Create Env
View source1. Install with the skills CLI
npx skills add nvidia/skills/i4h-workflow-create --agent claude-code2. Or install it manually
Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.
Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs
Inside SKILL.md
Written by nvidiai4h Workflow - Create Env
Purpose
Create the first runnable version of a new workflows/agentic environment by forking the closest existing env. Keep this skill focused on env scaffolding: YAML, assets, task, env class, runtime, and validation. Do not use this skill to polish an existing scene, add optional props/cameras, or bake bridge edits; use [[i4h-workflow-scene-edit]] for that.
Base Code
Resolve and work from the i4h-workflows root:
ROOT="${I4H_WORKFLOWS:-$(git rev-parse --show-toplevel 2>/dev/null)}"
if [ ! -d "$ROOT/workflows/agentic" ]; then
ROOT="${I4H_WORKFLOWS:-$HOME/i4h-workflows}"
[ -d "$ROOT/workflows/agentic" ] || git clone https://github.com/isaac-for-healthcare/i4h-workflows "$ROOT"
fi
export I4H_WORKFLOWS="$ROOT"; cd "$ROOT"
What to Load
Before editing, load only the references that match the request:
- Always load
skills/i4h-workflow/references/repo-map.md. - Always load
skills/i4h-workflow-create/references/create-contract.md. - Load
skills/i4h-workflow-create/references/env-authoring-patterns.mdto choose the source env, robot owner, policy stack, and YAML pattern. - Load
skills/i4h-workflow-create/references/hybrid-layout-rules.mdonly for hybrid scene+robot envs, G1 footprint/table-height work, catalog USD scale, or support-surface layout. - Load a recipe file only when the prompt matches it exactly enough to avoid re-deciding components.
Recipe routing:
| Prompt shape | Reference |
|---|---|
Surgical tool sorting using G1 based on scissor_pick_and_place | skills/i4h-workflow-create/references/g1-surgical-tool-sort.md |
Create Contract
Create the env shell first. A normal create task should produce exactly these surfaces unless the chosen existing pattern requires an explicit exception:
| Surface | Path |
|---|---|
| Env YAML | workflows/agentic/config/environments/<env>.yaml |
| Assets | workflows/agentic/arena/arena/assets/<env>.py |
| Task | workflows/agentic/arena/arena/tasks/<env>.py |
| Env class | workflows/agentic/arena/arena/environments/<env>_environment.py |
| Runtime | workflows/agentic/arena/arena/runtimes/<env>.py |
Keep all paths repo-root relative and keep the workflows/agentic/ prefix. Do not create a new policy package, README, docs, or shared-module edits unless the user explicitly asks and the policy stack truly needs it.
Workflow
- Resolve components: env id, source env, scene/assets source, robot owner, policy stack, model/checkpoint, cameras, objects/destinations, success rule.
- Inspect the selected source env YAML, env class, assets, task, runtime, and policy stack files before writing code.
- Fork the closest working pattern. Preserve inline-scene vs registry-asset style; do not invent a new architecture.
- Keep the first version minimal and runnable. Optional visual polish, extra props, new cameras, and layout changes happen through scene-edit after the env exists.
- Run validation and fix source until the env builds and the rendered scene is visually sane.
For an exact recipe match, do not re-derive the architecture after loading the recipe. Read only the source files the recipe names, skip large source runtime files when the recipe says the runtime is a re-export, then write the five contract files immediately. Do not inspect third-party framework internals unless a validation error requires it.
Plan shape:
Env id:
Source env / recipe:
Scene/assets source:
Robot owner:
Policy stack + model/checkpoint:
Objects/destinations:
Success rule:
Files to create:
Validation:
Hard Rules
- Env YAML is the source of truth for robot, policy, cameras, task text, dataset mapping, and train defaults.
- Fork from the nearest existing implementation. For hybrid envs, robot integration comes from the robot owner and scene construction comes from the scene source.
- Sorting tasks need at least two object types, at least two destinations, and a success rule that fails swapped placements.
- Static/kinematic destination props may not expose
.data.root_pos_w; success checks must fall back toentity.get_world_poses(). - Functions referenced by
func=inside config classes must be defined above those classes. - G1 WBC envs need footprint clearance and matched ground/base-height values; load
hybrid-layout-rules.mdbefore choosing those numbers. - Additional fixed cameras are normally scene-edit/bake work. If a create prompt explicitly requires a policy/dataset camera, load the scene-edit camera and bake references and wire every surface in one pass.
Validation
Run these static checks:
python -m py_compile <changed-python-files>
workflows/agentic/policy/run.sh --list-envs
workflows/agentic/arena/run.sh --env <env> --dry-run
workflows/agentic/policy/run.sh --env <env> --dry-run
Then run the real build/visual gate from skills/i4h-workflow-create/references/create-validation.md. --dry-run is shallow: it does not prove the task/assets instantiate or the scene is visually usable. Do not report a new env as ready until the bridge reaches ready, key objects are valid, a viewport capture has been inspected, and the bridge is stopped with:
workflows/agentic/arena/stop.sh --env <env>
If Isaac Sim cannot launch on the host, report that as a blocker and include the static check results; do not present static-only as success.
Hand Off to Scene Edit
After the env shell passes create validation, use [[i4h-workflow-scene-edit]] for:
- Adding, moving, resizing, or replacing objects/assets.
- Adding fixed room/overhead/wrist cameras.
- Live bridge edits.
- Baking live changes into source.
- Running
local-agent/validate-bake.sh.
The scene-edit workflow owns object snippets, camera snippets, bridge endpoint details, and bake checklists so this create workflow stays small.
Prerequisites
- Workflow setup has completed via [[i4h-workflow-setup]];
.venv, third-party checkouts, and Isaac Sim launch support are present. - The source env and target env id are known, or the prompt provides enough information to choose them from existing patterns.
- Bridge validation runs on a GPU host that can launch Isaac Sim.
Limitations
- Create one env per invocation.
- Fork existing patterns; do not invent a new policy stack or shared framework.
- Use scene-edit for post-create polish, optional props, camera baking, and source persistence of live edits.
--dry-runis not a substitute for the bridge build and visual validation gate.
Troubleshooting
- Missing setup: if
.venv, third-party checkouts, orrun.shentrypoints are missing, run [[i4h-workflow-setup]] first. - Env not listed: check that the YAML exists at
workflows/agentic/config/environments/<env>.yamland all files use the fullworkflows/agentic/repo-root prefix. - Build fails after static checks pass: inspect the first Isaac/arena stack trace; common causes are bad cfg kwargs, a helper defined below a config class, or an observation pointing at a missing sensor.
- Scene looks wrong: fix source or use scene-edit to live-adjust and bake; do not report success from static checks alone.
Final Response
Report the env id, source choices, files created, validation commands and results, capture paths, and any blocker. Do not commit changes unless the user explicitly asks.
Frequently asked questions about i4h Workflow - Create Env
Similar skills
Spring Boot Testing
Master testing techniques for Spring Boot 4 applications.
GitHub Issues
Manage GitHub issues efficiently with MCP tools.
Geofeed Tuner
Optimize your IP geolocation feeds in CSV format.
Batch Files
Master Windows batch scripting for automation and task management.
Adobe Illustrator Scripting
Automate your Illustrator workflows with ExtendScript.
Plugin Structure
Create and organize Claude Code plugins effectively.
