Add nvidia-skill-finder as catalog-only router skill

[jasonnvidia]

Summary

• Adds skills/nvidia-skill-finder/ directly to the catalog as a router/discovery skill (no components.d upstream)
• Registers the directory in catalog-exceptions.yml so the current orphan-pruning sync logic preserves this catalog-only skill
• Updates benchmarks.json from the staged BENCHMARK.md

This follows Moshe's guidance that the skill belongs in the catalog itself rather than as a synced component. Because newer sync logic prunes unregistered skills/ directories, this PR explicitly adds nvidia-skill-finder to catalog-exceptions.yml. Future updates are direct PRs here plus a fresh /nvskills-ci run.

Replaces fork PR #339 because /nvskills-ci does not support fork pull requests; the signing service needs to push the signature commit back to a branch inside NVIDIA/skills.

Sync and signing notes

• No components.d entry is added, so normal rsync sync will not overwrite this skill.
• catalog-exceptions.yml protects it from orphan pruning.
• The exception does not bypass compliance: the skill still needs skill.oms.sig, skill-card.md, and eval data.
• /nvskills-ci should generate the signature commit and refresh generated artifacts. Before merge, verify that commit landed and that no unsigned content commit came after it.
• benchmarks.json is regenerated from BENCHMARK.md. If /nvskills-ci rewrites BENCHMARK.md, re-run aggregate_benchmarks.py so benchmarks.json still matches and the metadata check stays green.

Follow-up

• Once all /nvskills-ci checks pass and this merges, we will create a separate PR to include nvidia-skill-finder in the plugin bundle.

Post-merge checklist

1. Comment /nvskills-ci on this PR (maintainer/admin) to generate skill.oms.sig, refresh skill-card.md, and regenerate BENCHMARK.md
2. Verify the bot's signature commit lands on the PR branch
3. Confirm no unsigned commits land after the signature commit
4. Merge once CI is green and signatures are in place

Test plan

• /nvskills-ci completes and pushes signature commit
• skill.oms.sig, skill-card.md, and evals/evals.json present after CI
• benchmarks.json re-verified against the post-/nvskills-ci BENCHMARK.md
• Content integrity check passes after signature commit
• npx skills add nvidia/skills --skill nvidia-skill-finder --list shows the skill after merge

[jasonnvidia]

/nvskills-ci

[mosheabr]

Reviewed — the skill and the wiring are in great shape; the blocker is upstream of this PR.

What's right: SKILL.md is a well-scoped router (rich positive triggers, explicit negative triggers, live-catalog-as-source-of-truth so it won't rot), full artifact set (evals, skill card, benchmark), catalog-exceptions.yml entry is textbook (dir/reason/owner/component — the pruner will preserve it and the dashboard groups it), and the committed benchmarks.json regen passes the drift gate. Also the right call replacing the fork PR — in-repo branch is what the signing service needs.

Blocker: the signing run needs to complete before merge — per catalog rules, no merge until skill.oms.sig and the refreshed skill card land.

One naming note, non-blocking: component: NVIDIA Skills creates a new product grouping on the adoption dashboard — intentional for catalog-infrastructure skills? Fine either way, just confirming it's deliberate.

Once the signing run goes green here, I'm ready to approve same-day.

[jasonnvidia]

/nvskills-ci

[jasonnvidia]

/nvskills-ci

[jasonnvidia]

/nvskills-ci

[jasonnvidia]

cc @mosheabr — heads-up on the changes here

Context

gate:content blocked the first /nvskills-ci run with two HIGH findings (tier1 + tier2). Everything else (tier1/2/3, skillcritic, unit tests) passed. Fixes below; a fresh /nvskills-ci is running against the latest commit.

Findings and fixes

1. DUPLICATE (tier2, HIGH, conf 0.88) — SKILL.md "When Not to Use this Skill" overlapped references/taxonomy-routing.md "False-Positive Checks".

• Fix: kept SKILL.md as the authoritative copy (it always loads) and replaced the reference section with a pointer to it. No content lost.

2. SECURITY (tier1, HIGH, conf 0.72) — SkillSpector flagged agents/openai.yaml allow_implicit_invocation: true as "without activation constraints," i.e. an elevation-of-privilege risk for a skill that finds/installs other skills.

• We kept implicit invocation (it's the whole point of a router/detector skill) and kept openai.yaml minimal/standard rather than adding non-standard policy keys.
• Instead we documented the scope in SKILL.md under a new "Implicit Invocation Constraints" section: activation is scoped to NVIDIA relevance, and installing/modifying skills requires explicit user approval (recommendation is always allowed; install is not).
• We were careful not to narrow trigger breadth — the wording preserves the original "plausibly related to an NVIDIA product area / taxonomy lane" bar and the softer "how do I do X" triggers, so this does not introduce underfiring.