I4h Workflow Scene Edit
NVIDIAOfficialCreated by Isaac for Healthcare TeamDistributed by NVIDIA
- Skill
- Tool integration
- Automation and integrations
- Apache-2.0
- Medium risk
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
The i4h-workflow-scene-edit skill provides a structured process for modifying existing Isaac for Healthcare (i4h) workflow scenes. It enables users to perform live edits on assets, layouts, cameras, and task rules within a simulator session. The skill emphasizes a workflow where changes are applied to a live stage and only persisted to source files upon explicit user authorization. It integrates with Isaac Sim and requires adherence to established scene authoring patterns and asset catalogs.
What it does
- Opens existing i4h workflow scenes in a live-authoring simulator session.
- Applies incremental edits to assets, transforms, cameras, and physics properties.
- Provides helper scripts for common scene modifications like adding assets or adjusting views.
- Exports confirmed live-stage values into snapshots for review and source integration.
- Supports the validation of scene changes through linting and dynamic rollout checks.
- Ensures source files are updated only when the user explicitly requests to bake or persist changes.
When to use it
- When you need to refine the layout or configuration of an existing i4h workflow scene.
- When you need to adjust camera positions, robot placement, or asset properties in a live environment.
- When you want to test scene modifications before committing them to the underlying source code.
- When you need to update task contracts or success rules within an established workflow.
Advantages
- Allows for visual verification of scene changes before modifying source files.
- Maintains a clear separation between live-stage experimentation and source-code persistence.
- Leverages existing asset catalogs and authoring patterns to ensure consistency.
- Provides structured validation steps to catch errors before and after baking changes.
Usage examples
- “Edit the g1_tray scene to add a red cube at the origin and move the robot.”
- The agent opens the g1_tray scene in a live session, adds the cube, updates the robot position, and waits for further instructions.
- “Bake the current scene changes and stop the session.”
- The agent exports the live scene state, updates the owning source files, performs validation, and closes the simulator session.
Install
Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/nvidia/i4h-workflow-scene-edit/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip i4h-workflow-scene-edit.zip -d .agents/skills
Documentation by Isaac for Healthcare Team
Edit an i4h Workflow Scene
Purpose
Iterate on an existing Scene in one live simulator session, and persist the confirmed state only when explicitly asked to bake, save, or persist.
Instructions
Run the checkout resolver and inspect target ownership.
Start or reuse one bridge-backed live-authoring session by default and capture a visible baseline.
Read the minimal upstream guidance and apply each requested edit as its own observable live-stage transaction without changing source.
On an explicit bake/save/persist instruction, export the accumulated live state, inspect its resolved authoring facts, and have the coding agent edit the smallest owning sources.
Keep the session running for further prompts until the user explicitly says stop or exit.
Run static, persisted-visible, and affected dynamic validation when baking.
Resolve and inspect
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.
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
./run.sh list
./run.sh show <workflow>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.
Read DESIGN.md, the target workflow, Scene Python, scene manifest, embodiment manifest, and relevant task manifests. Use $ROOT/skills/i4h-workflow/references/repo-map.md to resolve ownership.
For a G1 face, walk, reach, or collision-sensitive success contract, read references/g1-reach-and-contact.md. Reuse its Tasks and Scene-owned footprint interface; do not generate workflow-specific locomotion helpers or hardcode object extents in the Workflow.
An open/run request without an edit means ./run.sh <workflow> --idle; do not invent source changes. An edit-scene request always means start or reuse ./run.sh <workflow> --live unless the user explicitly requests offline/no-live operation. Live authoring is the default and does not require confirmation. “Save,” “persist,” or “bake” means serialize the accumulated live-stage edits into their owning sources; without one of those words, leave source untouched. “Stop” or “exit” closes the session; if persistence was not requested, discard the live-only edits. Do not stop merely because one edit prompt completed.
Before adding or resizing an asset that already appears in a maintained scene, read references/existing-scene-assets.md. Reuse its known USD identity, authored scale, support height, physics role, and embodiment convention instead of rediscovering them from the raw USD. Treat owning Python as source of truth and use visual-language inspection only for bounded scene-specific refinement after the known baseline is visible.
Establish a visible baseline
Open the existing Scene as one persistent live-authoring session. Use the bridge only when I4H_LOCAL_AGENT=1: Local Agent commands share one serialized shell, so a foreground --live command would block every later edit transaction.
I4H_RUN_DIR="$(pwd)/runs/<workflow>/$(date +%Y%m%d_%H%M%S)"
if [ "${I4H_LOCAL_AGENT:-0}" = 1 ] && [ -x ./local-agent/bridge.sh ]; then
./local-agent/bridge.sh start <workflow> "$I4H_RUN_DIR"
else
./run.sh <workflow> --live --run-dir "$I4H_RUN_DIR"
fiThe fallback ./run.sh <workflow> --live must run through the host agent's persistent/yieldable foreground-session mechanism. Never launch that fallback as an ordinary blocking shell call and wait for it to exit before editing.
--live resolves the workflow's declared idle mode, enables isaacsim.code_editor.python_server on port 8226, and keeps the simulator open until explicitly stopped. Wait for port 8226 for at most ${I4H_AGENT_BRIDGE_TIMEOUT:-900} seconds (matching the bridge startup default), stopping sooner if the launcher exits. On timeout, report the run log and bridge blocker, stop only this failed session, and use the documented offline fallback only for work already authorized; source persistence still requires bake/save/persist.
Once ready, use the pinned upstream isaac-sim-remote client to inspect and modify the running stage. Keep every ordinary edit only in that live stage; do not change owning source yet. Accumulate later edit prompts in the same session. Only “bake,” “save,” or “persist” authorizes writing the confirmed live values into source. After baking, restart through run.sh, verify the persisted result matches the live stage, and stop when requested. An offline source edit followed by a reopen is not live authoring.
Preserve the live interpreter experience
Treat a compound prompt as an ordered stream of edits, not as one batch script. Run one bridge transaction for one user-visible operation, wait for its viewport update, inspect its result, and only then apply the next operation. For example, adding a table, two tools, two trays, and a robot is six live transactions. Never hide all requested edits inside one remote Python file or patch owning source while the user is waiting for the stage to change.
Use the one-operation helper from the workflow root for common edits:
arena/.venv/bin/python scripts/live_scene_edit.py add-known-asset \
--asset surgical_table \
--prim-path /World/envs/env_0/Table \
--position 0,0,0
arena/.venv/bin/python scripts/live_scene_edit.py add-cube \
--prim-path /World/envs/env_0/RedCube \
--position 0,0,0.3 \
--size 0.1 \
--color 1,0,0
arena/.venv/bin/python scripts/live_scene_edit.py scale-by \
--prim-path /World/envs/env_0/RedCube \
--factor 2
arena/.venv/bin/python scripts/live_scene_edit.py set-transform \
--prim-path /World/envs/env_0/Robot \
--position=-4.64,0,0.8 \
--rotation 0,0,0
arena/.venv/bin/python scripts/live_scene_edit.py set-view \
--eye 2.6,-7,3.4 \
--target=-1.8,0,0.75
arena/.venv/bin/python scripts/live_scene_edit.py camera-from-view \
--prim-path /World/envs/env_0/RoomCamera
arena/.venv/bin/python scripts/live_scene_edit.py capture-camera \
--prim-path /World/envs/env_0/RoomCamera \
--output-path "$I4H_RUN_DIR/room-camera.png"When a comma-separated vector begins with a negative number, bind it with = (for example, --position=-0.5,0.5,0.1) so the argument parser does not treat the value as another option.
<!-- markdownlint-disable-next-line MD013 -->
The helper intentionally accepts one operation per invocation, selects the affected prim, advances visible render updates, and prints the resulting world bounds. Prefer add-known-asset for catalogued Healthcare assets: it reuses canonical USD, scale, orientation, physics metadata, attached-camera metadata, embodiment metadata, and expected metric bounds, then rejects a result whose size differs by more than 20%. The g1 preset must create the standard head camera below the live robot preview; treat a missing camera prim as a failed robot edit, activate it, and verify its view before continuing. If no executable preset exists, warm-start from references/existing-scene-assets.md and its owning source before using generic add-usd. Both asset-add commands place the reference below a transform wrapper so a referenced asset's authored root transform cannot discard the requested live position, rotation, or scale. add-known-asset, add-usd, add-cube, and camera-from-view tag their prims for deterministic export; pass --name or --alias when the source/manifest name cannot be derived generically from the prim path. Inspect bounds before continuing. Use capture-camera for fast visible camera checks: it activates the requested camera, schedules a synchronous FileCapture, advances the renderer, and rejects an absent, empty, or stale output. Do not use the upstream asynchronous viewport screenshot helper in the persistent bridge session. Use activate-camera when capture is unnecessary and inspect for one-prim verification. Use raw isaacsim_send.py only for an operation the helper does not support, and still send one observable edit per call; record any untagged prim explicitly when baking.
Infer ordinary support relationships from the requested workspace and measured bounds. A robot or object intended for a table, cart, tray, pad, or floor must have its lower support bound aligned with that surface and its footprint plausibly contained by it; do not accept a floor-mounted, floating, or visibly interpenetrating placement merely because every named asset is present. Include those support relationships in the bounded visual rubric before baking.
Send a short progress update while the scene visibly changes. Do not spend extended time designing the eventual source representation before the first requested live edit. Inspect ownership and prepare baking after the live result exists.
Session lifecycle
On the first “edit scene” prompt, use
local-agent/bridge.shonly whenI4H_LOCAL_AGENT=1; otherwise launch./run.sh <workflow> --livethrough a persistent/yieldable host session. Use the bounded readiness wait above.On every later scene prompt, use
./local-agent/bridge.sh status <workflow>andrundir <workflow>for a managed Local Agent session, or the retained host session and run directory for a foreground launch. Verify it is the intended workflow; a listening port alone is insufficient. Reuse that session; do not reset or relaunch the Scene unless the requested change requires it.Apply each add/move/rotate/scale/material/camera operation separately to the same live stage, select the affected prim, advance the viewport, and verify it before continuing.
After adding a robot, verify every camera declared by its authoring preset. For G1, require the live
Robot/Asset/head_link/RobotHeadCampreview and bake with a registered G1 embodiment whoserobot_head_camsensor is exposed through theheadalias.Return control to the user after each prompt while leaving the simulator and bridge running.
Bake only on explicit authorization. Baking does not imply stop unless the user also says stop/exit.
On stop/exit without bake, close the session and leave source unchanged. A Local Agent session closes with
./local-agent/bridge.sh stop <workflow>.Use offline/source-first editing only when the user explicitly disables live mode or the bridge cannot operate. Report a bridge blocker before using that fallback; never silently substitute it.
Use upstream Isaac Sim skills
Read references/isaacsim-skill-routing.md, then load only the upstream skills required by the request. State the selection before editing. Use current upstream semantics for generic physics, cameras, sensors, USD, rendering, and spatial reasoning; integrate them through the closest current i4h Scene pattern.
Iterate live, then let the coding agent bake
Apply requested asset, layout, physics, camera, and transform changes through port 8226 first. For a compound prompt, preserve its order and inspect the live stage after each individual operation. Do not preemptively patch files merely because their eventual owner is known.
When explicitly asked to bake/save/persist, export the confirmed live values and resolve the reusable catalog facts without launching another simulator:
I4H_RUN_DIR="runs/<workflow>/<YYYYMMDD_HHMMSS>"
mkdir -p "$I4H_RUN_DIR"
arena/.venv/bin/python scripts/live_scene_edit.py export-scene \
--workflow <workflow> \
--root-path /World/envs/env_0 \
--output-path "$I4H_RUN_DIR/live_scene.json"
arena/.venv/bin/python scripts/authoring_info.py snapshot \
<workflow> "$I4H_RUN_DIR/live_scene.json"export-scene records every helper-managed asset, primitive, robot, and camera with its confirmed transform and camera optics. Keep that snapshot in the run directory as authoring evidence. Pass a previous run snapshot through --baseline only when a later live export needs to merge it: existing prims are re-read from the current stage, newly tagged prims are added, and removed prims are omitted. authoring_info.py is read-only; it validates the snapshot and returns code-ready catalog metadata and derived manifest capabilities immediately. It never generates or edits workflow code.
The coding agent then patches the existing asset, Scene, and manifest templates using the closest maintained source pattern. When committing is within the user's request, inspect git diff -- <owning-files> and stage only this task's changes, preserving unrelated edits. Commit only those owning sources; do not commit the exported authoring snapshot or treat it as a second Scene contract. Never copy a reusable USD path, canonical scale, mass, embodiment registry name, action contract, attached camera, or camera alias from memory: query authoring_info.py asset <preset> or the complete snapshot report, then use the catalog from owning source. Scene-specific names, placement, camera optics, and explicit overrides come from the snapshot.
Write only to the owning layer:
Bake assets, layout, physics, cameras, randomization, view aliases, actuation mapping, or reset hooks into Scene/asset/envcfg source.
Bake cross-boundary camera/object names, control rate, cap, or mode overrides into the scene manifest.
Bake mode composition and goal semantics into the workflow.
Bake reusable behavior into a Task.
Bake cross-process robot labels, calibration, or teleop devices into the embodiment manifest.
Bake a policy prompt, camera, observation, model, or training contract into the remote-task manifest.
Preserve the quaternion convention at each concrete API boundary. Do not add compatibility conversions or duplicate catalog facts across Python and YAML.
For a camera based on the current perspective, treat the viewport pose as an initial estimate. Compute and validate a stable live look-at from task-relevant bounds. On bake, add the confirmed env-local camera through the closest Scene pattern, declare it in the manifest, and verify every recording/policy consumer that should receive it.
Validate
./run.sh show <workflow> --mode <affected-mode>
./run.sh lint <workflow> --mode <affected-mode>
./run.sh lint --all
uvx ruff==0.5.2 check --config pyproject.toml <changed-python-files...>The Ruff version above matches the maintained checkout's .pre-commit-config.yaml; if its pin changes, use that exact pinned version. Run focused tests through each affected component's uv project. After the coding agent's static validation, reopen once with ./run.sh <workflow> --live, compare every requested visual change and declared camera against the exported snapshot, then stop when requested. Do not add extra restarts between export, source editing, and this persisted-visible check. Compare the persisted transforms, world bounds, and camera views with the live snapshot; static lint cannot catch a wrong quaternion convention.
Select dynamic modes from run.sh list and run.sh show that actually consume the changed Scene, Task, camera, observation, or success contract. Run those modes when physics, reset, actuation, policy observations, task behavior, or success changed. Idle is insufficient for those changes.
When success excludes collision, dynamic validation must include a forced-contact negative case and a fresh-reset recovery case from references/g1-reach-and-contact.md. Do not call the success rule validated if its configured contact signal has only ever returned false.
When cleanup is needed, stop the managed session with ./local-agent/bridge.sh stop <workflow> or interrupt its retained foreground session and verify its children exit. ./stop.sh all affects other runs in this checkout; use it only when all those runs are within the requested cleanup scope.
Troubleshooting
Fix manifest/workflow lint before launch. If the rendered result differs, compare the baseline, authored prims, bounds, cameras, and owning source. Make one focused correction and revalidate; if the same mismatch remains, preserve the snapshot and report the unresolved difference instead of looping or claiming validation.
Prerequisites
Require a supported existing workflow, complete simulator setup, and the relevant upstream Isaac Sim skills for generic scene semantics.
Limitations
Use i4h-workflow-create for a new workflow. Live idle validates stationary layout but not physics, actuation, policy observations, or success. A live session is process-local; export before stopping because unexported edits are lost if it dies. The live helper covers common assets, raw USDs, cubes, transforms, cameras, inspection, capture, and export; the coding agent handles source authoring and any semantics outside those utilities.
Examples
Add a red cube, move G1, add a room camera, bake all changes, and stop.→ keep one bridge-backed simulator session open, apply the three edits live in order, export and inspect one snapshot at “bake,” patch and statically validate the owning source, reopen once for persisted-visible validation, and stop.
Completion gate
Report upstream skills used, live session/bridge status, edits applied live, whether persistence was authorized, owning sources changed only during bake, static tests, live and persisted visible observations, camera checks, dynamic rollout results including collision-negative evidence when applicable, clean stop status, and any unresolved mismatch.
Files
- ATTRIBUTION.mdAdded by AutoGineer946 B
- BENCHMARK.md9.0 KiB
- LICENSELicence file added by AutoGineer11.2 KiB
- SKILL.md18.8 KiB
- evals/evals.json16.1 KiB
- references/existing-scene-assets.md8.0 KiB
- references/g1-reach-and-contact.md5.0 KiB
- references/isaacsim-skill-routing.md2.1 KiB
- skill-card.md4.1 KiB
- skill.oms.sig5.2 KiB
evals/evals.json
[
{
"id": "i4h-workflow-scene-edit-readme-g1-surgical-layout",
"question": "Edit my_workflow live.\n - Add a surgical table.\n - Add scissors and tweezers on the table.\n - Add two destination trays named tray_a and tray_b.\n - Add a Unitree G1 robot.\n - Move G1 so its base starts 2 m from the nearest table edge.\n - Keep G1 upright and facing the center of the table.\n - Set the perspective view to frame the room, then add a room camera from that view.\n - Visually verify that the tabletop, scissors, tweezers, and both trays are visible in at least one camera.\n - Bake all changes and stop.",
"expected_skill": "i4h-workflow-scene-edit",
"ground_truth": "This README authoring prompt builds and persists a complete G1 surgical work area in one ordered live scene-edit session while leaving behavior undefined.",
"expected_behavior": [
"routes to i4h-workflow-scene-edit",
"opens the existing scene visibly in render-only idle before authoring so the current perspective and baseline are observable",
"keeps one simulator window and Python-bridge session running while applying the edit bullets to the live stage",
"executes the table, each tool, each tray, G1 placement, perspective, and camera as separate observable bridge transactions rather than one batch script",
"selects each affected prim and advances the viewport before starting the next requested edit",
"reuses canonical known-asset presets for Healthcare USD scale and verifies metric world bounds instead of rediscovering scale for this scene",
"consults the existing-scene asset reference and owning source before measuring or rescaling a maintained asset",
"uses visual-language inspection only as a bounded scene-specific refinement after applying known scale and placement facts",
"uses the pinned upstream Isaac Sim physics, spatial, USD, camera, and validator skills for generic authoring semantics",
"starts from the blank Workflow without assuming a robot or policy",
"adds a surgical table with scissors, tweezers, tray_a, and tray_b as distinct scene objects",
"adds Unitree G1 from the explicit environment requirement instead of inheriting a robot from the blank scaffold",
"uses the G1 authoring preset so the live robot preview includes Robot/Asset/head_link/RobotHeadCam rather than adding only the raw robot USD",
"measures two metres from the nearest table edge rather than from the table center",
"keeps G1 upright at its normal authored root height and rotates it to face the table center",
"visibly verifies the tabletop, scissors, tweezers, tray_a, and tray_b through the head or room camera",
"derives and wires an env-local room camera from the perspective view",
"exports one deterministic live_scene.json snapshot only when bake is requested and resolves it with scripts/authoring_info.py",
"has the coding agent patch the owning asset, Scene, and manifest sources instead of running a workflow code generator",
"uses catalog metadata to replace the G1 preview with the registered G1 embodiment and expose robot_head_cam through the head alias",
"keeps live_scene.json as run-local authoring evidence and commits only the owning Scene, asset, and manifest sources",
"runs per-mode show and lint, lint --all, affected tests, and final persisted-visible validation",
"restarts the persisted workflow only once for persisted-visible validation",
"stops the simulator and bridge after successful bake validation"
]
},
{
"id": "i4h-workflow-scene-edit-g1-head-camera-regression",
"question": "Add a Unitree G1 robot to the open scene and show me its head-camera view. Keep the editor open.",
"expected_skill": "i4h-workflow-scene-edit",
"ground_truth": "Adding G1 through live authoring includes and visibly verifies the standard head camera instead of referencing only the robot geometry.",
"expected_behavior": [
"routes to i4h-workflow-scene-edit",
"reuses the existing live simulator and bridge session",
"adds G1 through the canonical g1 authoring preset rather than generic add-usd",
"creates the standard head camera at Robot/Asset/head_link/RobotHeadCam as part of the live G1 preview",
"treats a missing or invalid head-camera prim as a failed robot edit",
"uses the local synchronous capture-camera helper to activate and visibly verify the head-camera view without waiting on the upstream asynchronous screenshot helper",
"does not bake source because save, persist, or bake was not requested",
"keeps the simulator and bridge open"
]
},
{
"id": "i4h-workflow-scene-edit-deterministic-bake",
"question": "Bake the live changes in my_workflow, verify the persisted scene, and stop.",
"expected_skill": "i4h-workflow-scene-edit",
"ground_truth": "An environment is persisted by a coding agent from one deterministic snapshot, validated statically, reopened once for visible comparison, and stopped.",
"expected_behavior": [
"routes to i4h-workflow-scene-edit",
"exports helper-managed live prims to a run-local live_scene.json only because bake was explicitly requested",
"uses an explicitly supplied prior run snapshot as a baseline only when the current export needs to merge existing, added, moved, and removed prims",
"runs scripts/authoring_info.py with the exported snapshot to validate it and resolve catalog and manifest facts without launching Isaac Sim",
"derives known-asset and robot runtime facts from authoring_catalog.py instead of copying USD paths, canonical scales, masses, action contracts, or camera aliases from memory",
"has the coding agent patch the existing Scene asset source, Scene integration, and scene manifest while leaving the snapshot in the run directory",
"does not use a script to generate workflow-specific Python or YAML",
"keeps the generated workflow contract test valid as the workflow gains objects, cameras, a robot, tasks, or additional modes",
"reopens the persisted workflow only once, compares requested geometry and cameras with the snapshot, and then stops all simulator components"
]
},
{
"id": "i4h-workflow-scene-edit-reuse-known-scene-scale",
"question": "Add the existing surgical scissors asset to a new scene, then use the rendered view to fine-tune how it looks on the table.",
"expected_skill": "i4h-workflow-scene-edit",
"ground_truth": "Known asset facts provide the first live result immediately; visual review may make a bounded scene-local refinement but does not rediscover or silently replace canonical scale.",
"expected_behavior": [
"routes to i4h-workflow-scene-edit",
"reads the existing-scene asset reference and the listed owning source",
"uses the scissors preset with scale 0.006,0.0065,0.012 and verifies metric world bounds",
"places the tool relative to the known table support height before visual refinement",
"renders both a room view and a task-relevant camera view",
"keeps any automatic visual-language scale refinement within 20 percent per axis",
"stores a confirmed refinement as a scene-local override rather than changing the shared preset from one image",
"updates the shared preset only when trusted dimensions or world bounds justify a correction across consumers"
]
},
{
"id": "i4h-workflow-scene-edit-readme-define-behavior",
"question": "Continue authoring my_workflow with a rule-based G1 reach-table Task.\n - Behavior: have G1 walk forward and stop near the surgical table.",
"expected_skill": "i4h-workflow-scene-edit",
"ground_truth": "This prompt creates reusable G1 reach-table behavior without placing workflow-specific goal or success semantics inside the Task.",
"expected_behavior": [
"routes to i4h-workflow-scene-edit because my_workflow already exists",
"inspects the existing Scene, Workflow, task registry, and relevant manifests before choosing ownership",
"composes the reusable basic/g1_face_object and basic/g1_walk_to_object Tasks as separate graph steps instead of generating workflow-specific locomotion code",
"implements forward locomotion through the 50-D G1 WBC action contract instead of a teleop device",
"keeps the table collision footprint in the Scene-owned footprint_half_extents interface rather than hardcoding it in the Workflow",
"keeps goal and success semantics out of the reusable Task",
"adds focused CPU tests for the behavior and graph contract"
]
},
{
"id": "i4h-workflow-scene-edit-readme-define-goal",
"question": "Define the goal and success condition for my_workflow.\n - Goal: G1 reaches the surgical table.\n - Success: G1 stops upright within 0.3 m of the nearest table edge.",
"expected_skill": "i4h-workflow-scene-edit",
"ground_truth": "This prompt keeps the measurable reach-table goal and success condition in the existing Workflow while reusing the Task behavior created separately.",
"expected_behavior": [
"routes to i4h-workflow-scene-edit because this changes the existing workflow contract",
"inspects the existing Scene, Workflow, reach-table Task, and relevant manifests before editing",
"defines goal and success semantics in the Workflow rather than the reusable Task",
"uses the Scene-owned table footprint to measure 0.3 metres from the nearest table edge",
"requires G1 to be upright with low linear and angular velocity before success",
"configures the Scene-owned contact sensing needed to reject robot-table collisions",
"keeps scissors, tweezers, tray_a, and tray_b out of the goal and success condition",
"runs static validation plus a successful visible rollout and a forced-contact negative rollout"
]
},
{
"id": "i4h-workflow-scene-edit-readme-add-modes",
"question": "Add these run modes to my_workflow:\n - rule-based\n - trainable GR00T N1.6 policy\nValidate the rule-based rollout and statically validate all modes.",
"expected_skill": "i4h-workflow-scene-edit",
"ground_truth": "This continuation makes the G1 reach-table workflow ready for rule-based demonstration recording and GR00T N1.6 training by adding runnable rule-based and trainable policy contracts.",
"expected_behavior": [
"routes to i4h-workflow-scene-edit because this changes an existing workflow contract",
"adds only the explicitly requested rule-based and policy modes",
"configures rule-based mode with a G1 WBC action contract that can be recorded for training",
"configures a trainable GR00T N1.6 remote task with reach-table instruction, camera, observation, and train manifest facts",
"does not claim an untrained checkpoint already solves the reach-table task",
"updates the Workflow and only the manifests owned by rule-based and policy mode contracts",
"runs show and lint for every enabled mode plus lint --all",
"reports rule-based mode as rollout-validated only after a successful dynamic rollout",
"reports the untrained policy mode as structurally valid rather than rollout-validated"
]
},
{
"id": "i4h-workflow-scene-edit-live-session-no-bake",
"question": "Edit the current scene. Add a blue cube beside the table and keep the scene open; I will give you more edits later. Do not save yet.",
"expected_skill": "i4h-workflow-scene-edit",
"ground_truth": "Scene editing defaults to one persistent Isaac Sim Python-bridge session. The requested cube exists only in the live stage, the simulator remains open for later prompts, and no source changes occur without bake/save/persist.",
"expected_behavior": [
"routes to i4h-workflow-scene-edit",
"starts or reuses the workflow's live simulator session with the Python bridge enabled",
"adds and visually verifies the cube as one observable bridge transaction rather than patching source",
"does not bake or modify source because persistence was explicitly withheld",
"keeps the simulator and bridge running after completing the prompt"
]
},
{
"id": "i4h-workflow-scene-edit-compound-live-cadence",
"question": "Edit the current scene. Add a table, then a red cube on the table, double the cube size, and move the robot to the other side. Keep the editor open.",
"expected_skill": "i4h-workflow-scene-edit",
"ground_truth": "Every requested change is visibly applied to the same open stage in prompt order. The agent does not collapse the edits into one remote script or patch source.",
"expected_behavior": [
"routes to i4h-workflow-scene-edit",
"starts or reuses one live simulator and bridge session",
"adds the table as one bridge transaction and verifies its world bounds",
"adds the red cube as the next bridge transaction and makes the affected prim visible in the editor",
"doubles the existing cube scale in a separate bridge transaction",
"moves the existing robot in a separate bridge transaction after measuring the requested spatial relation",
"does not combine multiple requested edits into one remote Python file",
"does not bake source because save, persist, or bake was not requested",
"keeps the simulator and bridge open"
]
},
{
"id": "i4h-workflow-scene-edit-table-red-cube",
"question": "Edit the scissor pick-and-place scene to replace the scissors with a red cube and save the scene.",
"expected_skill": "i4h-workflow-scene-edit",
"ground_truth": "This README skill-table prompt routes to scene-edit and bakes because the prompt says save the scene.",
"expected_behavior": [
"routes to i4h-workflow-scene-edit",
"uses the closest source scene pattern and selected upstream generic guidance",
"replaces the requested prop with a red cube",
"keeps source changes because save is explicit",
"runs static and visible scene validation"
]
},
{
"id": "i4h-workflow-scene-edit-readme-robotic-instrument-reach",
"question": "Edit robotic_instrument_reach live.\n - Add a table and a surgical training pad.\n - Add a Franka-style arm with a probe attached to its tool frame.\n - Add a target marker on the pad and a room camera.\n - Frame the arm, probe, pad, and target in the camera view.\n - Visually verify that the arm, probe, pad, and target are visible in the room camera.\n - Bake all changes and stop.",
"expected_skill": "i4h-workflow-scene-edit",
"ground_truth": "This README RL-authoring prompt visibly authors and persists the physical robotic_instrument_reach Scene while leaving the RL objective and policy ownership to later stages.",
"expected_behavior": [
"routes to i4h-workflow-scene-edit",
"opens the existing blank robotic_instrument_reach Scene visibly and applies each requested edit through the live bridge",
"adds a table, surgical training pad, target marker, Franka-style arm, attached probe, and room camera",
"frames and visibly verifies the arm, probe, pad, and target",
"bakes the owning asset, Scene, and manifest sources only after the requested live result is verified",
"reopens the persisted Scene once for visible comparison and stops the simulator",
"does not add the RL objective, trainer profile, checkpoint, policy Task, or Workflow policy mode"
]
},
{
"id": "i4h-workflow-scene-edit-readme-add-robotic-policy-mode",
"question": "Add that Task as the policy run mode of robotic_instrument_reach.",
"expected_skill": "i4h-workflow-scene-edit",
"ground_truth": "This README continuation edits the existing Workflow contract so its policy TaskGraph invokes the already-created RoboticInstrumentReach policy Task.",
"expected_behavior": [
"routes to i4h-workflow-scene-edit because this changes an existing Workflow contract",
"resolves the previously created reusable rsl_rl/robotic_instrument_reach Task",
"adds policy mode without duplicating policy inference in the Workflow",
"keeps the idle mode and existing Scene intact",
"runs show and lint for the policy mode, lint --all, and affected contract tests",
"reports structural validity separately from the later normal-runner rollout validation"
]
}
]
Requirements and compatibility
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Needs: Needs Python
Security
What our scanner noticed· Medium risk
- Large base64-encoded blobs
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Created by
- Isaac for Healthcare Team
- Publisher
- NVIDIA (Official)
- Distributed by
- NVIDIA
- Source
- NVIDIA/skills · skills/i4h-workflow-scene-edit · commit fce3cca
- Licence
- Apache License 2.0 (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE-APACHE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
AutoGineer is not affiliated with or endorsed by Isaac for Healthcare Team or NVIDIA.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download i4h-workflow-scene-edit.zip