simready-foundation-update-profile
Use for updating SimReady profile versions, feature bundles, docs, and adapter notes.
npx skills add https://github.com/nvidia/simready-foundation --skill simready-foundation-update-profileSimReady Update Profile
Purpose
Use this skill to change an existing profile. Profile versions are immutable, so the normal operation is to add a new version under the existing profile table in profiles.toml and update documentation to describe the new version.
Edit an existing profile version in place only for a clear typo, comment correction, markdown-only clarification, or unpublished draft content that the user explicitly says may be changed in place.
Prerequisites
Before editing, read:
AGENTS.mdnv_core/sr_specs/docs/guides/guides.mdnv_core/sr_specs/docs/guides/profiles/profiles.mdnv_core/sr_specs/docs/guides/feature_adapters/feature_adapters.mdnv_core/sr_specs/docs/profiles/profiles.toml- target profile markdown
nv_core/sr_specs/docs/profiles/profiles.md- selected feature JSON manifests
nv_core/sr_specs/docs/features/feature-dependency-graph.md
Inputs
Collect or infer:
| Input | Requirement |
|---|---|
profile_name | Existing profile table name. |
base_version | Existing version to copy from. |
new_version | New semantic version for changed feature bundle. |
feature_changes | Added, removed, or changed exact feature IDs/versions. |
reason | Runtime, validation, asset class, or dependency reason for the update. |
adapter_plan | Required adapters or migration notes from old to new profile. |
Instructions
Use this checklist when changing the repository:
- Classify the change.
- Editorial changes may edit docs or comments in place.
- Feature bundle changes require a new profile version.
- Confirm the profile and base version exist in
profiles.toml. - Confirm every new feature ID/version exists as a JSON manifest before referencing it.
- Add the new profile version by copying the base version feature list and applying the requested changes.
- Preserve old profile versions exactly unless the user explicitly requested an editorial fix.
- Update the target profile markdown:
- add or update the version block
- document changed feature versions
- describe migration and adapter implications
- keep authoring guidance synchronized with the new feature list
- Update
nv_core/sr_specs/docs/profiles/profiles.mdso the profile summary lists the available versions and current feature bundle accurately. - Update adapter docs or create adapter work items when assets are expected to upgrade between profile versions.
- When the new profile version differs from another source/target profile, identify every feature difference and whether a direct adapter path exists or is intentionally blocked.
- When validation tooling is available, run
workspace validateor the equivalentsimready-validatecommand against a representative asset. - Validate consistency:
- TOML parses
- old version still exists
- new version exists and contains exact feature versions
- profile markdown agrees with TOML
- profile index agrees with TOML
- all feature references resolve to JSON manifests
Versioning Rules
- Patch: non-contract metadata or documentation fix.
- Minor: backward-compatible added feature or feature-version bump.
- Major: removed feature, incompatible feature-version change, target runtime change, or changed required authored data.
When a profile adopts a new feature version created in the same change, include both the feature update and profile update in the final summary.
Examples
Example request:
Update prop-robotics-neutral to include a conditional optional feature note.
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
- Treat
profiles.tomlas source of truth. - Do not silently make a feature optional by changing prose only; machine-readable profile behavior must match.
- Do not update only markdown when validators consume TOML.
- Do not reference feature versions that do not exist.
- Keep old versions available for existing assets.
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 |
|---|---|
profile_name | Profile changed. |
base_version | Existing version used as source. |
new_version | Version added, or in-place editorial fix. |
features_added | Feature IDs/versions added. |
features_removed | Feature IDs removed. |
features_changed | Feature version changes. |
docs_changed | Markdown/index paths changed. |
adapter_plan | Migration/adapters required. |
validation | Checks run and remaining gaps. |