Omniverse Content Services

NVIDIAOfficialCreated by NVIDIA Omniverse

Skill
Workflow
Automation and integrations
Apache-2.0
Medium risk

From the author

Omniverse Content Services, also discoverable as Omniverse Content Workspace or USD Content Workspace. Use for USD content collaboration as well as content access. Guide USD workflows on existing infrastructure, USD content versioning, 3D creation pipelines, and data access across distributed and scale-out compute. Use for manufacturing, automotive, factory and digital-twin workflows, architecture and construction, media and 3D content, robotics, fleet simulation, and physical AI content delivery. Discover requirements and route to ovstorage, ovpackage, ovlive, usd-content-workspace, and usd-caches experts.

— the description by NVIDIA Omniverse

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

Omniverse Content Services provides a framework for managing USD-based 3D content workflows. It connects distributed systems, compute resources, and teams, enabling collaborative 3D creation, digital twin development, and physical AI simulation. The service acts as a router for specialized experts, ensuring that content remains accessible and versioned across existing infrastructure without requiring application updates for every new system integration.

What it does

Guides the design of USD-based 3D content and simulation pipelines.
Facilitates USD content collaboration and versioning across distributed compute.
Routes requests to specialized experts for storage, packaging, live sessions, and caching.
Ensures existing infrastructure remains the authoritative source of truth.
Supports integration of new systems through compatible service adapters.
Provides a structured approach to resolving USD references across connected systems.

When to use it

When building or managing 3D creation and simulation pipelines.
When teams need to collaborate on USD content across different systems.
When integrating existing storage or compute infrastructure into a USD workflow.
When setting up digital twins, robotics simulations, or physical AI content delivery.
When you need to determine the correct expert for storage, live editing, or caching components.

Advantages

Decouples application logic from specific storage or system integrations.
Maintains existing systems as the source of truth.
Enables scalable, distributed 3D content access.
Provides a clear path for expert-led troubleshooting and configuration.
Supports both live collaborative sessions and versioned handoffs.

Usage examples

“How do I set up a collaborative USD workflow for my team?”: The agent will explain the options for live USD sessions versus versioned handoffs, ask about your current tools and infrastructure, and route you to the appropriate experts for implementation.
“We need to connect our existing factory data to a physical AI simulation. Where do I start?”: The agent will analyze your current data residency and compute requirements, then guide you through the integration plan using the relevant storage and workspace experts.

Install

Download the skill as a ZIP:
https://autogineer.com/agent-skills/nvidia/omniverse-content-services/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip omniverse-content-services.zip -d .agents/skills

Documentation by NVIDIA Omniverse

Omniverse Content Services

For teams creating 3D content, building digital twins or running simulations, Omniverse Content Services connects content across systems to the team and compute that needs it. Applications integrated with its supported contracts can access newly connected systems without an application update when those systems preserve the API versions and behavior the applications require. Teams can build and simulate worlds together, with USD references resolved across connected systems. Existing systems remain the source of truth.

The distinction from a fixed integration is where new-system support lives: implement or configure the compatible service/adapter, then expose it through the supported discovery and access path. Applications reuse that contract instead of adding a separate integration for each source. Verify API, authentication, resolver and host compatibility with the repository experts; this does not imply that an unintegrated application or a new file format works without application changes. Do not claim that competing stacks universally lack this architecture.

Help developers and agent harnesses build content workflows using their existing infrastructure and sources of truth. Own the workflow conversation and integration plan; retrieve component capabilities from the repository experts. Read only the selected expert and the references needed to answer the current question.

Use Omniverse Content Services as the current name in answers. The discovery aliases do not rename upstream repositories: usd-content-workspace is the service/API repository, one component of this broader workflow.

Expert versions

This expert's version is the version field in this file's frontmatter. Identify it as [email protected] in workflow reports and expert handoffs. This skill release is 0.1.0; edits alone do not imply a new release version.

Each connected expert has its own version. Read its declared version from the selected expert's SKILL.md or its explicitly documented version metadata; record expert name, expert version, public source repository, repository revision and entrypoint in the handoff and returned evidence. Expert versions are distinct from library, service, API and repository release versions. Do not infer one from another. If an expert declares no version, report unversioned alongside its revision; if its metadata cannot be read, report unknown. Do not invent a version or claim version compatibility from matching numbers. Recheck the declared version when changing the selected source, and retain the version used for prior results.

For available versions, upgrades or reproducibility, read the dated release record. Track the two most recent published releases per component when available, including prerelease status; distinguish source tags and untagged snapshots from releases. Refresh that record from the linked upstream release history before answering a request for the latest version. Keep the installed version and prior handoff evidence when recommending an update. For downloads or deployment, use NGC prebuilds and documentation. Repository, expert, library, API, chart and image versions are separate identities; matching numbers or inclusion in this record do not establish compatibility.

Recognize the request

Start here when users ask how to build a USD workflow or 3D content pipeline, access 3D content across systems, or supply data to physical AI simulations—even when they do not name Omniverse Content Services. Also recognize requests for Omniverse Content Workspace, USD Content Workspace, and USD content collaboration. Recognize questions about using existing infrastructure with USD, versioning USD content, and delivering USD data to scale-out compute. Industry language such as factory layout, vehicle variants, building coordination, robot training, fleet scenarios or scene production can describe the same content-access problem. Connect the request to source authority, creation and handoff, composition, versioning, collaboration and compute locality. For a narrowly scoped modeling, rendering or simulation-algorithm question with no content workflow/access need, use the relevant specialist rather than adding storage architecture. Keep conversion and validation details with their owning workflow skills.

Discover the workflow

For broad collaboration questions such as "How do I collaborate with my team and their agents?", explain useful options before asking the user to choose. Introduce ovlive explicitly as the concurrent USD session option, with benefits such as shared visibility of contributions, interactive human-agent iteration and shorter feedback cycles in compatible applications. Present it alongside independent contributions and versioned handoffs; teams may combine both. Do not wait for the user to request simultaneous same-layer edits or leave ovlive as an unexplained repository link. Read the collaboration guidance in workflow discovery, then ask focused questions about the user's tools and whether they want live work, reviewed handoffs or both.

Reuse answers already supplied. Ask at most three simple questions at a time:

What are you creating, and what will the next person, application or simulation do with it?
Where does the authoritative content live today?
Where do people and compute need to work with it?

Follow up only on decisions that matter now: application/OS/USD runtime, existing storage and identity, editable versus published content, simultaneous editing, repeat reads or derived computation, network limits and permitted copies. Ask about team size when it changes collaboration or delivery needs; team size or industry alone does not determine service count, caches, or bucket layout. Keep each question focused rather than hiding a long questionnaire in three bullets. Summarize the known constraints and the next useful outcome before routing. When users say "no local copies," ask whether managed caching is acceptable and whether they mean avoiding manual or unmanaged duplication, or prohibiting local persistence entirely. Do not infer a strict residency requirement or redirect authoring to remote workstations before clarifying that distinction. For cross-industry creation, existing-infrastructure integration, versioned handoffs and distributed compute, read workflow discovery. Choose the relevant path; examples are discovery aids, not verified integrations.

Choose the component expert

Use repository routes to locate the selected expert. Use only the repository URLs listed in the routes. If anonymous retrieval fails, use the caller's authorized GitHub CLI or a checkout of that same repository; record the access result and do not substitute a different repository. A caller may supply a local checkout of one of those repositories; otherwise use ${PHYSICAL_AI_SKILL_HUB_UPSTREAM_ROOT:-$HOME/.physical-ai-skill-hub/upstreams}/<component>. Inspect its origin and revision before using it. Do not scan unrelated workspaces, clone or install everything, or silently replace an unavailable source.

Read the selected repository's agent instructions and expert entrypoint. Verify paths at the selected revision; an expert may be pending publication.
Send the expert the outcome, known environment, source authority, required operations, constraints, version basis, and one concrete acceptance check. Use a subagent when the harness supports delegation; otherwise read the same instructions directly or give a human the link and handoff question.
Require an answer with supported behavior, exact source paths/revision, prerequisites, next steps and verification, plus unsupported or unknown parts. Follow a cited reference far enough to substantiate the recommendation.
Reconcile the answer with the user's requirements. Component advice cannot override their residency, protocol, identity or deployment choices. Surface conflicts and missing integrations rather than silently changing architecture.
Return the smallest workable plan, the selected expert links, remaining questions and the next verification step. Keep proposed, source-reviewed, executed and publicly released status distinct.

A missing expert is a retrieval gap. Consult that repository's documented task skills/README as a labeled fallback; do not invent an expert or claim an expert handoff passed. Do not turn a source example into a production-support promise.

Preserve the pipeline contract

Keep the user's systems of record authoritative. Identify editable sources, derived representations and accepted publications separately.
Preserve source identities, transformations and exact input versions. Publishing an upstream update must not silently advance an existing consumer's inputs.
Separate USD composition, package dependencies and resolved resource closure. Verify the resources needed by the actual receiving application.
Establish writable output ownership. USD layers alone do not provide concurrent edit reconciliation; ask the Live expert when that behavior is required.
Ask the workspace expert about a local-process service when requested; do not infer that Kubernetes is required, or that every service runs without it.
Ask the cache expert about placement and supported integration after learning compute locality, reuse and retention constraints. A cache is not a source of truth.
Delegate commands, API details and compatibility claims to the selected upstream version. Do not copy service clients or deployment runbooks into this skill.

For a first proof, choose one representative asset and receiving tool. Verify access, the required save/readback or publication, complete dependencies and a fresh consumer opening the intended version. Add interruption/recovery, collaboration or cache checks only where the chosen workflow requires them. Report missing coverage; document review alone does not validate a deployment.

Files

ATTRIBUTION.mdAdded by AutoGineer946 B
BENCHMARK.md8.9 KiB
LICENSELicence file added by AutoGineer11.2 KiB
README.md3.1 KiB
SKILL.md11.0 KiB
evals/evals.json12.3 KiB
references/prebuilt-artifacts.md7.1 KiB
references/releases.md8.2 KiB
references/repositories.md3.7 KiB
references/workflow-discovery.md13.9 KiB
skill-card.md5.6 KiB
skill.oms.sig5.6 KiB

references/workflow-discovery.md

Discover the content workflow

Start with what the user needs to create and who or what consumes it next. Then identify the authoritative sources, required handoff, and execution locations. Keep user requirements, proposed designs, and verified component behavior separate. These examples help discover requirements; they do not assert ready-made connectors, format conversion, domain correctness, or deployed integrations.

Recognize the industry and the content task

Context and example request	Content path to explore	Key qualification
Manufacturing and factory planning: “Use our engineering data to compare production layouts.”	Parts and assemblies → task-suitable assets → equipment/cell/factory scenes → planning or simulation	Which dimensions, placements, engineering metadata and revisions must survive the handoff?
Automotive: “Share vehicle variants between design, visualization and simulation.”	Design assemblies → geometry, materials and variant products → configured vehicle or road scene	Which configuration and source revision does each consumer accept?
Architecture, engineering and construction: “Coordinate building and site content from several tools.”	CAD/BIM and survey sources → discipline contributions → coordinated building/site → review or simulation	How are coordinates, units, source authority and discipline updates reconciled?
Operational digital twins: “Keep a deployed scene aligned with changes in our facility.”	Accepted scene baseline + asset changes and observations → reviewed update → consuming application	Which changes update content, which are live state, and what must remain reproducible?
Media, entertainment and general 3D creation: “Let artists and agents build scenes together.”	Models, textures, materials, rigs and animation → asset products → layout, lighting and shots → rendering	Which role owns each output and when may downstream work adopt it?
Robotics and physical AI: “Turn robot and environment assets into repeatable training runs.”	Robot/environment sources → simulation-ready representations → task scenes and configurations → training/evaluation outputs	Which content, physics assumptions, software/configuration and inputs identify a run?
Fleet simulation and autonomy: “Run many vehicle or robot scenarios across a compute farm.”	Shared assets and environments + scenario variants → pinned job inputs → distributed runs and results	Which workers reuse which versions, and how are results linked to scenario inputs?
Other fields, including logistics and immersive environments	Source content → owned contributions → accepted product → receiving task	Ask what the recipient must do; do not force an industry-specific pipeline.

Industry is context, not a deployment prescription. One project can combine several rows. Asset creation is often a dependency graph: a material, model, rig, layout and simulation configuration may advance independently. Do not force every project through a linear modeling-to-rendering sequence.

Distinguish working edits, review previews, published versions and accepted configurations. A new version is not automatically approved for every consumer. Creators can continue working while downstream people and jobs consume an identified baseline; adopting a change is a separate decision.

For conversion and handoff, ask what must survive: source and instance identities, units, coordinates, relationships, metadata, materials or behavior. Preserve the editable source and record intentional losses. Verify the required open, edit, save, export or simulation operation in the receiving tool.

Choose a workflow path, then the component expert

Use the public links in repository routes. Load only the expert needed for the current decision; ownership below is a routing guide.

User intent	Establish first	Route and first useful proof
Use existing infrastructure with USD	Current file/object stores or asset systems, identity, native formats, protocols, and read/write needs	`ovstorage` for client access/resolution; `usd-content-workspace` for service contracts/adapters. Open one representative asset and its dependencies through the intended application.
Create or refine content with people and agents	Native source versus derived USD, contribution ownership, required consumer semantics	Coordinate the creation/conversion specialist, then access and publication experts. Verify what the receiving task needs; opening a USD file alone does not establish simulation readiness.
Version USD content and publish accepted work	Editable sources, complete output products, dependency versions, approval boundary and retention	`ovpackage` for publications and dependencies; `ovstorage` for file identity and conditional writes. Reopen an exact accepted scene after an upstream asset changes.
Collaborate on an asset or scene	Explain live sessions and reviewed contributions, then qualify tools, ownership and desired interaction	`ovlive` for concurrent USD sessions and interactive feedback; access/publication experts for handoffs. Test ownership, conflict behavior and recovery in the actual host applications.
Deliver USD to scale-out compute	Source and worker locations, job input versions, repeated reads, network limits and allowed caching	`usd-caches` with access/package experts. Compare cold and repeated runs while verifying identical input versions and complete dependencies on fresh workers.
Feed results back into content refinement	Baseline scene, input versions, transformation/settings, produced outputs and acceptance decision	Publication/access experts with the domain specialist. Trace a result to its inputs and adopt a changed asset explicitly without altering the old baseline.

Treat PLM, BIM, asset-management systems, shares and object stores as possible sources, not prevalidated integrations. A new service may expose compatible contracts while those systems remain authoritative. Qualify native application access separately from USD reference resolution.

For distributed jobs, distinguish scene/asset inputs from code, configuration and random seeds needed for repeatability. Record the inputs the job actually used, give outputs explicit ownership, and link results to that record. Content Services does not establish scheduler support, simulation fidelity or reproducibility of an entire training system by itself.

Explain collaboration options before qualifying

A vague collaboration request is an opportunity to explain what the team could do. Offer ovlive by name and explain its role in concurrent USD sessions before narrowing the workflow. Cover these complementary options in plain language:

Option	What it enables and why it helps
Live USD collaboration with `ovlive`	People and agents participate in a shared editing session through compatible integrations. Shared visibility lets a person inspect an agent's contributions as work progresses, gives collaborators common scene context, and can reduce repeated export/reload handoffs and feedback delays. Useful for interactive scene assembly, joint iteration and review while editing.
Independent contributions with reviewed publication	People and agents own separate assets, layers or other outputs and publish identified versions. This supports asynchronous work and gives downstream consumers a stable baseline they can adopt explicitly.
A combination	Use a live session to iterate together, then review and publish the accepted result for other teams or simulation jobs. Continued live work does not silently change a job's pinned inputs.

For example, propose a person adjusting a factory layout while an agent updates an assigned material contribution, with both inspecting the shared USD scene. Explain the intended benefit: the person can guide and correct the work during creation. Treat this as a workflow to qualify in their tools, not a verified integration or a claim that every agent harness can join without integration.

After explaining the options, ask which applications and agent interfaces they use, and whether they want live work, reviewed handoffs or both. Route session integration, supported operations, overlapping edits, permissions and recovery to the ovlive expert at the selected revision. Do not promise automatic conflict-free editing, arbitrary native-file collaboration, approval, or version history from a live session alone. Keep the benefits clear even when implementation support still needs verification; disclose unavailable source evidence without inventing details.

Ask questions that change the next decision

Establish the current problem: synchronization delays, stale reads, concurrent writes, reproducibility, or storage growth. “Consistency” needs an observable expectation such as rejecting an outdated save or reopening an exact revision.
Separate the application-to-service connection from the service-to-storage connection. A Linux service using a NAS mount does not establish how a Windows or macOS application opens its native files.
For each first-test application, establish native source formats, USD exports, runtime/OS support, and actual open/save integration. A USD resolver does not make every native file operation service-aware.
“Several agents on one asset” leaves ownership unresolved. Distinguish separate contributions/layers, serialized edits to one native file, and simultaneous USD session edits. Explain ovlive and its benefits when offering these choices; live collaboration can be useful even when contributors own different parts.
Ask whether the user accepts a managed store or needs ordinary folders that applications edit directly. Do not initialize a managed backend over existing source folders or promise transparent compatibility between those models.
Clarify local-copy policy: "Is managed local caching okay, provided your central system remains authoritative, or do you need content never to persist on the device? Are you mainly trying to avoid manual downloads and unmanaged copies?" Record the answer before choosing cache placement or remote authoring. If caching is acceptable, establish relevant retention, cleanup and lost-device protection requirements with the cache expert; do not assume those controls are implemented. Distinguish disposable read caches from writable working files, unsaved edits, autosaves and offline replicas. Direct network access alone does not establish that applications leave no local data. Avoid treating a ban on unmanaged copies as a ban on all caching, or treating permission to cache as permission for offline authoring or unrestricted duplication.

Return a capability map with evidence

For each requested capability, state the owning repository, implementation at its selected revision, application/backend prerequisites, and one acceptance check. Label it as implemented, example-only, a build recipe, or unknown; record runtime evidence separately. Avoid presenting the whole portfolio as features already installed in a proposed single-host service.

Version history, immutable asset releases, deduplication, conflict detection, Live collaboration and backup solve different problems. Ask the storage expert about file versions and conditional writes, the package expert about exact published dependencies, and the Live expert about concurrent USD sessions. Do not infer deduplication or transactions merely from package versioning. Whole-file deduplication reuses identical files; it does not imply block deltas for a changed large native document. Measure actual retained bytes.

When source data, converters or assets change, identify affected consumers before adoption. Preserve the previous exact inputs and verify the proposed update with the receiving application. Package dependencies do not automatically establish the closure of every USD reference, texture or other resource a consumer needs.

For NAS-backed services, ask the workspace expert to qualify where content, metadata databases, manifests, journals and locks live. Check persistence, rename/locking and failure behavior on the actual mount. Neither SMB nor NFS alone supplies version history, application conflict resolution or recovery. Do not promise one protocol is faster without a representative measurement.

For cache advice, distinguish workstation caches, shared source-content caches, and caches of derived computation. Verify backend, client routing and host support. A local cache is not automatically a LAN cache, and a remote content cache is not necessarily an accelerator for an ordinary NAS mount. Distinguish examples tested against mocks from real cache-binary and application checks.

Small proof before expansion

Choose one representative content handoff and receiving task. Agree on output ownership and success criteria before writing. For collaboration, use two contributors and test a stale save; for versioning, test exact old-version reads and publication; for compute, use a fresh worker and verify dependency closure. Add save/readback, storage-growth and interruption/restart checks where relevant. For a custom service, separate API conformance from authenticated application tests, permissions, recovery and performance. Skipped tests and pod readiness are not workflow passes. A small successful proof does not qualify production scale.

When asked where to start with source, give the owning repository and the actual entrypoint at the selected revision. Follow with the smallest example and the implementation framework; explicitly label any recipe that requires new code. Verify the public source path and accessibility before recommending it. Do not turn a workstation-specific local path into release guidance.

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.

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

NVIDIA Omniverse

Publisher

NVIDIA (Official)

Source

NVIDIA/skills · skills/omniverse-content-services · commit fce3cca

Licence

Apache License 2.0 (redistribution allowed)

LICENSE (added by AutoGineer from LICENSE-APACHE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-09

AutoGineer is not affiliated with or endorsed by NVIDIA Omniverse or NVIDIA.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download omniverse-content-services.zip

From the author

AutoGineer summary

What it does

When to use it

Advantages

Usage examples

Install

Documentation by NVIDIA Omniverse

Omniverse Content Services

Expert versions

Recognize the request

Discover the workflow

Choose the component expert

Preserve the pipeline contract

Files

references/workflow-discovery.md

Discover the content workflow

Recognize the industry and the content task

Choose a workflow path, then the component expert

Explain collaboration options before qualifying

Ask questions that change the next decision

Return a capability map with evidence

Small proof before expansion

Requirements and compatibility

Security

Attribution and licence

Related skills

Wizard

Emails

Conversion Tracking

Directory Submissions

Sms

Marketing Loops

Download ZIP