NVIDIA · jensjebens · Jun 16, 2026 · Jun 24, 2026
@@ -1,4 +1,4 @@
 interface:
   display_name: "USD Performance Tuning"
   short_description: "Diagnose and optimize OpenUSD scene performance"
-  default_prompt: "Use $omniverse-usd-performance-tuning to diagnose and optimize a USD stage: confirm runtime context, capture baseline evidence, assess structure, route validation, run approved Scene Optimizer work, compare results, and produce the final optimization report."
+  default_prompt: "Use $omniverse-usd-performance-tuning to diagnose and optimize a USD stage: confirm runtime context, capture baseline evidence, assess structure, route validation, run approved Usd Optimize work, compare results, and produce the final optimization report."
@@ -42,7 +42,7 @@ Guide CAD-to-USD conversion diagnosis before optimization. Capture the source fo
 
 ## Limitations
 
-- Does not execute conversion or Scene Optimizer operations.
+- Does not execute conversion or Usd Optimize operations.
 - Cannot guarantee a tessellation knob exists for every source format or backend.
 - Post-conversion performance issues still need composition audit and validation.
 

@@ -59,7 +59,7 @@ terminal optimization report.
 ## Regression Handling
 
 When a metric regresses by more than 5%, name the metric, quantify the change,
-and correlate it with what changed. File-size growth after Scene Optimizer
+and correlate it with what changed. File-size growth after Usd Optimize
 operations may indicate USDC save behavior. Prim-count growth after instancing
 can be acceptable when instances compensate for added prototypes. Steady-state
 frame regressions are more serious than one-time startup regressions.
@@ -36,13 +36,13 @@ or had no measurable effect.
 Before reporting the verdict, prepend the **compact one-liner** from
 `skills/omniverse-usd-performance-tuning/references/setup-usd-performance-tuning/references/runtime-context-header.md` (Format B). The verdict is only
 reproducible against the runtime that produced it; users reading the verdict
-later need to know which Kit / Scene Optimizer / Asset Validator versions
+later need to know which Kit / Usd Optimize / usd-validation-nvidia versions
 were in effect. Read from the `runtime_context` block in
 `<output_path>/setup-preflight.json` (canonical location; see
 `skills/omniverse-usd-performance-tuning/references/setup-usd-performance-tuning/references/runtime-context-header.md` *Where artifacts live*).
 
 ```
-[Kit: {runtime_context.kit.application} {runtime_context.kit.version}  |  SO: {runtime_context.sceneOptimizer.version}  |  AV: {runtime_context.assetValidator.version}]
+[Kit: {runtime_context.kit.application} {runtime_context.kit.version}  |  SO: {runtime_context.usdOptimize.version}  |  AV: {runtime_context.assetValidator.version}]
 ```
 
 If a profile capture spans more than one runtime (rare — usually means the
@@ -144,7 +144,7 @@ If any metric regressed >5%:
 1. Report which metric regressed and by how much.
 2. Correlate with what changed — did file size grow? Did prim count increase?
 3. Check for known causes:
-   - Size regression after SO operations → likely USDC `Layer.Save()` bloat
+   - Size regression after Usd Optimize operations → likely USDC `Layer.Save()` bloat
      (see `skills/omniverse-usd-performance-tuning/references/usd-structure-assessment/references/usd-edit-target-planner/references/output-saving.md`).
    - Load time regression after adding instancing → unexpected, investigate
      prototype count vs instance count ratio.
@@ -163,7 +163,7 @@ omniverse-usd-performance-tuning
 → usd-validation-runner (master router; uses skills/omniverse-usd-performance-tuning/references/usd-validation-runner/README.md for tier detail and selected-probe policy)
 → restructure-decision (Phase 2e gate)
 → instancing-readiness (if applicable)
-→ SO operations / instancing
+→ Usd Optimize operations / instancing
 → apply-restructure (Phase 5 ref-remap)
 → profile-stage (AFTER)
 → compare-profiles

@@ -0,0 +1,50 @@
+# Large Monolithic Repeated-CAD Optimization Pass
+
+<!-- SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. -->
+<!-- SPDX-License-Identifier: Apache-2.0 -->
+
+Execution contract for large monolithic CAD-style stages with many repeated
+meshes and low or no instance/prototype use, when the user asks for the safest
+useful optimization before decimation. Referenced from the
+`omniverse-usd-performance-tuning` SKILL.md *Optimization ordering* section.
+
+- Treat lossless hierarchy/geometry deduplication or prototype/reference
+  restructuring as the primary optimization. A USDC/crate repack is only a
+  secondary packaging step and is not sufficient by itself — and a repack is the
+  free re-encode any export achieves, so its disk delta must be attributed to
+  re-encoding, not to the optimization (see the repack-normalized footprint
+  facts below).
+- Do not run decimation, primitive fitting, quantization, fuzzy matching, or
+  topology edits unless the user explicitly approves that lossy operation.
+- Write a separate optimized stage; never overwrite the source unless the user
+  explicitly approves in-place mutation.
+
+- For large or binary/crate USD artifacts, use binary-safe file operations (for example shell copy/export tools or Python opened in `rb`/`wb` mode). Do not pass byte content to text-only write APIs.
+- Record baseline and after metrics for file size, prim count, mesh count,
+  repeated mesh families, affected mesh prims, authored references, payloads,
+  instanceable/prototype usage, and validation status.
+- Run targeted before/after validation such as open/load checks, the
+  minimum-openability pass owned by `usd-validation-runner`, and affected-prim
+  composition checks. Treat expensive whole-stage equivalence, visibility,
+  duplicate-family, or exhaustive composition sweeps as full-sweep validation;
+  for large CAD stages, skip or defer those unless explicitly requested. Do not
+  describe a minimum-openability log as "full validation"; it is checker
+  evidence, not the full-sweep policy.
+- In the final response, include a compact "large-stage policy" ledger with
+  these exact facts: baseline is a large monolithic CAD-style repeated-mesh
+  stage; baseline authored references/payloads/instanceable or prototype
+  counts; operation order; optimized output path; source-not-overwritten
+  status; mesh/prim count before and after; repeated-family and affected-mesh
+  counts; instanceable/prototype/reference changes; targeted before/after
+  validation evidence; and
+  `full_sweep_validation: skipped/deferred due to large-stage policy`.
+- Report footprint honestly with all three repack-normalized sizes: raw input,
+  the repack-normalized baseline (input losslessly re-crated to the same
+  encoding, zero dedupe), and optimized — and attribute the split (`X% is
+  re-encoding; Y% is the structural optimization`). Score the structural win
+  against the normalized baseline, not the raw input. Populate the report's
+  `footprint` block; presenting the repack delta as the optimization win fails
+  the report gate.
+- Also state which runtime metrics were not measured. Do not claim FPS, VRAM,
+  Hydra, RTX, renderer, or draw-call wins unless those metrics were actually
+  captured.
@@ -21,7 +21,7 @@ Return a concise status or report that names the input, selected runtime or evid
 ## Purpose
 
 Use this before opening `omniverse://` assets from Kit, USD Python, validators,
-or Scene Optimizer operations.
+or Usd Optimize operations.
 
 Confirm the agent can access the remote stage and explain any authentication
 side effects. A browser window or SSO prompt is expected on first access and is

@@ -13,79 +13,43 @@ version: "0.1.0"
 
 # Operation Classification Rubric
 
-Every entry in `references/operations/_curation.json` has a `status` field assigned by this rubric. Every entry's `rationale` field must cite the specific clause below it satisfies, with the format `<status>: <clause>: <one-sentence justification>`.
+Every operation's nested `curation` block in `references/operations/operations.json` has a `status` field. **`status` is DERIVED, not hand-authored**: it is computed by the upstream status-derivation rubric (run during skill development) and materialized onto each entry, the same way the index is regenerated from source. The development-time coverage audit rewrites any drifted statuses.
 
-This rubric is local routing policy only. Scene Optimizer operation mechanics
+**The upstream status-derivation rubric is the single source of truth for the algorithm** — the derivation precedence (deprecated/specialty overrides → destructive→specialty → read-only→analysis → refs-present→canonical → else documentary), the reference-evidence rule (`wired_into` non-empty OR `pipelines` non-empty), and the clause definitions (C1/C2, S1/S2, A1–A3, D1–D3, X1/X2). This file does NOT restate them; it explains what each tier *means* for agent behavior and the hand-authored override contract.
+
+This rubric is local routing policy only. Usd Optimize operation mechanics
 belong to upstream `usd-optimize`; use
 [`usd-optimize` upstream handoff](../upstreams/usd-optimize.md) for the central
 package and operation-guide resolution rule.
 
-## status: canonical
-
-The op is part of the standard 7-phase optimization flow described in
-`skills/omniverse-usd-performance-tuning/references/workflow.md`. At
-least one local workflow reference routes to it, or upstream `usd-optimize`
-names it in a public pipeline that this workflow deliberately adopts. The
-agent reaches for canonical ops by default.
-
-Required evidence:
-
-- **C1.** The op has at least one `"operation": "<key>"` reference in the catalog skill or nested workflow references OR in an adopted upstream `usd-optimize` named pipeline, **and**
-- **C2.** The op is `loss_class: lossless` or `bounded-loss` (not `destructive`).
-
-A `destructive` op is `specialty`, never `canonical`, regardless of how often it appears.
-
-## status: specialty
-
-The op is gated behind explicit user confirmation in `so-run-operations`'s destructive-op table, or has narrow workflow-specific applicability (e.g., `pythonScript` used by `so-create-proxy` for USD authoring glue).
-
-Required evidence:
-
-- **S1.** The op is `loss_class: destructive` and appears in the `so-run-operations` destructive-op confirmation table, **or**
-- **S2.** The op is referenced in a skill body that handles a specific workflow (proxy creation, restructure orchestration, etc.) and the rationale names that workflow.
-
-## status: analysis
+## What each tier means for agent selection
 
-The op is read-only and produces a report/finding; used by `so-run-validators` or `so-interpret-validators`. Never mutates the stage.
+The code computes the label; this is what the label means when the agent picks an op:
 
-Required evidence:
+- **`canonical`** — reach for it by default; part of the standard 7-phase optimization flow.
+- **`specialty`** — reach for it only on an explicit need or named workflow (e.g. proxy creation, restructure orchestration); not a default choice.
+- **`analysis`** — a read-only finding/report producer; surface it to inspect, never to mutate the stage.
+- **`documentary`** — recommend only when the user explicitly names the op or describes a use case it uniquely fits.
+- **`deprecated`** — warn before recommending, and name the replacement.
 
-- **A1.** The op is `loss_class: lossless`, **and**
-- **A2.** The op produces a structured finding rather than a transformed stage (often a `find*`, `count*`, or `print*` op), **and**
-- **A3.** The op is either currently wired into `so-run-validators`/`so-interpret-validators` OR is a clear candidate for that wiring (`wired_into` may be empty for future-candidate analysis ops).
+## Overrides and `rationale`
 
-## status: documentary
+`deprecated` and `specialty` are the only values `curation.status_override` may take — they are the two statuses the per-op data cannot express, so they are authored, not derived. Each override entry carries an authored `rationale` (forbidden on every other entry):
 
-The op has a local routing stub for completeness but no local workflow route reaches for it. The agent is allowed to recommend it only when the user explicitly names the op or describes a use case it uniquely fits.
-
-Required evidence:
-
-- **D1.** The op has zero `"operation": "<key>"` references in skill bodies, **and**
-- **D2.** The op is not in an adopted upstream `usd-optimize` pipeline for this workflow, **and**
-- **D3.** The op is not in the tuning workflow's recommended-ops sections.
-
-`documentary` ops MAY appear as a passing mention in the tuning workflow's
-op-role index without being recommended for use — that doesn't disqualify them
-from this tier.
-
-## status: deprecated
-
-The op exists upstream but this skill pack actively discourages its use. The agent should warn before recommending one.
-
-Required evidence:
-
-- **X1.** The op's upstream behavior is known to be replaced by a better-supported alternative documented in this repo, **and**
-- **X2.** The rationale names the recommended replacement.
-
----
+- `deprecated` — `"deprecated: <replacement>: <one-sentence justification naming the recommended replacement>"`.
+- `specialty` (S2) — `"specialty: <one-sentence justification naming the narrow workflow / explicit-need constraint>"`.
 
-## How to cite a clause in `rationale`
+Authored shape on an override entry:
 
-Format: `<status>: <clause>: <one-sentence justification>`. Examples:
+```json
+"curation": {
+  "status": "specialty",
+  "status_override": "specialty",
+  "rationale": "specialty: legacy standalone welder superseded by meshCleanup; reach for it only when the user explicitly needs the upstream-documented behavior.",
+  "wired_into": ["skills/.../workflow.md"]
+}
+```
 
-- `"canonical: C1+C2: invoked by so-run-operations destructive-op table; loss_class bounded-loss."`
-- `"specialty: S1: destructive; appears in so-run-operations destructive-op confirmation table."`
-- `"analysis: A1+A2: lossless finding-producer; candidate for so-interpret-validators wiring."`
-- `"documentary: D1+D2+D3: no JSON references, no pipeline, no workflow recommendation."`
+Non-override entries carry just the generated `status` and the authored `wired_into` evidence — no `rationale`.
 
-The schema at `scripts/operation-curation.schema.json` enforces that every entry's `rationale` starts with `<status>:` matching the entry's declared `status`. The coverage audit additionally verifies that `canonical`-status ops have a non-empty `wired_into`, and that each `wired_into` target file actually references the op.
+The schema at `scripts/operations.schema.json` describes the `curation` block (the `status` enum, the `status_override` enum, and the `rationale`-only-on-override rule). The coverage audit enforces it: it derives `status` (failing on any mismatch with the materialized value), requires a `rationale` starting with `<status>:` whenever `status_override` is set and forbids `rationale` otherwise, verifies `canonical`-status ops have a non-empty `wired_into`, and verifies each `wired_into` target file actually references the op.