SkillAtlasSkill 详情

i4h-workflow-scene-edit

Official, NVIDIA-verified Agent Skills for Claude Code, Codex, and other coding agents.

审核状态:已审核Quality 80Security 62

复制安装命令

用 Codex 或 Claude 安装复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它先审查 Skill 页面再帮你安装。

复制前请先查看来源、License 和安全提示。

项目 README

来源文件:README.md

抓取于 2026年8月9日

NVIDIA Agent Skills

Official, NVIDIA-verified Agent Skills for Claude Code, Codex, and other coding agents.

NVIDIA Agent Skills Spec License

📖 Docs: docs.nvidia.com/skills  ·  📺 Livestream: From Vulnerable to Verified  ·  📝 Blog: NVIDIA Verified Agent Skills: Capability Governance for AI Agents


Skills are portable instruction sets that teach AI agents how to use NVIDIA software optimally: Physical AI and robotics workflows, simulation, CUDA-X libraries, RAG and AI Blueprints, and platform tools. This repository is a catalog: skills are maintained in their respective product repos, and mirrored here daily via an automated sync pipeline. Skills are being added continuously, so check back for updates. We are building this infrastructure in the open, and contributions are welcome. See the Roadmap for what is planned next.


Quickstart

Install NVIDIA skills with the default skills CLI flow:

npx skills add nvidia/skills

The CLI runs through npx and prompts you to choose a skill and install destination. You do not need to clone this repo or copy skill folders by hand.

Requires a current skills CLI (v1.5.16 or newer). Installing via npx skills@latest add nvidia/skills always uses the latest. On older CLIs (v1.5.15 and earlier), skills may install but not appear in Claude Code — see Troubleshooting.

The skill is available the next time your agent loads skills and encounters a relevant task. For example, ask your agent to "solve a linear programming problem with cuOpt" and the skill guides it through the cuOpt Python API. In Claude Code, run /reload-skills to load newly installed skills in your current session.

Install One Skill Without Prompts

Use this when you already know the skill name and want to skip prompts.

npx skills add nvidia/skills --skill cuopt-numerical-optimization-api --yes

Replace cuopt-numerical-optimization-api with any skill name from the Skill Catalog.

Install for a Specific Agent

Use --agent to target a specific AI coding agent. Initially, we'll support common client targets, expanding the list over time. For the full list of clients supported by the spec, see the skills CLI Supported Agents table.

Claude Code

npx skills add nvidia/skills --skill cuopt-numerical-optimization-api --agent claude-code

Codex

npx skills add nvidia/skills --skill cuopt-numerical-optimization-api --agent codex

Snowflake CoCo

npx skills add nvidia/skills --skill cuopt-numerical-optimization-api --agent cortex

Cursor

npx skills add nvidia/skills --skill cuopt-numerical-optimization-api --agent cursor

Kiro

npx skills add nvidia/skills --skill cuopt-numerical-optimization-api --agent kiro-cli

Use --agent more than once to install the same skill into multiple agents.

npx skills add nvidia/skills \
  --skill cuopt-numerical-optimization-api \
  --agent claude-code \
  --agent codex \
  --agent cursor \
  --agent kiro-cli

Keep Skills Up to Date

New skills land continuously, and existing ones are revised, renamed, or consolidated as the catalog evolves. Refresh what you have installed with:

npx skills update

Run it interactively and the CLI also flags skills that were removed or merged upstream (for example, when several skills are consolidated into one) and offers to remove the stale local copies. Use npx skills list to see what is installed and npx skills check to preview what is out of date first.

Browse the Catalog

Use this when you want to see available NVIDIA skills before installing anything.

npx skills add nvidia/skills --list

For non-interactive installs, global installs, agent-specific installs, updates, removals, and fallback manual copying, see Advanced installation.


Skill Catalog

ProductDescriptionSkills
AIQNVIDIA AI-Q Blueprint - deploy local AI-Q services and run shallow or deep research workflows as agent skills.aiq-research, aiq-deploy
CUDA-QCUDA Quantum — onboarding guide for installation, test programs, GPU simulation, QPU hardware, and quantum applications.cudaq-guide
cuDFOfficial NVIDIA-authored guidance for NVIDIA cuDF GPU DataFrames, pandas acceleration, dask-cuDF, ETL, joins, groupby, CSV/Parquet I/O, nullable semantics, and multi-GPU DataFrame workloads.accelerated-computing-cudf
cuOptGPU-accelerated optimization — vehicle routing, linear programming, quadratic programming, installation, server deployment, and developer tools.cuopt-install, cuopt-multi-objective-exploration, cuopt-numerical-optimization-api, cuopt-numerical-optimization-formulation, cuopt-routing-api-python, cuopt-server-api-python
cuPyNumericNumPy and SciPy on multi-node multi-GPU systems — skills to help with installing cuPyNumeric, migrating existing NumPy code, and doing parallel I/Ocupynumeric-hdf5, cupynumeric-install, cupynumeric-migration-readiness, cupynumeric-parallel-data-load
DALIGPU-accelerated data loading and processing with NVIDIA DALI.dali-dynamic-mode
Data DesignerBuild declarative synthetic dataset generation pipelines with NeMo Data Designer.data-designer
DeepStreamAgentic skills for guided DeepStream development.amc-run-sample-calibration, amc-run-video-calibration, amc-setup-calibration-stack, deepstream-dev, deepstream-generate-pipeline, deepstream-import-vision-model, deepstream-profile-pipeline, deepstream-sop
Digital HealthAgent skills for the clinical ASR evaluation flywheel — term curation, synthetic clinical-speech benchmark generation, KER (Keyword Error Rate) scoring, and fine-tune guidance.digital-health-clinical-asr-setup, digital-health-clinical-asr-build, digital-health-clinical-asr-eval, digital-health-clinical-asr-finetune
DOCATeach AI agents to use the NVIDIA DOCA SDK on BlueField DPUs and ConnectX NICs — setup, libraries, services, tools, deployment, and debugging.doca-bare-metal-deployment, doca-bf3-deployment, doca-bf4-deployment, doca-collectx-deployment, doca-container-deployment, doca-debug, doca-hardware-safety, doca-programming-guide, doca-public-knowledge-map, doca-setup, doca-structured-tools-contract, doca-upgrade, doca-version, doca-aes-gcm, doca-argp, doca-comch, doca-common, doca-compress, doca-devemu, doca-dma, doca-dpa, doca-dpdk-bridge, doca-erasure-coding, doca-eth, doca-flow, doca-flow-dpa-provider, doca-gpi, doca-gpunetio, doca-mgmt, doca-pcc, doca-pcc-ztr-rttcc-algo, doca-rdma, doca-rdmi, doca-rmax, doca-sha, doca-sta, doca-telemetry, doca-telemetry-exporter, doca-urom, doca-verbs, doca-argus, doca-dms, doca-firefly, doca-urom-svc, doca-bench, doca-bench-extension, doca-caps, doca-comm-channel-admin, doca-dpa-hl-tracer, doca-flow-dpa-perf, doca-flow-grpc-server, doca-flow-perf, doca-flow-tune, doca-gpunetio-ib-write-bw, doca-gpunetio-ib-write-lat, doca-pcc-counters, doca-sha-offload-engine, doca-socket-relay, doca-spcx-cc, doca-telemetry-utils
DynamoNVIDIA Dynamo deployment bring-up on Kubernetes — pick and deploy recipes, start router modes, validate disagg NIXL/UCX/NCCL interconnect, and triage day-2 failures.dynamo-interconnect-check, dynamo-recipe-runner, dynamo-router-starter, dynamo-troubleshoot
Earth2StudioOpen-source deep-learning framework for exploring, building and deploying AI weather/climate workflows.earth2studio-create-datasource, earth2studio-create-diagnostic, earth2studio-create-prognostic, earth2studio-data-fetch, earth2studio-deterministic-forecast, earth2studio-discover, earth2studio-install
HoloHubBuild, run, debug, benchmark, and develop HoloHub applications and Holoscan Modules with validated lifecycle workflows.holohub-app-lifecycle, holohub-debug-build-run, holohub-module-lifecycle
Holoscan SDKInstall and set up the Holoscan SDK on any platform (container, Debian, Python, Conda, or source).holoscan-install-debian, holoscan-install-source, holoscan-install-wheel, holoscan-install-conda, holoscan-install-container, holoscan-setup
Holoscan Sensor BridgeAgent-ready skills for Holoscan Sensor Bridge devkit workflows, including demo environment bring-up, FPGA flashing for Lattice and VB1940 hardware, example application execution, QA test-plan automation, and support for configuring and using the Holoscan Sensor Bridge FPGA intellectual property (IP) core.hsb-setup, hsb-flash, hsb-app, hsb-test, hsb-ip-def, hsb-ip-packetizer, hsb-ip-create-top
Isaac for Healthcare WorkflowsAgent-ready skills for Isaac for Healthcare agentic and catheter-navigation workflows, covering task authoring, data pipelines, policy training and validation, CT-derived digital twins, DRR rendering, and interactive catheter simulation.i4h-workflow, i4h-workflow-setup, i4h-workflow-create, i4h-workflow-scene-edit, i4h-workflow-dataset-teleop, i4h-workflow-dataset-replay, i4h-workflow-dataset-mimic, i4h-workflow-dataset-annotate, i4h-workflow-dataset-convert, i4h-workflow-finetune, i4h-workflow-validate, i4h-workflow-e2e, i4h-lerobot-viz, i4h-catheter-navigation, i4h-catheter-navigation-setup, i4h-catheter-navigation-digital-twin, i4h-catheter-navigation-render-drr, i4h-catheter-navigation-viewport, i4h-catheter-navigation-smoke, i4h-catheter-navigation-e2e
Jetson BSPAgentic skills for setting up and customizing an NVIDIA Jetson Linux Board Support Package (BSP) — pick a target, prepare image and sources, customize IO (camera, PCIe, USB, pinmux, clocks, and more), then promote, flash, and validate.jetson-build-source, jetson-customize-camera, jetson-customize-clocks, jetson-customize-fan, jetson-customize-mgbe, jetson-customize-nvpmodel, jetson-customize-pcie, jetson-customize-pinmux, jetson-customize-uphy, jetson-customize-usb, jetson-derive-carrier, jetson-download-bsp, jetson-flash-image, jetson-generate-kb, jetson-init-image, jetson-init-source, jetson-init-target, jetson-link-docs, jetson-optimize-memory, jetson-print-bsp-info, jetson-promote-image, jetson-quick-start, jetson-set-target, jetson-validate-image
Jetson DeviceDevice-side agent skills for working with a live NVIDIA Jetson after boot — diagnostics, memory auditing, headless setup, inference memory tuning, LLM serving and benchmarking, packaging guidance, and speculative decoding.jetson-diagnostic, jetson-headless-mode, jetson-inference-mem-tune, jetson-llm-benchmark, jetson-llm-serve, jetson-memory-audit, jetson-package, jetson-print-device-info, jetson-speculative-decoding
Medical AI SkillsAgent-ready medical AI skills built on MONAI for DICOM handling, NVIDIA-hosted medical imaging model workflows, segmentation, synthesis, and evidence-oriented evaluation.dicom-metadata-extract, dicom-series-preflight, dicom-series-to-volume, nv-generate-ct-rflow, nv-generate-mr, nv-generate-mr-brain, nv-generate-mr-brain-finetune, nv-generate-vae-finetune, nv-reason-cxr, nv-segment-ct, nv-segment-ct-finetune, nv-segment-ctmr
Megatron-CoreLarge-scale distributed training — model parallelism, pipeline parallelism, and mixed precision.mcore-create-issue, mcore-linting-and-formatting, mcore-run-on-slurm, mcore-split-pr, mcore-testing
NeMo AutoModelNeMo AutoModel - PyTorch-native distributed training for LLMs/VLMs with Hugging Face support, recipes, launchers, and validation workflows.nemo-automodel-distributed-training, nemo-automodel-launcher-config, nemo-automodel-model-onboarding, nemo-automodel-recipe-development
NeMo MBridgeNeMo MBridge - PyTorch-native bridge between Hugging Face and Megatron-Core for checkpoint conversion, training recipes, and NVIDIA GPU performance workflows.nemo-mbridge-mlm-bridge-training, nemo-mbridge-multi-node-slurm, nemo-mbridge-perf-activation-recompute, nemo-mbridge-perf-cpu-offloading, nemo-mbridge-perf-cuda-graphs, nemo-mbridge-perf-expert-parallel-overlap, nemo-mbridge-perf-hierarchical-context-parallel, nemo-mbridge-perf-megatron-fsdp, nemo-mbridge-perf-memory-tuning, nemo-mbridge-perf-moe-comm-overlap, nemo-mbridge-perf-moe-dispatcher-selection, nemo-mbridge-perf-moe-hardware-configs, nemo-mbridge-perf-moe-long-context, nemo-mbridge-perf-moe-optimization-workflow, nemo-mbridge-perf-moe-vlm-training, nemo-mbridge-perf-parallelism-strategies, nemo-mbridge-perf-sequence-packing, nemo-mbridge-perf-tp-dp-comm-overlap, nemo-mbridge-recipe-recommender, nemo-mbridge-resiliency
NeMo PlatformNeMo Platform brings NVIDIA NeMo libraries together under one CLI, Python SDK, and web UInemo-evaluator-plugin, nemo-data-designer-plugin
NeMo RelaySkills to help get started and use NeMo Relay - a runtime for instrumenting and controlling AI agents across harnesses, applications, and frameworks.nemo-relay-install, nemo-relay-get-started, nemo-relay-instrument-calls, nemo-relay-instrument-context-isolation, nemo-relay-instrument-typed-wrappers, nemo-relay-plugin-adaptive-tuning, nemo-relay-plugin-build, nemo-relay-plugin-observability, nemo-relay-migrate-from-flow, nemo-relay-debug-runtime-integration
NeMo RetrieverNeMo Retriever - deploy NeMo Retriever Library locally, extract information from corpus of data, and answer questions against the corpus.nemo-retriever
NeMo-RLRLHF training on Ray — GRPO, DPO, and SFT for LLMs and VLMs with FSDP2 and Megatron-Core.launch-nemo-rl, nemo-rl-auto-research, nemo-rl-brev-etiquette, nemo-rl-docs, nemo-rl-session-memory
NemoClawSecure agent sandboxing — run OpenClaw inside NVIDIA OpenShell with managed inference, policy management, remote deployment, sandbox monitoring.nemoclaw-user-guide
NemotronAuthor end-to-end model development, customization, evaluation, and deployment pipelines using the NVIDIA AI stack.nemotron-customize, nemotron-retrieval-recipes, nemotron-policy-generator
Nemotron SpeechDeploy and operate NVIDIA Nemotron Speech (Riva) NIMs — ASR, TTS, and NMT, cloud-hosted via build.nvidia.com or self-hosted on your own GPU.nemotron-speech, nemotron-asr-finetune
Physical AIPhysical AI skills for simulation, synthetic data generation, training, validation and deployment and more.omniverse-cad-to-simready, omniverse-realtime-viewer, omniverse-usd-performance-tuning, physical-ai-infrastructure-setup-and-resilient-scaling, physical-ai-neural-reconstruction, physical-ai-defect-image-generation, physical-ai-video-data-augmentation, physical-ai-people-attribute-search
PhysicsNeMoNVIDIA PhysicsNeMo - Open-source deep-learning framework for building, training, and fine-tuning deep learning models using state-of-the-art Physics-ML methods.physicsnemo-discover, physicsnemo-shard-tensor
Portfolio OptimizationGPU-accelerated Mean-CVaR portfolio optimization with NVIDIA cuOpt — CVaR optimization, efficient frontier, scenario generation, backtesting, and rebalancing.portfolio-optimization
RAG BlueprintRAG pipeline — deploy, configure, troubleshoot, and manage retrieval augmented generation with Docker Compose or Helm.rag-blueprint, rag-eval, rag-perf
Skill Card GeneratorReads an agent skill's source files and produces a skill card plus a review table. Use when a skill directory exists and a governance card needs to be generated or updated.skill-card-generator
TAO ToolkitNVIDIA TAO Toolkit - fine-tune and optimize 100+ pretrained vision AI models with your own data using low-code microservices, then export production-ready models for edge or cloud deployment.tao-analyze-changenet-rca, tao-finetune-huggingface-model, tao-port-huggingface-model, tao-run-automl, tao-run-automl-deft-pipeline, tao-run-deft-aoi, tao-run-inference-service, tao-train-single-step, paidf-anomalygen, tao-analyze-gaps-visual-changenet, tao-analyze-gaps-vlm-bcq, tao-convert-dataset-format, tao-generate-image-grounding, tao-generate-referring-expressions, tao-generate-video-reasoning-annotations, tao-mine-aoi-images, tao-route-visual-changenet-samples, tao-validate-dataset-format, tao-finetune-clip, tao-finetune-cosmos-embed, tao-finetune-cosmos-reason, tao-train-action-recognition, tao-train-bevfusion, tao-train-centerpose, tao-train-deformable-detr, tao-train-depth-anything-v2, tao-train-dino, tao-train-fast-foundation-stereo, tao-train-foundation-stereo, tao-train-grounding-dino, tao-train-image-classification, tao-train-mask-auto-encoder, tao-train-mask-auto-label, tao-train-mask-grounding-dino, tao-train-mask2former, tao-train-metric-learning-recognition, tao-train-nvdinov2, tao-train-nvpanoptix3d, tao-train-ocdnet, tao-train-ocrnet, tao-train-oneformer, tao-train-optical-inspection, tao-train-pointpillars, tao-train-pose-classification, tao-train-reid, tao-train-rtdetr, tao-train-segformer, tao-train-sparse4d, tao-train-visual-changenet, tao-run-on-brev, tao-run-on-docker, tao-run-on-kubernetes, tao-run-on-local-docker, tao-run-on-slurm, tao-run-platform, tao-setup-nvidia-gpu-host, tao-launch-workflow, tao-list-capabilities
TileGymTile-based GPU programming — adding new kernels, cross-framework conversion, and performance optimization.tilegym-adding-cutile-kernel, tilegym-converting-cutile-to-julia, tilegym-converting-cutile-to-triton, tilegym-cutile-autotuning, tilegym-cutile-python, tilegym-improve-cutile-kernel-perf, tilegym-monkey-patch-kernels-to-transformers
Video Search and SummarizationVSS Blueprint — deploy profiles, search and summarize video, generate analysis reports, manage alerts and incidents, query VIOS sensors, and use the RTVI VLM microservice.vss-ask-video, vss-deploy-dense-captioning, vss-deploy-detection-tracking-2d, vss-deploy-detection-tracking-3d, vss-deploy-profile, vss-deploy-video-embedding, vss-generate-video-calibration, vss-generate-video-report, vss-manage-alerts, vss-manage-video-io-storage, vss-query-analytics, vss-search-archive, vss-setup-behavior-analytics, vss-setup-video-analytics-api, vss-summarize-video

Getting Help & Contributing

Where to file an issue depends on what's broken:

  • Skill content issues (a specific skill has a bug, missing functionality, or incorrect content) — file in the source repo for that product, using the per-product table below.
  • Catalog issues (catalog README errors, sync workflow problems, distribution channels, signing/verification flow, docs in this repo) — file here using the catalog issue templates: Bug Report, Feature Request, or Documentation Request or Correction.
  • Questions or general discussion — use Discussions. The issue tracker is reserved for bug reports, feature proposals with a design, and documentation issues.
  • Security vulnerabilities — follow the disclosure process in SECURITY.md; do not open a public issue.

Per-product source repo links:

ProductIssuesDiscussionsContributingSecurity
AIQIssuesDiscussionsContributingSecurity
CUDA-QIssuesDiscussionsContributingSecurity
cuDFIssuesDiscussionsContributingSecurity
cuOptIssuesDiscussionsContributingSecurity
cuPyNumericIssues—Contributing—
DALIIssues—Contributing—
Data DesignerIssuesDiscussionsContributingSecurity
DeepStreamIssues—ContributingSecurity
Digital HealthIssues—ContributingSecurity
DOCAIssues—ContributingSecurity
DynamoIssuesDiscussionsContributingSecurity
Earth2StudioIssuesDiscussionsContributing—
HoloHubIssues—ContributingSecurity
Holoscan SDKIssues—ContributingSecurity
Holoscan Sensor BridgeIssues—Contributing—
Isaac for Healthcare WorkflowsIssues—ContributingSecurity
Jetson BSPIssues—ContributingSecurity
Jetson DeviceIssues—ContributingSecurity
Medical AI SkillsIssues—ContributingSecurity
Megatron-CoreIssuesDiscussionsContributing—
NeMo AutoModelIssuesDiscussionsContributingSecurity
NeMo MBridgeIssuesDiscussionsContributingSecurity
NeMo PlatformIssuesDiscussionsContributingSecurity
NeMo RelayIssuesDiscussionsContributingSecurity
NeMo RetrieverIssuesDiscussionsContributingSecurity
NeMo-RLIssuesDiscussionsContributingSecurity
NemoClawIssuesDiscussionsContributingSecurity
NemotronIssuesDiscussionsContributingSecurity
Nemotron SpeechIssues—ContributingSecurity
Physical AIIssues—ContributingSecurity
PhysicsNeMoIssuesDiscussionsContributingSecurity
Portfolio OptimizationIssuesDiscussionsContributingSecurity
RAG BlueprintIssuesDiscussionsContributingSecurity
Skill Card GeneratorIssues—ContributingSecurity
TAO ToolkitIssuesDiscussionsContributingSecurity
TileGymIssues—ContributingSecurity
Video Search and SummarizationIssuesDiscussionsContributingSecurity

For issues with this catalog repo itself (README, structure, listing a new product): open an issue here.


Verifying Skills

Every published skill ships with a detached OMS signature (skill.oms.sig). The sync pipeline drops any skill missing the required artifacts before publishing, so every skill in the catalog carries:

  • SKILL.md — the skill instructions consumed by the agent
  • skill-card.md — skill identity and governance card
  • skill.oms.sig — detached OMS signature (verifiable against nv-agent-root-cert.pem)
  • A Tier-3 evaluation dataset — accepted at evals/evals.json, evals/*.json, eval/*.json, or benchmark/evals.json
  • BENCHMARK.md — generated benchmark report capturing verifiable uplift data

Verify a skill against the NVIDIA trust anchor nv-agent-root-cert.pem:

pip install model-signing
model_signing verify certificate SKILL_DIR \
  --signature SKILL_DIR/skill.oms.sig \
  --certificate_chain nv-agent-root-cert.pem \
  --ignore_unsigned_files

A successful verification confirms that the skill contents have not been modified since signing by NVIDIA.

See Verify Signed Agent Skills for signature layout, the trust pipeline, and policy options.


Roadmap

  • ✅ Public skills catalog with NVIDIA-verified skills across multiple products
  • ✅ Automated sync pipeline with skills mirrored from product repos daily
  • ✅ Security scanning for all published skills covering instruction safety and supply-chain integrity
  • ✅ Skills signing so every published skill carries a verifiable NVIDIA signature
  • ✅ Skills universal evaluation criteria and task-specific criteria
  • ✅ Skill Card with machine-readable metadata for identity, provenance, quality, and behavioral boundaries
  • ✅ Sync-time compliance gates — signature drift detection and missing-artifact enforcement
  • ✅ Syndication to external marketplaces — Skills.sh, Codex plugin, Claude Code plugin, ClawHub, Hermes Hub
  • 🔲 Syndication to additional MCP hubs and partner channels

Repository Structure

NVIDIA/skills/
├── skills/                      # NVIDIA-verified skills (count grows continuously),
│   │                              synced from upstream product repos
│   ├── README.md                 # Browser-facing install guidance
│   ├── <product-prefix>-*/       # Flat layout — one dir per skill, product-prefixed
│   │                               # e.g. aiq-*, cuopt-*, cupynumeric-*,
│   │                               # dali-*, deepstream-*, dicom-*, digital-health-*,
│   │                               # dynamo-*, earth2studio-*, holoscan-*, hsb-*,
│   │                               # jetson-*, launch-nemo-rl, mcore-*,
│   │                               # nemo-automodel-*, nemo-data-designer-plugin,
│   │                               # nemo-evaluator-plugin, nemo-mbridge-* (20 skills),
│   │                               # nemo-retriever, nemo-rl-* (4 skills),
│   │                               # nemoclaw-user-guide, nemotron-*, nemotron-speech,
│   │                               # nv-* (medical AI), physicsnemo-*, rag-*,
│   │                               # skill-card-generator, tao-*, tilegym-*,
│   │                               # vss-* (15 skills), accelerated-computing-cudf,
│   │                               # cudaq-guide, portfolio-optimization
│   ├── omniverse-*/              # Physical AI — manually staged (see manual-components.yml)
│   └── physical-ai-*/            # Physical AI — manually staged
├── components.d/                # Product registry — one file per component, teams onboard here
│   ├── README.md                 # Schema and onboarding instructions
│   └── <product>.yml             # one file per registered product
├── plugins/                     # Packaged plugin distributions
│   └── nvidia-skills/            # Curated NVIDIA skills bundle (Claude Code, Codex)
├── plugins.d/                   # Plugin build registry — config for `build-plugins.py`
│   ├── README.md
│   ├── _defaults.yml
│   └── nvidia-skills.yml
├── .claude-plugin/              # Claude Code marketplace metadata
│   └── marketplace.json
├── .agents/plugins/             # Agent marketplace metadata (other clients)
│   └── marketplace.json
├── docs/                        # Long-form documentation (published via Fern)
│   ├── README.md                 # How to build the docs locally
│   ├── index.mdx
│   ├── advanced-install.mdx
│   ├── agent-skill-trust-pipeline.mdx
│   ├── release-checklist.mdx
│   ├── scanning-agent-skills.mdx
│   ├── signing-agent-skills.mdx
│   └── skill-cards.mdx
├── fern/                        # Fern docs site configuration
├── .github/
│   ├── workflows/                # Sync pipeline, plugin validation, DCO check, author verify
│   └── scripts/                  # regenerate-readme.sh, build-plugins.py,
│                                 # manual-components.yml (temp Physical AI catalog
│                                 # exception, removed after Computex 2026),
│                                 # marketplace/metadata.json (skill metadata sidecar)
├── nv-agent-root-cert.pem       # Trust anchor for OMS signature verification
├── skills.sh.json               # Skills.sh marketplace grouping config
├── CHANGELOG.md
├── CONTRIBUTING.md              # Contribution guidelines
├── SECURITY.md                  # Security reporting policy
├── CODE_OF_CONDUCT.md           # Community code of conduct
├── LICENSE-APACHE               # Apache 2.0 (source code)
└── LICENSE-CC-BY-4.0            # CC BY 4.0 (documentation/skills)

Skills are maintained in their respective product repos (see the Source column in the Skill Catalog) and synced to this repo daily. Products only appear under skills/ after the sync pipeline confirms each skill carries:

  • skill.oms.sig — detached OMS-format signature (verifiable against nv-agent-root-cert.pem)
  • skill-card.md — skill identity and governance card
  • A Tier-3 evaluation dataset — accepted at evals/evals.json, evals/*.json, eval/*.json, or benchmark/evals.json

When evaluation runs produce a BENCHMARK.md, it ships alongside the skill so consumers can see verifiable benchmark uplift data.


Standards & Compatibility

This repository adheres to the Agent Skills specification:

  • Skills are portable directories with a SKILL.md file at their root.
  • Metadata uses YAML frontmatter with required name and description fields.
  • Skills follow a progressive disclosure model — lightweight metadata loads at startup, full instructions load on activation.
  • Validate your skill using the skills-ref reference library.

License

Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved.

This code is dual-licensed with documentation/skills under the CC-BY-4.0 AND source code under Apache-2.0 license terms. The full license texts can be found in LICENSE-APACHE and LICENSE-CC-BY-4.0 respectively.

Agent / MCP / Skill 创作

高风险

  • 来源需自行核对维护者身份。
  • 包含脚本或命令调用,安装前请复核。
  • 未检测到明显外部权限要求。
  • 存在潜在风险命令,请谨慎安装。
  • 扫描发现:4 条。

Codex — Git Clone 安装

  1. 安装前请先查看来源仓库和风险报告。
  2. 克隆仓库:git clone https://github.com/NVIDIA/skills.git
  3. 将 "skills/i4h-workflow-scene-edit" 文件夹复制到 Codex 的 skills 目录中。
  4. 重启 Codex 让新的 skill 生效。

Codex — 手动复制安装

  1. 安装前请先查看来源仓库和风险报告。
  2. 从源仓库下载 SKILL.md 及相关文件。
  3. 在 Codex 的 skills 目录中创建新文件夹。
  4. 将所有 skill 文件复制到新文件夹中。
  5. 重启 Codex 让新的 skill 生效。

Claude Code — Git Clone 安装

  1. 安装前请先查看来源仓库和风险报告。
  2. 克隆仓库:git clone https://github.com/NVIDIA/skills.git
  3. 将 "skills/i4h-workflow-scene-edit" 文件夹复制到 Claude Code 的 skills 目录中。
  4. 重启 Claude Code 让新的 skill 生效。

Claude Code — 手动复制安装

  1. 安装前请先查看来源仓库和风险报告。
  2. 从源仓库下载 SKILL.md 及相关文件。
  3. 在 Claude Code 的 skills 目录中创建新文件夹。
  4. 将所有 skill 文件复制到新文件夹中。
  5. 重启 Claude Code 让新的 skill 生效。

Cursor — Git Clone 安装

  1. 安装前请先查看来源仓库和风险报告。
  2. 克隆仓库:git clone https://github.com/NVIDIA/skills.git
  3. 将 "skills/i4h-workflow-scene-edit" 文件夹复制到 Cursor 的 skills 目录中。
  4. 重启 Cursor 让新的 skill 生效。

Cursor — 手动复制安装

  1. 安装前请先查看来源仓库和风险报告。
  2. 从源仓库下载 SKILL.md 及相关文件。
  3. 在 Cursor 的 skills 目录中创建新文件夹。
  4. 将所有 skill 文件复制到新文件夹中。
  5. 重启 Cursor 让新的 skill 生效。

GitHub Copilot — Git Clone 安装

  1. 安装前请先查看来源仓库和风险报告。
  2. 克隆仓库:git clone https://github.com/NVIDIA/skills.git
  3. 将 "skills/i4h-workflow-scene-edit" 文件夹复制到 GitHub Copilot 的 skills 目录中。
  4. 重启 GitHub Copilot 让新的 skill 生效。

GitHub Copilot — 手动复制安装

  1. 安装前请先查看来源仓库和风险报告。
  2. 从源仓库下载 SKILL.md 及相关文件。
  3. 在 GitHub Copilot 的 skills 目录中创建新文件夹。
  4. 将所有 skill 文件复制到新文件夹中。
  5. 重启 GitHub Copilot 让新的 skill 生效。

Windsurf — Git Clone 安装

  1. 安装前请先查看来源仓库和风险报告。
  2. 克隆仓库:git clone https://github.com/NVIDIA/skills.git
  3. 将 "skills/i4h-workflow-scene-edit" 文件夹复制到 Windsurf 的 skills 目录中。
  4. 重启 Windsurf 让新的 skill 生效。

Windsurf — 手动复制安装

  1. 安装前请先查看来源仓库和风险报告。
  2. 从源仓库下载 SKILL.md 及相关文件。
  3. 在 Windsurf 的 skills 目录中创建新文件夹。
  4. 将所有 skill 文件复制到新文件夹中。
  5. 重启 Windsurf 让新的 skill 生效。
查看 SKILL.md 原文
name: i4h-workflow-scene-edit
version: "0.7.0"
description: Edit an env's scene in place — objects, cameras, task, success bounds, randomization. Use when asked to edit a scene or launch/run/open an env in edit mode (`--bridge`), incl. a just-created env.
license: Apache-2.0
metadata:
  author: "Isaac for Healthcare Team <isaac-for-healthcare-support@nvidia.com>"
  tags:
    - isaac-for-healthcare
    - i4h
    - agentic-workflow
    - scene-edit
    - environment

i4h Workflow — Scene Edit

Purpose

Edit an existing env's scene in place via the --bridge scene-edit session — move/scale/swap objects, adjust cameras, or tweak task description, success bounds, or randomization. Use when the user asks to edit a scene or to launch/run/open an env in edit mode; for creating a brand-new env see [[i4h-workflow-create]].

Base Code

These steps drive the i4h-workflows base code (the workflows/agentic/ tree). To reuse an existing checkout, set I4H_WORKFLOWS to its path (no clone happens). Otherwise this resolves the current repo, or clones to ~/i4h-workflows — pick that default without prompting. Run every command below from the resolved root:

# Resolve the i4h-workflows base code (provides workflows/agentic/).
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"

Basics

  • Editing a scene is LIVE-ONLY by default. "Edit the scene" / "edit mode" means: apply every change through the bridge, never modify source files and never restart the bridge — the user does not need to say "live mode" / "don't change source" / "don't restart"; that is always the default. Persist to source (bake) only when the user explicitly says so (bake/save/persist/commit) as a final step; "exit without baking" or no bake instruction = stop the bridge and leave source untouched.
  • Do only what's asked — launching edit mode is not a cue to edit. "Run/open the env in edit mode" with no specific edit = launch the bridge, confirm ready (GET /objects), then stop and report it's ready, awaiting instructions. Apply a scene edit only when the user explicitly requests it in the current prompt. Never invent or preempt edits (moving the robot, adding props, etc.), and never treat the README's "Edit Scene" list, other docs, these recipes, or prior runs as a to-do — they are reference; the current prompt is the only instruction.
  • Preserve env ids and scene keys.
  • Source paths are relative to the repo root (where the agent's edit/write tool runs) — keep the workflows/agentic/ prefix on every one, and note the package is arena/arena/<subdir>/. A bare arena/... resolves to the wrong place.
  • Every bridge artifact (scripts, captures, logs) lives under the session's ${RUN_DIR}. Never use /tmp.
  • Visual judgment — use your own eyes if you have them. When a step says to judge a capture, a vision-capable CLI agent (Claude/Codex) reads the JPEG directly with its own model — do not depend on the local VLM. Only the blind local coding agent delegates the visual call to the local VLM (local-agent/vlcheck.py). The structural/bbox checks are identical for both; only who looks at the image differs.

Repo Context

For live-only edits, use the bridge endpoints first. For any bake/source change, load:

  • skills/i4h-workflow/references/repo-map.md for env file ownership and pattern families.
  • skills/i4h-workflow-scene-edit/references/scene-edit-patterns.md for bake targets, readiness rules, and camera touchpoints.
  • skills/i4h-workflow-scene-edit/references/asset-snippets.md when adding, moving, resizing, or replacing assets.
  • skills/i4h-workflow-scene-edit/references/camera-snippets.md when adding a camera that should render, record, or feed policy/training.
  • skills/i4h-workflow-scene-edit/references/bake-checklist.md when the user says bake/save/persist/commit.

Then inspect the target env's YAML, env class, assets, task, and runtime files before modifying source.

Edit Lifecycle

For a normal interactive edit prompt, use exactly one sim/bridge window: launch or reuse one bridge, perform all requested live edits in that session, collect bake state/snippets if needed, stop that bridge once, and then write source from the collected state. Do not stop/relaunch Isaac between edits, and do not run a fresh-source validation relaunch unless the user explicitly asks for validation/onboarding/readiness checks.

  1. Live. Apply each edit through the bridge HTTP API in the same bridge session. Capture the viewport after task-relevant changes.
  2. Bake. Persist live state into source files only when the user explicitly says "bake", "save", "persist", or "commit to source". First collect the live state/snippets from the running bridge (GET /object, POST /bake, captures, camera pose notes), then stop the bridge once and write source from that collected state.
  3. Exit. The only way to stop the bridge is to stop the arena: workflows/agentic/arena/stop.sh --env <env>. Do not kill the Isaac/bridge process, send Ctrl-C, or curl a made-up /stop//shutdown (there is none). "Exit without baking" = run that one command (no source writes, no /bake).
  4. Validate only when asked. Fresh-source validation (local-agent/validate-bake.sh <env>) intentionally stops any bridge and launches a new sim window. Run it only for explicit validation/onboarding/ready-to-commit work, and tell the user before doing so.

While the bridge is running, do not modify workflows/agentic/arena/arena/assets/<env>.py, workflows/agentic/arena/arena/tasks/<env>.py, the env class, runtime, or env YAML. Source writes happen after the needed bridge state is collected and the bridge has been stopped.

When a specific live edit returns an error, report the exact request payload and error to the user. Do not restart the bridge as a fallback.

Launch

The bridge is a long-running foreground process: running it inline blocks a one-shot shell forever (and the bridge dies with the call), so it must be launched detached and then polled for ready. Each step below is a separate bash call; variables persist in the local agent's tmux session.

Local agent — one command

./local-agent/bridge.sh start <env> does setup + detached launch + wait-for-ready and prints RUN_DIR=... (and the helper paths). Run it plainly (it takes minutes — no short timeout). Stop later with ./local-agent/bridge.sh stop <env>.

Manual (portable) form

# Step 1 — setup
REPO_ROOT="${I4H_WORKFLOWS:-$(git rev-parse --show-toplevel 2>/dev/null)}"; [ -d "$REPO_ROOT/workflows/agentic" ] || REPO_ROOT="$HOME/i4h-workflows"
ENV_ID=<env>
RUNS_ROOT="${REPO_ROOT}/workflows/agentic/runs"
RUN_DIR="${RUNS_ROOT}/scene_edit_${ENV_ID}_$(date +%Y%m%d_%H%M%S)"
mkdir -p "${RUN_DIR}/logs" "${RUN_DIR}/scripts" "${RUN_DIR}/captures"
ln -sfn "${RUN_DIR}" "${RUNS_ROOT}/.latest"

# Step 2 — launch DETACHED (never foreground / never `| tee` inline — that blocks), then wait
"${REPO_ROOT}/workflows/agentic/arena/run.sh" ensure-bridge \
  --env "${ENV_ID}" \
  --log "${RUN_DIR}/logs/bridge.log"
BRIDGE_URL="$("${REPO_ROOT}/workflows/agentic/arena/run.sh" bridge-url --env "${ENV_ID}")"
curl -fsS "${BRIDGE_URL}/health" >/dev/null

Once ready, GET "${BRIDGE_URL}/objects" to enumerate scene entities. Stop only via workflows/agentic/arena/stop.sh --env "${ENV_ID}" — never by killing the process.

Bridge Endpoints (env-specific port)

Base URL: BRIDGE_URL="$(workflows/agentic/arena/run.sh bridge-url --env <env>)". The port comes from arena.bridge_port in workflows/agentic/config/environments/<env>.yaml and falls back to 8765; --bridge-port overrides it. JSON responses are either {"ok": true, "result": ...} or {"ok": false, "error": ...}.

Method + PathPurposeBody / Query
GET /healthServer readiness + endpoint discovery.—
GET /contextExec globals, helper names, endpoint inventory.—
GET /objectsList scene entities with kind (articulation / rigid / camera / xform) and prim path.—
GET /object?name=<key>Full state for one entity: xform_ops, bbox, live (authoritative PhysX pose), children.name=<key> or path=<prim_path>
GET /camerasList live RGB camera outputs.—
POST /captureSave camera frames and viewport as JPEG.{"output_dir": "<abs>", "viewport": true, "cameras": ["<name>", ...]}
POST /object/teleportLive-set pose for rigid bodies and articulations.{"name": "<key>", "translation": [x,y,z], "rotation_wxyz": [w,x,y,z], "zero_velocity": true, "env_index": 0}
POST /scriptRun a trusted absolute Python file on Isaac's main loop. Globals: ctx, env, app, args, helpers, stage, get_stage.{"path": "/abs/path/to/script.py"}
POST /bakeReturn Python snippets reflecting the current live xform of named entities.{"names": ["<key>", ...]}

After a teleport, read the live field from GET /object?name=<key> to verify. The bbox field is USD-derived and may lag a physics step.

Edit Matrix

EditLive (bridge)Bake target
Move/rotate rigid objectPOST /object/teleportworkflows/agentic/arena/arena/assets/<env>.py init_state.pos/rot
Move/rotate truly-static XformPrim (no physics body anywhere in the USD — lights, decals)POST /script → xformOp:translate / xformOp:orientworkflows/agentic/arena/arena/assets/<env>.py init_state.pos
Move/rotate AssetBaseCfg whose USD embeds a rigid body (e.g. SCISSOR_TRAY_USD trays/fixtures — kinematic child mesh)POST /script → helpers.move("<key>", pos=/dpos=) — drives the child PhysX body (raw USD writes snap back; see recipe)workflows/agentic/arena/arena/assets/<env>.py init_state.pos
Rescale a primLive-added / bridge-spawned prim → re-spawn at the new size (delete + CuboidCfg(new).func + re-rest; see "Resize a live-added prim"). Do NOT use xformOp:scale on it — that scales its position (flings it off-screen), NOT its size. xformOp:scale is only for an existing scene-asset prim.workflows/agentic/arena/arena/assets/<env>.py spawn=...scale
Move robot standPOST /object/teleport name=robotworkflows/agentic/arena/arena/environments/<env>_environment.py embodiment.set_initial_pose(...)
Add a new primPOST /script → sim_utils.CuboidCfg(...).func(path, cfg) + helpers.move(...) (see "Add a prim live" recipe) — NOT raw pxr USD authoring; a live-added body isn't GPU-simulated, so place it at rest height, don't tensor-query itworkflows/agentic/arena/arena/assets/<env>.py + make_*_scene_assets()
Toggle gravityPOST /script → set physxRigidBody:disableGravity; zero root_lin_vel_w / root_ang_vel_wworkflows/agentic/arena/arena/assets/<env>.py rigid_props.disable_gravity
Toggle kinematicPOST /script → flip physics:kinematicEnabledworkflows/agentic/arena/arena/assets/<env>.py rigid_props.kinematic_enabled
Change mass / collider propsPOST /script → write physxRigidBody:* / physxCollision:*workflows/agentic/arena/arena/assets/<env>.py mass_props / collision_props
Swap a USD referencePOST /script → prim.GetReferences().SetReferences(...)workflows/agentic/arena/arena/assets/<env>.py spawn.usd_path
Add/remove a cameraUse the live bridge to choose the pose from viewport/object state; do not live-register a new IsaacLab sensor.See "Adding a Camera" — bake env-locally, never in the shared embodiment
Change task wordingpreview onlyenv YAML policy.language_instruction / task_description
Change success rulePOST /script → swap term on env.unwrapped.termination_managerworkflows/agentic/arena/arena/tasks/<env>.py
Change reset randomization rangePOST /script → mutate EventTerm.pose_range; env.reset()workflows/agentic/arena/arena/tasks/<env>.py events cfg

Live-Edit Recipes

Keep SKILL.md as the router and load references/scene-edit-patterns.md for the detailed bridge recipes. Load references/asset-snippets.md for copyable object/asset snippets. The mandatory live-edit rules are:

  • Rigid bodies and articulations move through POST /object/teleport, then verify with the object's live pose.
  • Robot stand moves use POST /object/teleport with name=robot; derive x/y/yaw from the table bbox and current robot pose, keep the current live z, and verify the settled live pose over multiple reads.
  • For G1 or any floating-base robot stand move, an immediate successful teleport is not stability proof. Sample GET /object?name=robot for at least 10-15 seconds after the move (for example once per second). Treat continuous z drop, growing roll/pitch, or x/y drift as a fall; if that happens, revert to the last stable pose or adjust target/standoff/yaw and re-test before continuing to camera work or bake.
  • Embedded kinematic AssetBaseCfg props/support surfaces use helpers.move. Raw USD translation can snap back because PhysX owns the body pose.
  • Live-added bodies must be spawned through IsaacLab cfgs plus helpers.move, placed directly at their resting height, and never tensor-queried until a relaunch registers them with the GPU pipeline.
  • Live-added prim resize is delete + re-spawn + re-rest. xformOp:scale is only for existing scene assets, not bridge-spawned bodies.
  • Capture after each task-relevant edit and judge the image plus structural state before reporting success.

Adding a Camera

Do not initialize a new IsaacLab Camera/TiledCamera sensor through a live /script. On this workflow, runtime sensor registration can block the Isaac main loop and leave /script, /cameras, and /bake timing out while /health still responds. Use the live bridge to inspect objects, verify the current viewport/pose, and choose the camera eye/target. Then bake the camera as an env-local source sensor. Verify the baked camera with local-agent/validate-bake.sh <env> plus camera captures only when running the explicit fresh-source validation gate. A temporary USD-only camera prim may be used only to reason about placement; it does not prove downstream policy/dataset readiness. Load references/camera-snippets.md for source/YAML/policy/dataset wiring.

For "room camera based on current perspective view", treat the viewport as only the first pose guess. Capture the room camera before baking; it must show the main task area and task-relevant objects after all requested edits, including the support surface, robot/table relationship, tools/destinations, and newly added objects. A frame that cuts off the robot body, head/hands, table, trays/tools, or new object at an image edge is a failed candidate; do not call it "whole room" or bake it. If the frame clips or hides those objects, zoom out before baking by moving the camera farther from the task look-at point and/or widening the lens, then capture again and bake only the validated view. Leave extra margin for the baked 4:3 sensor because it can be narrower than a 16:9 viewport capture.

For bake, load references/scene-edit-patterns.md and apply the camera checklist in one pass: env-local sensor, matching task observations.policy term, YAML zenoh.camera_names, policy camera list, dataset mapping, and any stack-specific modality config. Never add an env-specific camera to a shared embodiment class, and re-record demos after changing policy/dataset cameras.

Durable Touchpoints (bake targets)

  • workflows/agentic/arena/arena/environments/<env>_environment.py: env wiring, robot stand pose.
  • workflows/agentic/arena/arena/assets/<env>.py: static scene assets.
  • workflows/agentic/arena/arena/tasks/<env>.py: reset randomization, success, task text.
  • workflows/agentic/arena/arena/runtimes/<env>.py: runtime-specific camera/state/action logic.
  • workflows/agentic/config/environments/<env>.yaml: cameras, policy language, dataset mappings.

Notes

  • assemble_trocar is inference-only. Do not add train hooks during a scene edit.
  • If adding/removing cameras, update policy.data_config, dataset.camera_mappings, and the train modality config together.
  • Scissor SO-ARM generates meta/modality.json from YAML splits and does not need dataset.modality_template_path. G1 locomanip and assemble-trocar do.

Verify (after bake)

For a normal interactive "edit, bake, and stop" prompt, do not relaunch Isaac after stopping the edit bridge. Run the cheap static checks and report that fresh-source validation was not run unless requested:

python -m py_compile <changed-python-files>
python - <<'PY'
import yaml, pathlib
for p in pathlib.Path('workflows/agentic/config/environments').glob('*.yaml'):
    yaml.safe_load(p.read_text())
PY
workflows/agentic/arena/run.sh  --env <env> --dry-run      # necessary, NOT sufficient
workflows/agentic/policy/run.sh --env <env> --dry-run

For validation, onboarding readiness, ready-to-commit checks, or a full bake gate, load references/bake-checklist.md and run local-agent/validate-bake.sh <env>. That gate intentionally opens a fresh sim window; RESULT: PASS is required for validation work.

Prerequisites

  • Workflow set up via [[i4h-workflow-setup]] (.venv present); the arena/run.sh --bridge launch depends on it.
  • An existing env id with its scene keys (the bridge edits an env in place; preserve its ids).
  • A GPU host able to launch Isaac Sim for the bridge session.

Limitations

  • Live edits are not persisted until an explicit bake; only bake on user request ("bake"/"save"/"persist"/"commit to source").
  • Support-surface rescale is source-only (spawn.scale) — moving an AssetBaseCfg surface live moves only the visual, not the collision mesh, so props fall through; relaunch to apply.
  • A live-added body is not GPU-simulated and must not be tensor-queried (a manual create_rigid_body_view(...).get_transforms() is a fatal CUDA fault); relaunch to simulate it.
  • While the bridge runs, do not edit workflows/agentic/arena/arena/assets/<env>.py, workflows/agentic/arena/arena/tasks/<env>.py, the env class, runtime, or env YAML.

Troubleshooting

  • Error: .venv / import fails or bridge won't launch - Cause: workflow not set up. Fix: run [[i4h-workflow-setup]] first.
  • Error: GET /objects / bridge URL unreachable - Cause: bridge not ready yet or wrong env URL. Fix: set BRIDGE_URL="$(workflows/agentic/arena/run.sh bridge-url --env <env>)" and wait for [agentic-arena] scene-edit bridge ready in ${RUN_DIR}/logs/bridge.log before calling endpoints.
  • Error: object moves for one frame then snaps back - Cause: it's a kinematic embedded rigid body (SCISSOR_TRAY_USD/SCISSOR_TABLE_USD), so /object/teleport and raw xformOp:translate don't hold. Fix: use helpers.move("<key>", ...) to drive the PhysX body.
  • Error: a live edit returns {"ok": false, "error": ...} - Cause: invalid request for that entity. Fix: report the exact payload and error to the user; do not restart the bridge as a fallback.

Final Response

Live session: report each bridge action, verified live pose, capture path, and whether source was baked from the collected bridge state.

After bake: report files touched, cheap static check results, and final bridge state. Report fresh-source validation results only if the user explicitly asked for that validation gate.

发现问题?提交给管理员复核

评分:

评论 (0)

暂无评论,成为第一个评论者吧!