|
| 1 | +# Federate Your Repo Into the Catalog |
| 2 | + |
| 3 | +How to list skills that live in **your own AMD repo** in this catalog. Your repo |
| 4 | +stays the source of truth; the catalog vendors a pinned copy. |
| 5 | + |
| 6 | +This is the detailed version of **Path B** in |
| 7 | +[CONTRIBUTING.md](../CONTRIBUTING.md#path-b-skills-authored-in-a-product-repository-federation). |
| 8 | +Start there for an overview of how it compares to authoring skills directly in |
| 9 | +this repo. |
| 10 | + |
| 11 | +> **Eligibility: AMD-owned repositories only.** The source `repo` must be under |
| 12 | +> an AMD GitHub org (e.g. `AMD-AGI/...`). Non-AMD repos are not accepted. |
| 13 | +
|
| 14 | +## Prerequisites |
| 15 | + |
| 16 | +- Each skill is a folder with a valid `SKILL.md` and `skill-card.md`. |
| 17 | + See [CONTRIBUTING.md](../CONTRIBUTING.md) and [skill-cards.md](skill-cards.md). |
| 18 | +- Skills live in a known directory in your repo (e.g. `skills/`). |
| 19 | +- Pick a branch to track (e.g. `main` or a release branch). |
| 20 | + |
| 21 | +## Add your source |
| 22 | + |
| 23 | +Edit [`.github/scripts/sources.yml`](../.github/scripts/sources.yml) and append an entry: |
| 24 | + |
| 25 | +```yaml |
| 26 | +sources: |
| 27 | + - name: amd-myproject # kebab-case source id |
| 28 | + repo: AMD-Org/MyProject # must be AMD-owned |
| 29 | + ref: main # branch to track (e.g. main or a release branch) |
| 30 | + path: skills # dir in your repo holding the skill folders |
| 31 | + license: MIT # SPDX id, carried into the marker file |
| 32 | + skills: |
| 33 | + - name: my-skill # folder name in your repo |
| 34 | + as: myproject-my-skill # local catalog name: <project>-<skill> |
| 35 | +``` |
| 36 | +
|
| 37 | +Use `as:` to namespace skills as `<project>-<skill>` so catalog names stay unique. |
| 38 | + |
| 39 | +## Import |
| 40 | + |
| 41 | +Run the import scripts locally (they read `sources.yml` from your working tree), |
| 42 | +then open a PR for review. |
| 43 | + |
| 44 | +1. Vendor the skills and refresh the manifests: |
| 45 | + |
| 46 | + ```bash |
| 47 | + uv run .github/scripts/import_external_skills.py # vendor into skills/<name>/ |
| 48 | + uv run .github/scripts/generate_cursor_marketplace.py |
| 49 | + ./.github/scripts/check.sh # validate |
| 50 | + ``` |
| 51 | + |
| 52 | +2. Commit `skills/**`, `.github/scripts/sources.yml`, and the manifests. |
| 53 | +3. Open a PR; a maintainer reviews and merges once CI passes. |
| 54 | + |
| 55 | +## Catch failures before nightly |
| 56 | + |
| 57 | +The catalog runs checks against your skills. Run the **same** checks in your own |
| 58 | +repo by calling them as reusable workflows, so you catch breakage during normal |
| 59 | +development instead of in the catalog's nightly run. The logic and config live in |
| 60 | +`amd/skills`, so green in your repo means green in the catalog — and you never copy |
| 61 | +or maintain the check yourself. |
| 62 | + |
| 63 | +Add a caller workflow to your repo (e.g. `.github/workflows/skills-checks.yml`): |
| 64 | + |
| 65 | +```yaml |
| 66 | +name: skills-checks |
| 67 | +on: |
| 68 | + pull_request: |
| 69 | + workflow_dispatch: |
| 70 | +jobs: |
| 71 | + external-references: |
| 72 | + uses: amd/skills/.github/workflows/external-reference-check.yml@main |
| 73 | + permissions: |
| 74 | + contents: read |
| 75 | + issues: write |
| 76 | +``` |
| 77 | + |
| 78 | +## Update or remove |
| 79 | + |
| 80 | +Automatic refresh and pruning will soon be enabled through nightly workflows. |
| 81 | + |
| 82 | +Never hand-edit vendored skills under `skills/`; changes must come from your repo |
| 83 | +via re-import, or they'll be overwritten. |
0 commit comments