chore: sync skills (CUDA-Q,cuOpt,TensorRT-LLM,Model-Optimizer,Megatron-Bridge,Nemotron Voice Agent,NeMo Gym,NeMo Evaluator)

[github-actions]

Automated skills sync

Components synced:

• CUDA-Q
• cuOpt
• TensorRT-LLM
• Model-Optimizer
• Megatron-Bridge
• Nemotron Voice Agent
• NeMo Gym
• NeMo Evaluator

Components that failed to sync:

• Megatron-Core (NVIDIA/Megatron-LM): .claude/skills/ empty or missing

Triggered by: workflow_dispatch

[mosheabr]

Reviewed the sync output — looks good overall. 277 files across 7 product directories, all under skills/. No sensitive files, no binaries. Script and JSON files are all legitimate (deployment scripts, eval test cases).

One thing to check before merging: cuOpt and Nemotron Voice Agent are listed in the PR body as synced but don't appear in the file diff. Looks like the sparse checkout may have failed silently for those repos. Could be a PAT access issue or a path mismatch in components.yml. Can you verify?

Product	Files	Status
Megatron-Bridge	47	Synced
Model-Optimizer	26	Synced
NeMo-Evaluator-Launcher	12	Synced
TensorRT-LLM	11	Synced
NeMo-Gym	2	Synced
NeMo-Evaluator	1	Synced
CUDA-Q	1	Synced
cuOpt	0	Missing
Nemotron Voice Agent	0	Missing

Everything else LGTM — happy to approve once the missing products are resolved or confirmed as expected.

[mosheabr]

Review Comments

The workflow refactor to components.yml is a great improvement — teams can now onboard by adding a YAML entry instead of editing the workflow. A few items to flag before merging:

1. Internal URL — NeMo Evaluator Launcher

skills/NeMo-Evaluator-Launcher/launching-evals/ contains an internal GitLab container registry URL:

gitlab-master.nvidia.com/dl/joc/competitive_evaluation/nvidia-core-evals/ci-llm/long-context-eval:dev-...

If this repo goes public, this should be replaced with a placeholder or marked as internal-only.

2. Internal Infrastructure URLs — TensorRT-LLM

skills/TensorRT-LLM/exec-slurm-compile/ references internal infrastructure:

• urm.nvidia.com/sw-tensorrt-docker/... — internal URM registry
• authn.nvidia.com — NGC auth endpoint in netrc config

These are in slurm/compile skills which may be internal-use-only, but they'd leak internal infra details if the repo goes public.

3. Author Email — CUDA-Q

skills/CUDA-Q/cudaq-guide/SKILL.md includes spisal@nvidia.com in the metadata. Worth checking if employee emails should appear in public-facing files per policy.

4. Megatron-Core — No Skills Synced

components.yml lists Megatron-Core (from NVIDIA/Megatron-LM) but no skills appeared in this PR. The old ci.yml expected 3 skills. Either the source repo has no skills on main yet, or the checkout failed silently (the workflow uses continue-on-error). Worth verifying.

[sayalinvidia]

Great catches, @mosheabr! Thanks for the thorough review!

Addressing each:

1-3 (Internal URLs, email in CUDA-Q): These are valid concerns but they live in the source repos (NeMo Evaluator, TensorRT-LLM, CUDA-Q), not in this catalog. The sync workflow mirrors skills as-is from each product repo — we don't modify content during sync.
Should we flag these as issues on the respective source repos for the owning teams to fix?

4 (Megatron-Core): Confirmed — .claude/skills in NVIDIA/Megatron-LM is a symlink pointing to ../skills, not an actual directory. Sparse checkout pulls the symlink file instead of the directory contents, so the sync silently skips it. We have a fix in PR #24 that tracks and reports failed components — once merged, this will automatically create a GitHub issue when Megatron-Core fails to sync, making it visible instead of silent. The Megatron team will need to update their entry in components.yml to use the correct path.

[mosheabr]

LGTM — approving. The internal URL issues (items 1-3) live in the source repos, not this catalog. Let's file issues on the respective source repos for the owning teams to clean up:

• NeMo Evaluator: gitlab-master.nvidia.com container registry URL
• TensorRT-LLM: urm.nvidia.com and authn.nvidia.com references
• CUDA-Q: author email in SKILL.md metadata

Megatron-Core symlink issue is tracked via the failure reporting in PR #24 (now merged).