#562·skills

Group catalog skills by product to support product-scoped installation

Author: chesterxgchenCreated Sep 14, 2026Updated Sep 17, 2026
Labelsenhancement

Problem Statement

The NVIDIA skills catalog currently stores skill directories in a flat skills/ layout:

  skills/
  ├── nvflare-autofl/
  ├── nvflare-autofl-report/
  ├── nvflare-convert-huggingface/
  ├── nvflare-fed-stats/
  ├── cuopt-install/
  ├── cuopt-developer/
  └── ...

Product membership is encoded implicitly through naming prefixes such as nvflare-, cuopt-, and nemo-.

This makes it difficult to install every skill belonging to one product. The skills CLI accepts exact skill names, but prefix patterns are not supported:

  npx skills add nvidia/skills \
    --skill 'nvflare-*' \
    -a codex \
    -a claude-code \
    -y

Current result:

No matching skills found for: nvflare-*

Installing the group therefore requires listing every skill individually. This is verbose, easy to get out of date as the catalog changes, and makes it easy to omit product- level shared skills such as nvflare-shared.

Wildcard matching has also been requested in the upstream CLI, but relying on name prefixes would continue to make product membership an implicit naming convention rather than part of the catalog structure: vercel-labs/skills#438.

Proposed Design

Organize catalog skills under stable product directories:

  skills/
  ├── nvflare/
  │   ├── nvflare-autofl/
  │   ├── nvflare-autofl-report/
  │   ├── nvflare-convert-huggingface/
  │   ├── nvflare-convert-lightning/
  │   ├── nvflare-convert-pytorch/
  │   ├── nvflare-diagnose-job/
  │   ├── nvflare-fed-stats/
  │   ├── nvflare-orient/
  │   └── nvflare-shared/
  ├── cuopt/
  │   ├── cuopt-install/
  │   ├── cuopt-developer/
  │   └── ...
  └── ...

The product directory would become an installation scope. Because the CLI supports GitHub repository subpaths, users could install all NVFlare skills with:

  npx skills add nvidia/skills/skills/nvflare \
    --skill '*' \
    -a codex \
    -a claude-code \
    -y

The equivalent full URL would be:

  npx skills add \
    https://github.com/NVIDIA/skills/tree/main/skills/nvflare \
    --skill '*' \
    -a codex \
    -a claude-code \
    -y

Individual installation would remain unchanged because skill names and leaf-directory names would not change:

  npx skills add nvidia/skills \
    --skill nvflare-fed-stats \
    -a codex \
    -a claude-code \
    -y

The catalog synchronization workflow should preserve or assign a stable product identifier when mirroring skills from their source repositories. It should not derive product membership solely from the skill-name prefix.

Product-scoped installation would include shared skills located within that product directory. Automatic dependency installation for an individually selected skill could remain a separate enhancement; this proposal ensures that complete product installation includes those shared components.

Acceptance criteria:

  • Skills are organized beneath stable product directories.
  • Exact-name installation from the catalog root continues to work.
  • Installing from a product subpath discovers only that product’s skills.
  • --skill '*' from a product subpath installs the complete product group, including shared skills.
  • The catalog sync workflow preserves product grouping.
  • Documentation covers product-scoped installation and migration implications for existing lock files.

Alternatives Considered

  1. Add prefix-glob support to the skills CLI.

    This would make --skill 'nvflare-*' possible, but it requires an upstream CLI change and continues to treat naming conventions as catalog metadata.

  2. List every skill using repeated --skill arguments.

    This works today but is verbose and becomes stale whenever skills are added, renamed, or removed.

  3. Install directly from each product’s source repository.

    This works for repositories such as NVIDIA/NVFlare, but it bypasses the unified NVIDIA catalog and assumes every product has a separately installable source repository with a compatible layout.

  4. Introduce product-pack manifests.

    A manifest could express membership and dependencies more explicitly, but it would require additional format and tooling support. Directory-based grouping provides useful product-scoped installation with the CLI’s existing subpath behavior.

Category

enhancement: catalog / sync workflow

Checklist

  • I searched existing issues and this is not a duplicate
  • This is a design proposal, not a "please build this" request