SimReady Add Capability

Purpose

Use this skill when a new requirement does not fit an existing capability. A capability groups related requirements and their validators under nvcore/srspecs/docs/capabilities/.

After creating the capability, use simready-foundation-add-requirement for each requirement and simready-foundation-add-validator for executable checks.

Prerequisites

Before editing, read:

• AGENTS.md
• nvcore/srspecs/docs/guides/guides.md
• nvcore/srspecs/docs/guides/naming_conventions.md
• nvcore/srspecs/docs/guides/featuresexpansionworkflow.md
• existing neighboring capability folders
• nvcore/srspecs/docs/capabilities/capabilities.md
• nvcore/srspecs/docs/capabilities/init.py

No network access, API key, or external service is required for the authoring pass.

Inputs

Collect or infer:

Instructions

Use this checklist when changing the repository:

1. Confirm no existing capability already covers the scope.
2. Choose names using the naming guide:

- group folder: snakecase - folder: snakecase - overview: capability-<folder_name>.md - requirement docs: kebab-case

1. Create the capability folder in the appropriate group; if the group is new, add the group landing page too.
2. Add capability-<slug>.md with purpose, scope, requirement table, related capabilities, and validation notes.
3. Add requirements.md with {requirements-table} and a toctree for requirement docs.
4. Add an empty or initial requirements/ folder content only for real requirements.
5. Add validation.py with imports and placeholder structure only when validators are planned; otherwise document deferred validation in the capability overview.
6. Update parent group toctrees, group landing pages, and global capability indexes, including capabilities.md when needed.
7. Update capabilities/init.py imports when a new validation module must be registered.
8. Validate consistency:

- folder and overview names match - requirements index builds conceptually - validator registration path is documented - no duplicate requirement prefix or capability slug exists

Examples

Example request:

Add a SimReady capability for factory connection points, with requirement index registration and a validation plan.

Expected result summary:

capability_path: nv_core/sr_specs/docs/capabilities/<group>/<capability_slug>
overview_doc: capability-<capability_slug>.md
requirements_index: requirements.md
validation_module: validation.py or deferred
next_step: add concrete requirements with simready-foundation-add-requirement

Policies

• Prefer adding requirements to an existing capability when the domain already exists.
• Do not create a capability as a thin wrapper for one feature unless the requirement family is truly distinct.
• Keep capability docs about requirement families, not profile workflows.
• Make validation status explicit; incomplete validators are acceptable only when called out.

Limitations

• Do not create new feature or profile versions from this skill; hand off to the relevant add/update feature or profile skill.
• Do not invent requirement IDs when the capability scope is still ambiguous; record the naming question instead.
• Do not add executable validators unless the objective checks and registration path are clear.

Troubleshooting

• Error: an existing capability already owns the scope. Solution: update that capability instead of creating a parallel one.
• Error: the validator registration path is unclear. Solution: document deferred validation in the overview and list the exact follow-up.
• Error: indexes and folder names disagree. Solution: re-check the naming guide, then align folder, overview, requirements index, and imports.

Resources

• assets/openai.yaml preserves optional UI metadata for clients that read skill display hints. It is not required for the authoring workflow.

Summary Format

Report: