SKILL.md
SimReady Update Feature Adapter
Purpose
Use this skill when an existing feature adapter no longer matches source/target feature contracts, produces invalid USD, misses a required mutation, or needs new profile-version support.
Prerequisites
Before editing, read:
AGENTS.mdnvcore/srspecs/docs/guides/featureadapters/featureadapters.md- target adapter file
- source and target feature manifests
- source and target profile versions
- existing adapter tests or validation reports
Inputs
Collect or infer:
| Input | Requirement |
|---|---|
adapter_path |
Existing adapter file. |
source_feature |
Input feature ID/version currently supported. |
target_feature |
Output feature ID/version currently supported. |
bugorgap |
Missing mutation, bad metadata, invalid output, non-idempotence, crash, or profile drift. |
newfeatureversions |
Updated feature versions if the adapter should support a new path. |
test_assets |
Assets or reports that show the problem. |
Instructions
Use this checklist when changing the repository:
- Compare adapter metadata with actual source/target manifests and profile versions.
- Reproduce or inspect the failed upgrade when possible.
- 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.
- Patch transformation logic narrowly:
- preserve unrelated data - keep output deterministic - avoid source-stage mutation - save output stage correctly
- Update metadata only when the supported feature path changes.
- Update tests or manual validation instructions to cover the corrected path.
- Update profile migration notes if adapter behavior affects profile upgrades.
- Confirm every changed feature difference in the profile transformation still has a direct adapter path or documented blocker.
- 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.yamlpreserves optional UI metadata for clients that read skill display hints. It is not required for the workflow.
Summary Format
Report:
| Field | Meaning |
|---|---|
adapter_path |
Adapter changed. |
feature_path |
Input and output feature IDs/versions. |
change_type |
Bug fix, new version path, or docs/test update. |
mutation_summary |
USD behavior changed. |
tests |
Tests/assets run. |
profile_followup |
Profile docs or migration notes changed/needed. |
validation |
Remaining gaps. |