New Skill: amd-skill-finder

[andyluo7]

What changed

• adds amd-skill-finder as a native cross-cutting AMD catalog skill
• searches installed skills and the published AMD catalog before routing to source repositories
• adds a curated registry covering official AMD/ROCm projects and reviewed ecosystem projects
• keeps general GitHub discovery opt-in and distinguishes installable skills from source material
• publishes the new skill through the Claude, Codex, Cursor, and agents manifests

Why

AMD's catalog needs a stable capability detector similar to NVIDIA's skill finder,
while also covering AMD-specific knowledge that currently lives in ROCm and selected
upstream repositories rather than packaged skills.

The finder uses this trust order:

1. installed skills
2. published amd/skills catalog entries
3. official AMD, ROCm, and AMD-AGI repositories
4. reviewed upstream repositories
5. unreviewed GitHub fallback only when explicitly enabled

Repositories remain non-installable source results unless they are published as
validated AMD catalog skills. PyTorch, JAX, and Triton AMD forks are grouped with
their upstream repositories instead of producing duplicate recommendations.

The registry includes MORI, Hyperloom, PyTorch, JAX, Triton, TorchTitan, LMCache,
Mooncake, TileLang, NIXL, Miles, VERL, VIME, vLLM, SGLang, AITER, ATOM, and related
ROCm sources. ai-dynamo/dynamo is explicitly excluded; the separately requested
ai-dynamo/nixl source remains included.

Validation

• UV_SYSTEM_CERTS=true bash .github/scripts/check.sh
• python3 -m unittest skills/amd-skill-finder/tests/test_find_skills.py (15 tests)
• uvx --system-certs ruff check skills/amd-skill-finder
• uvx --system-certs ruff format --check ... for finder Python
• git diff --check origin/main...HEAD

Behavioral agent eval definitions are included under skills/amd-skill-finder/evals/.
Fork PR jobs cannot access AMD's ORCHESTR_API_KEY; an AMD maintainer can rerun the
required behavioral gate from a trusted context.

This PR now contains only amd-skill-finder. The Quark skill family is submitted
independently in #122, as requested in the review discussion.

[danielholanda]

@andyluo7 Can you please split this into two PRs? One for amd-skill-finder and another one for quark-*?

[amd-zhaofeng]

This is a useful skill — it turns "look for an existing skill first" into an explicit path. We are on the AMD Quark team and have been reading the finder end to end while working out how Quark's own skills should join the catalog. From that angle there is one thing we would like to raise, only so that the quantization path actually gets walked:

Neither the description nor amd_signals carries any quantization vocabulary. The frontmatter trigger list names vLLM, SGLang, AITER, MORI, TileLang and a dozen other projects, but never Quark, quantization, or any precision format; amd_signals likewise has no quark, so a Quark-only question misses the +8 that score_project gives AMD-official sources. The Quark entry in data/sources.json is already thorough, but it is hard to reach on exactly those queries. Suggest adding Quark and the quantization vocabulary to both the description and amd_signals, plus a deterministic routing test as the policy document itself requires — Quark is currently absent from the 13 projects asserted in test_requested_projects_and_canonical_repositories_are_present.