Official agent skill

I4h Workflow Scene Edit

by NVIDIA in NVIDIA/skills

Edit an existing workflow Scene or task contract. An agent skill from NVIDIA/skills.

OfficialApache-2.0Auto-check passed

Install I4h Workflow Scene Edit

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

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

GitHub CLI
$ gh skill install NVIDIA/skills i4h-workflow-scene-edit --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-scene-edit .claude/skills/i4h-workflow-scene-edit && 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-scene-edit
GitHub stars
3.5k
Used in
1 other repo
Token cost
~4.8k tokens
SKILL.md length
2,255 words
Files
8 (incl. references)
Skills in repo
380
Repo updated
First seen
Licence
Apache-2.0

At a glance

Edit an existing workflow Scene or task contract. An agent skill from NVIDIA/skills.

  • Works in 6 steps: Run the checkout resolver and inspect… → Start or reuse one bridge-backed… → Read the minimal upstream guidance and… → …
  • Do not use to create a new workflow
  • SKILL.md covers Purpose, Instructions, Resolve and inspect and Establish a visible baseline, plus 10 more sections
  • Calls python, git and uvx; reaches github.com

What it does

I4h Workflow Scene Edit is an agent skill from NVIDIA/skills, published by the product's own GitHub organization. Edit an existing workflow Scene or task contract. Use for assets, layout, cameras, randomization, task text, or success rules; do not use to create a new workflow.

Its SKILL.md is about 4.8k tokens, which your agent loads only when the skill is triggered. The skill folder holds 9 other files, including reference files (for example `BENCHMARK.md`, `evals/evals.json` and `references/existing-scene-assets.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

  • Do not use to create a new workflow

Example prompts

  • “/i4h-workflow-scene-edit”

Requirements

  • Python 3

Workflow steps

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

  1. Run the checkout resolver and inspect target ownership.
  2. Start or reuse one bridge-backed live-authoring session by default and capture a visible baseline.
  3. Read the minimal upstream guidance and apply each requested edit as its own observable live-stage transaction without changing source.
  4. On an explicit bake/save/persist instruction, export the accumulated live state, inspect its resolved authoring facts, and have the coding…
  5. Keep the session running for further prompts until the user explicitly says stop or exit.
  6. Run static, persisted-visible, and affected dynamic validation when baking.

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:

    • python
    • git
    • uvx

    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 Scene Edit loads about 4.8k tokens when it runs, and up to ~8.7k if it reads all its reference files. Until then it costs about 47 tokens; SKILL.md has 2,255 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~47
When it runs · the whole SKILL.md, loaded when a task matches
~4.8k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~8.7k

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). 2,255 words, ~4,814 tokens.

Download SKILL.mdSave it as .claude/skills/i4h-workflow-scene-edit/SKILL.md (or your agent's skills folder). This skill also uses 7 other files; get the full folder from GitHub.
name
i4h-workflow-scene-edit
description
Edit an existing workflow Scene or task contract. Use for assets, layout, cameras, randomization, task text, or success rules; do not use to create a new workflow.
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, isaac-sim, scene-authoring

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

  1. Run the checkout resolver and inspect target ownership.
  2. Start or reuse one bridge-backed live-authoring session by default and capture a visible baseline.
  3. Read the minimal upstream guidance and apply each requested edit as its own observable live-stage transaction without changing source.
  4. 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.
  5. Keep the session running for further prompts until the user explicitly says stop or exit.
  6. 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.

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
./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.

bash
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"
fi

The 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:

bash
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.sh only when I4H_LOCAL_AGENT=1; otherwise launch ./run.sh <workflow> --live through a persistent/yieldable host session. Use the bounded readiness wait above.
  • On every later scene prompt, use ./local-agent/bridge.sh status <workflow> and rundir <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/RobotHeadCam preview and bake with a registered G1 embodiment whose robot_head_cam sensor is exposed through the head alias.
  • 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.
Show full SKILL.md (893 more words)Show less

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:

bash
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

bash
./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.

© 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 7 other files (references) in skills/i4h-workflow-scene-edit of NVIDIA/skills.

  • SKILL.md
  • BENCHMARK.md
  • evals/evals.json
  • references/existing-scene-assets.md
  • references/g1-reach-and-contact.md
  • references/isaacsim-skill-routing.md
  • 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 Scene Edit 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 Scene Edit compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
I4h Workflow Scene Edit this skillNVIDIA/skills3.5k1 repos~4.8kAutomated safety check: PassApache-2.0
Scenesautonomous-ai/openharness1.1k—~4.7kAutomated safety check: PassMIT
Scene Establishing-Shot Promptchatfire-AI/huobao-drama16k—~378Automated safety check: PassCustom licence
Horizontal Scroll ScenesMengTo/Skills6.6k—~2.5kAutomated safety check: PassMIT
Scene CreateIvanMurzak/Unity-MCP4.4k—~1kAutomated safety check: PassApache-2.0
Scene UnloadIvanMurzak/Unity-MCP4.4k—~802Automated safety check: PassApache-2.0

Similar skills

  • Scenes

    autonomous-ai/openharness

    A skill your agent uses when working with Phaser 4 scenes. An agent skill from autonomous-ai/openharness.

    1.1k GitHub stars~4.7k tokensUpdated today
    Auto-check passed
  • Scene Establishing-Shot Prompt

    chatfire-AI/huobao-drama

    Writes the final image prompt for a clear wide establishing shot of an empty scene, fixing foreground, midground, background, exits, floor, walls and key furnishings.

    16k GitHub stars~378 tokensUpdated 2 days ago
    Media & CreativeAuto-check passed
  • Build scene-by-scene chapters that advance left to right on one fixed stage while the user scrolls vertically, with native scroll as the only input.

    6.6k GitHub stars~2.5k tokensUpdated yesterday
    Frontend & DesignAuto-check passed
  • Scene Create

    IvanMurzak/Unity-MCP

    Create a new Unity scene asset and save it at the given .unity path.

    4.4k GitHub stars~1k tokensUpdated 3 days ago
    Game DevelopmentAuto-check passed
  • Scene Unload

    IvanMurzak/Unity-MCP

    Unload an opened scene from the Unity Editor (asynchronously via SceneManager.UnloadSceneAsync).

    4.4k GitHub stars~802 tokensUpdated 3 days ago
    Game DevelopmentAuto-check passed
  • Scene Save

    IvanMurzak/Unity-MCP

    Save an opened scene back to its asset file (or to a new path when path is provided).

    4.4k GitHub stars~530 tokensUpdated 3 days ago
    Game DevelopmentAuto-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 Scene Edit

What does I4h Workflow Scene Edit do?

Edit an existing workflow Scene or task contract. An agent skill from NVIDIA/skills. I4h Workflow Scene Edit is an agent skill from NVIDIA/skills, published by the product's own GitHub organization. Edit an existing workflow Scene or task contract.

When should I use I4h Workflow Scene Edit?

I4h Workflow Scene Edit fits situations like: do not use to create a new workflow.

How do I install I4h Workflow Scene Edit in Claude Code?

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

How do I install I4h Workflow Scene Edit in Codex?

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

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

What does I4h Workflow Scene Edit need to run?

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

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

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

About 4.8k tokens (SKILL.md is roughly 19k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 3.9k tokens, read only when the agent opens those files.

What are the alternatives to I4h Workflow Scene Edit?

Skills that share tags, products or a category with I4h Workflow Scene Edit: Scenes (autonomous-ai/openharness, 1.1k stars), Scene Establishing-Shot Prompt (chatfire-AI/huobao-drama, 16k stars), Horizontal Scroll Scenes (MengTo/Skills, 6.6k stars) and Scene Create (IvanMurzak/Unity-MCP, 4.4k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains I4h Workflow Scene Edit?

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.