nvidia/simready-foundation · Archived

simready-foundation-add-profile

Use for adding SimReady profile versions with feature bundles, docs, indexes, and validation notes.

First seen Jul 3, 2026

Installation

$ npx skills add nvidia/simready-foundation --skill simready-foundation-add-profile

Stronger alternatives

This repository is archived — consider an actively maintained alternative.

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from nvidia/simready-foundation · top by installs.

npx skills add nvidia/simready-foundation

Browse all from nvidia/simready-foundation

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 72
License LICENSE.txt
Default branch main
Open issues 22
Status Archived

Skill metadata

Parsed from SKILL.md frontmatter.

LicenseApache-2.0
More metadata
author
Shaad Boochoon <[email protected]>
tags
["simready","profile","specification"]

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 5,744 B
  • docs SUMMARY.md 138 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 2 installs

SKILL.md

SimReady Add Profile

Purpose

Use this skill to add a brand-new profile under nvcore/srspecs/docs/profiles/. A profile is a named, versioned bundle of exact feature IDs and versions for a target asset class or runtime.

Do not use this skill for a new version of an existing profile. Use simready-foundation-update-profile for that.

Prerequisites

Before editing, read:

  • AGENTS.md
  • nvcore/srspecs/docs/guides/guides.md
  • nvcore/srspecs/docs/guides/profiles/profiles.md
  • nvcore/srspecs/docs/guides/featureadapters/featureadapters.md
  • nvcore/srspecs/docs/profiles/ (per-profile TOML files, one per profile)
  • nvcore/srspecs/docs/profiles/profiles.md
  • nearby profile markdown files for the same asset class or runtime
  • nvcore/srspecs/docs/features/feature-dependency-graph.md

Inputs

Collect or infer:

Input Requirement
profile_name New profile name, such as Prop-Robotics-Neutral. Use title-case words separated by hyphens.
profile_version Initial version, usually 1.0.0 unless the user states otherwise.
targetassetclass Prop, robot body, scene, material library, or another concrete class.
target_runtime Neutral OpenUSD, PhysX, Isaac, or another runtime target.
feature_bundle Exact feature IDs and versions.
profilemarkdownname Markdown file path under docs/profiles/.
adapter_plan Required adapters from related profiles, or none.
validation_strategy Example assets, validator command, runtime test, or documented gap.

Instructions

Use this checklist when changing the repository:

  1. Confirm the profile name is new across the per-profile TOML files in profiles/.
  2. Choose a feature bundle from exact existing feature JSON manifests. Do not reference a feature version that does not exist.
  3. Check feature dependencies. Avoid duplicating dependencies unless existing profiles do so intentionally for clarity.
  4. Create a new per-profile TOML file under profiles/ (e.g. profiles/<profile_name>.toml) containing a [Profile-Name] table with the initial version and ordered feature list.
  5. Create a profile markdown page under nvcore/srspecs/docs/profiles/:

- purpose and target asset class - target runtime/environment - exact feature list and versions - authoring requirements and known conditional features - validation and runtime-test guidance - references to feature docs and related profiles

  1. Update nvcore/srspecs/docs/profiles/profiles.md with the new profile row and toctree entry if the index uses one.
  2. Add feature adapter notes when this profile is expected to be an upgrade or conversion target from another profile.
  3. When the new profile differs from an existing related profile, identify every feature difference and whether a direct adapter path exists or is intentionally blocked.
  4. When validation tooling is available, run workspace validate or the equivalent simready-validate command against a representative asset.
  5. Validate consistency:

- TOML parses - every referenced feature ID/version exists in docs/features/*.json - profile markdown and the profile's TOML feature lists agree - profiles.md includes the new profile

Examples

Example request:

Create a new prop-factory-neutral SimReady profile similar to prop-robotics-neutral.

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

  • The per-profile TOML files in profiles/ are the machine-readable source of truth.
  • Keep the initial feature bundle focused. Do not add features that are merely nice to have.
  • A feature may be conditionally applicable only when the profile docs and validator behavior make that condition clear.
  • If new features are needed, create them with simready-foundation-add-feature before referencing them.
  • If the new profile supersedes or branches from another profile, document migration/adapters instead of rewriting the old profile.

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:

Field Meaning
profile_name New profile.
profile_version Initial version.
profiles_toml TOML path changed.
profile_markdown Profile docs path.
features Exact feature IDs and versions.
adapters Adapter plan or none.
validation Checks run and remaining gaps.
next_step Feature creation, adapter work, runtime test, or review.