SimReady Add Validator

Purpose

Use this skill to implement objective validation for one or more requirement IDs. Validators should report failures against the exact requirement code documented in the capability.

If the rule already exists but is wrong or incomplete, use simready-foundation-update-validator.

Prerequisites

Before editing, read:

• AGENTS.md
• nv_core/sr_specs/docs/guides/features/features.md
• nv_core/sr_specs/docs/guides/features_expansion_workflow.md
• nv_core/sr_specs/docs/guides/naming_conventions.md
• target requirement markdown
• target capability validation.py
• nearby checker classes in the same capability
• feature manifests that include the requirement

Inputs

Collect or infer:

Instructions

Use this checklist when changing the repository:

1. Confirm requirement docs exist and the intended check is objective.
2. Inspect existing validators in the capability and reuse local helper patterns.
3. Add a checker class or function in validation.py with the correct registration decorators/imports used by the capability.
4. Register every requirement ID the checker enforces and pass the matching requirement when reporting each failure.
5. Keep failure messages specific, deterministic, and actionable.
6. Handle missing default prims, invalid paths, unloaded/abstract prims, variants, and composed stages consistently with neighboring validators.
7. Add focused pass/fail tests or sample validation instructions where the repo has a test pattern.
8. Update requirement docs only if implementation clarifies edge cases.
9. Validate consistency:
   • validator imports successfully where possible
   • requirement IDs match documented codes
   • failure messages match docs
   • feature manifests include only registered requirements when executable validation is expected

Examples

Example request:

Add a validator for a SimReady factory connection point requirement.

Expected result summary:

changed_files: new docs, manifests, indexes, or validation scaffolding
validation: focused static checks and any relevant docs/build checks
remaining_gaps: requirement, validator, adapter, profile, or runtime-test follow-up

Policies

• Do not validate subjective guidance as a hard failure unless the requirement defines objective criteria.
• Prefer one clear checker per rule family over tangled mega-checkers.
• Avoid changing unrelated validators while adding a new one.
• Use warnings only when the validation framework supports them and the requirement is advisory.
• If local Omniverse/OAV packages are unavailable, document the narrowed validation you could run.

Limitations

• Do not mutate published feature or profile versions in place.
• Do not invent requirement IDs or validator behavior when the contract is ambiguous; record the question.
• Do not skip index, manifest, validation, or downstream follow-up notes.

Troubleshooting

• Error: the new concept overlaps an existing artifact. Solution: update the existing capability, requirement, feature, profile, or adapter instead.
• Error: names or IDs conflict. Solution: re-check naming conventions and nearby indexes before editing further.
• Error: validation strategy is unclear. Solution: document deferred validation and the exact follow-up skill.

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: