SimReady Add Capability

Purpose

Use this skill when a new requirement does not fit an existing capability. A capability groups related requirements and validators under its owning package in nv_core/tiers/.

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
• nv_core/sr_specs/docs/guides/guides.md
• nv_core/sr_specs/docs/guides/naming_conventions.md
• nv_core/sr_specs/docs/guides/features_expansion_workflow.md
• existing neighboring capability folders
• nv_core/sr_specs/docs/shared/capabilities/capabilities.md
• the owning tier's 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: snake_case
   • folder: snake_case
   • overview: capability-<folder_name>.md
   • requirement docs: kebab-case
3. Create the capability folder in the appropriate group; if the group is new, add the group landing page too.
4. Add capability-<slug>.md with purpose, scope, requirement table, related capabilities, and validation notes.
5. Add requirements.md with {requirements-table} and a toctree for requirement docs.
6. Add an empty or initial requirements/ folder content only for real requirements.
7. Add validation.py with imports and placeholder structure only when validators are planned; otherwise document deferred validation in the capability overview.
8. Update parent group toctrees, group landing pages, and the shared global capability hub when needed.
9. Update the owning tier's capabilities/__init__.py when a new validation module must be registered. Keep the shared legacy aggregate import hub in sync until simready-foundation-core is retired.
10. 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/tiers/<owning-tier>/simready/foundation/<tier-module>/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: