I4H Scene Editing Workflow
Edit existing Isaac for Healthcare scenes live through a controlled bridge session.
The skill clearly separates live edits from baking, requires explicit user intent for persistence, scopes scripts/logs/captures, and specifies stop, rollback, and error-reporting behavior. However, it can automatically clone an external repository, execute trusted Python, and issue HTTP bridge actions; permission and data-flow boundaries are incomplete, and the license metadata is NOASSERTION, so points are deducted.
The workflow, endpoints, failure rules, and important physics pitfalls are documented, with static-check commands included. However, Isaac Sim, GPU, external repository, and unbundled base-code dependencies prevent key-path reproduction from the supplied files; the static-review ceiling therefore applies and points are deducted.
The audience, scene-edit scenarios, live/bake triggers, and non-fit boundary for new-environment creation are reasonably clear. However, use requires a specific Isaac for Healthcare setup, GPU, and bridge; Chinese interaction, network reachability, and broader environment-variance guidance are not addressed, so points are deducted.
The skill provides a version, Apache-2.0 declaration, author, references, limitations, troubleshooting, and maintenance clues, with generally progressive structure. It lacks a clear changelog, pinned dependencies, and explicit maintenance commitment; the skill-card credential/output descriptions are not fully aligned with the frontmatter, and the static report notes missing Instructions and Examples sections, so points are deducted.
It covers object, camera, task, and randomization edits and provides directly usable commands, API calls, and configuration patterns. The committed benchmark reports three passing tasks, but it is not execution performed in this review; Codex correctness was 58% and effectiveness 36%, and results still require environment-specific work and human visual validation, so the score remains limited.
The material includes endpoint contracts, request examples, verification criteria, static checks, and a benchmark report, providing limited auditability. It lacks a skill-specific runnable test suite, CI coverage, or independent corroboration; key conclusions remain largely author-reported, so the static calibration limits the score.
- Before execution, review and pin the external repository revision, dependencies, and network scope; automatic cloning and trusted Python bridge execution may create unexpected external effects.
- Do not treat the benchmark report as independent reproduction evidence for this static review; camera behavior, robot stability, and post-bake results still require validation in the target environment.
- Align the credential requirements, license metadata, output format, and documentation structure, and add explicit Instructions, Examples, changelog, and maintenance path.
What does this skill do, and when should you use it?
This skill edits an existing Isaac for Healthcare environment through a --bridge scene-edit session. It covers objects, cameras, task wording, success bounds, and reset randomization. Editing is live-only by default, so source files remain untouched unless the user explicitly requests baking or persistence. It requires an existing environment, the i4h-workflows base code with a .venv, and a GPU host capable of launching Isaac Sim.
Resolves or reuses the i4h-workflows checkout; launches and polls a detached environment-specific bridge; calls HTTP endpoints to list objects, inspect object and camera state, teleport entities, run trusted scripts, capture JPEG frames, and collect bake snippets; verifies live poses; stops the arena through the prescribed command; and, only when requested, writes collected state to environment, asset, task, runtime, or YAML source files.
- An Isaac for Healthcare developer needs to move, rotate, or replace an object in an existing environment and wants live bridge-based verification.
- A user needs to reposition a robot stand and monitor the robot over time for falling, drift, or instability.
- A developer needs to choose or adjust a task camera by inspecting the live scene and validating captures before baking an environment-local camera.
- A developer needs to preview or change task wording, success conditions, or reset-randomization ranges and persist them only after explicit approval.
- A user wants to open an environment in edit mode without making edits; the bridge is launched, GET /objects is confirmed, and the session awaits instructions.
What are this skill's strengths and limitations?
- Covers object, camera, task, success-rule, and randomization edits.
- Clearly separates live editing from source baking, reducing unintended source changes.
- Provides environment-specific HTTP endpoints for inspection, editing, capture, verification, and bake-state collection.
- Includes distinct handling rules for rigid bodies, embedded kinematic assets, robots, and live-added objects.
- Requires a GPU host capable of launching Isaac Sim and a configured workflow environment.
- Live-added bodies are not immediately GPU-simulated and must not be tensor-queried.
- Support-surface scaling is source-only; live visual scaling does not update the collision mesh.
- Complete camera policy, dataset, and training wiring requires additional reference files; the skill does not provide a standalone installation tutorial.
How do you install this skill?
Install the skill with the repository's documented Skills CLI flow: npx skills add nvidia/skills --skill i4h-workflow-scene-edit --yes. The skill becomes available the next time the agent loads skills and encounters a relevant task. SKILL.md also requires a configured i4h-workflows setup with a .venv; the complete setup procedure is delegated to i4h-workflow-setup and is not included here.
How do you use this skill?
In a configured i4h-workflows environment, issue a concrete request such as: “Start scene-edit mode for <env> and move <object> to the specified position.” If the request only asks to open edit mode, launch the bridge, confirm readiness with GET /objects, and wait. Live edits are not persisted by default; use “bake,” “save,” “persist,” or “commit to source” to request source changes explicitly.