SimReady Update Feature Adapter

Purpose

Use this skill when an existing feature adapter no longer matches exact source/target FET_###_<RUNTIME> feature contracts, produces invalid USD, misses a required mutation, or needs new profile-version support.

Prerequisites

Before editing, read:

• AGENTS.md
• nv_core/sr_specs/docs/guides/feature_adapters/feature_adapters.md
• target adapter file
• source and target feature manifests
• source and target profile versions
• existing adapter tests or validation reports

Inputs

Collect or infer:

Instructions

Use this checklist when changing the repository:

1. Compare adapter metadata with actual source/target manifests and profile versions. Confirm feature names use FET_###_<RUNTIME> and feature versions are exact integers.
2. Reproduce or inspect the failed upgrade when possible.
3. Determine whether to update the existing adapter or add a new adapter for a new exact version path. Prefer adding a new path when published source/target versions must keep their old behavior.
4. Patch transformation logic narrowly:
   • preserve unrelated data
   • keep output deterministic
   • avoid source-stage mutation
   • save output stage correctly
5. Update metadata only when the supported feature path changes.
6. Update tests or manual validation instructions to cover the corrected path.
7. Update profile migration notes if adapter behavior affects profile upgrades.
8. Confirm every changed feature difference in the profile transformation still has a direct adapter path or documented blocker.
9. Validate source-to-target behavior against the relevant feature/profile requirements when tooling is available.

Examples

Example request:

Update a SimReady feature adapter for a new exact source and target feature version.

Expected result summary:

changed_files: updated docs, manifests, indexes, validators, or adapters
validation: focused checks for the changed contract
remaining_gaps: downstream feature, profile, adapter, or runtime-test follow-up

Policies

• Do not change an adapter to target a different feature version without preserving the old upgrade path when it is still published.
• Prefer adding a new adapter for new feature versions over mutating old behavior.
• Do not add broad catch-all mutation logic that could damage assets outside the adapter contract.
• If a required mutation needs user intent, report a blocked adapter path.

Limitations

• Do not silently change published contracts; add versions when behavior changes.
• Do not update docs without checking validator, manifest, profile, adapter, and runtime-test impact.
• Do not broaden a change beyond the selected requirement, capability, feature, profile, validator, or adapter.

Troubleshooting

• Error: the requested change alters a published contract. Solution: create a new version and preserve the old artifact.
• Error: docs and machine-readable manifests diverge. Solution: make the JSON/TOML and markdown agree, then rerun focused checks.
• Error: downstream profile or adapter impact is unclear. Solution: list the affected artifacts before making broad edits.

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: