simready-foundation-validate-foundation-change

SimReady Validate Foundation Change

Purpose

Use this skill after changing SimReady requirements, capabilities, validators, features, profiles, adapters, runtime tests, or related skills. It is a consistency audit, not a repair skill. Repair findings with the targeted add/update skills.

Prerequisites

Before validating, read:

• AGENTS.md
• the changed files
• relevant guides for the changed surface
• affected feature manifests and profiles
• nv_core/sr_specs/docs/guides/benchmark/benchmark.md and its linked pages when runtime evidence or _testing/ artifacts are involved

Inputs

Collect or infer:

Instructions

Use this checklist when changing the repository:

1. Inspect the diff and classify touched surfaces.
2. Requirement/capability checks:
   • every requirement doc has a unique code
   • every requirement doc is indexed by its capability
   • capability overview and requirements.md agree
   • custom names follow naming conventions
3. Validator checks:
   • validators register documented requirement IDs
   • failure messages are requirement-specific
   • docs and validator behavior agree
   • imports/registration paths are updated
4. Feature checks:
   • JSON manifests parse
   • feature names use FET_###_<RUNTIME>
   • feature versions are dotted semantic versions; do not reintroduce the reverted bare-integer version experiment
   • JSON manifest filenames match FET_###_<RUNTIME>-<semantic-version>.json
   • feature markdown filenames match FET_###_<RUNTIME>.md
   • id, version, display_name, path, dependencies, and requirements are present as expected
   • every requirement ID exists
   • every dependency feature/version exists
   • dependency versions are exact and dependency chains are not circular
   • feature expansion removes conflicting base requirements instead of stacking mutually exclusive rules
   • feature markdown keeps the canonical feature-template.md sections: Feature, Description, Dependency Graph, Use Cases, Requirements, Pipelines, Samples, Benchmarks, and Adapters
   • feature markdown documents the same semantic versions and requirements as the JSON manifests
   • features/features.md and dependency graph are updated when needed
   • new or contract-changing features have a matching skills/simready-foundation-conform-fet-###-<runtime> skill, or the change documents why no asset-repair skill is safe/applicable
5. Profile checks:
   • the per-profile TOML files in profiles/ parse
   • existing profile versions are preserved unless explicitly editorial
   • every referenced feature name/semantic feature version exists
   • profile markdown and profiles.md agree with TOML
6. Adapter checks:
   • adapter metadata references existing feature names and semantic feature versions
   • every changed profile feature difference has an adapter path or documented blocker
7. Runtime test checks:
   • Python test sources changed, not generated plans, result JSON, or reports
   • tier-owned tests live under nv_core/tiers/<tier>/<test-package>/, where <test-package> is the importable package declared by that tier's descriptor; retired nv_core/runtime_tests and nv_core/testing_tools trees are not recreated
   • the tier wheel includes the test package and its descriptor's runtime_tests_path points directly to that importable directory
   • independent test-only wheels use simready_benchmark.tests; unpublished development packs remain discoverable through --tests-path
   • each independently reportable test has its own module and @test registration
   • feature mappings, name/version, engine requirements, configuration defaults, description, and expected_video are complete; do not add the removed requirement decorator keyword
   • focused unit and registration tests cover non-runtime behavior
   • engine assumptions and reproduction commands are documented
   • expected pass/fail/skip signals and report artifacts are clear
8. Skill/layout checks:
   • skills is source of truth
   • .codex/skills and .claude/skills remain compatibility links/placeholders
   • skill folder name, SKILL.md name, and assets/openai.yaml prompt token align
   • conform skill source-of-truth feature manifests, requirement IDs, validators, repair policy, blocked cases, and summary fields align with the changed feature contract
9. Run available validation commands:
   • JSON/TOML parse checks
   • targeted Python syntax/import checks
   • simready-validate when installed
   • USD/PXR or runtime tests when available and relevant
10. Report findings ordered by severity with file paths and next repair skill.

Examples

Example request:

Validate a SimReady Foundation change that adds a feature, profile, validator, and conform skill.

Expected result summary:

findings: file paths and contract drift found
validation: checks reviewed or rerun
next_step: targeted add/update/conform skill for each repair

Policies

• Do not hide unavailable tooling. State exactly which checks could not run.
• Do not treat docs-only validation as equivalent to runtime validation.
• Prefer targeted findings over broad style advice.
• If profile markdown and TOML disagree, TOML is the machine-readable source of truth.
• If a published version was mutated in place, flag it unless the change is clearly editorial.

Limitations

• This skill audits consistency; make repairs only when the user asks for them.
• Do not treat missing runtime evidence as passing; record the validation gap.
• Do not collapse versioned SimReady artifacts into mutable in-place edits.

Troubleshooting

• Error: a referenced artifact is missing. Solution: report the missing path and the upstream index or manifest that points to it.
• Error: docs and validators disagree. Solution: identify which contract is authoritative before recommending a repair.
• Error: runtime evidence is absent. Solution: mark it as a validation gap rather than a pass.

Resources

• assets/openai.yaml preserves optional UI metadata for clients that read skill display hints. It is not required for the workflow.

Summary Format

Report: