Build a skills repository

The marketplace discovers skills by scanning a public GitHub repository: every directory that holds a SKILL.md becomes one skill. The repository is also where published skills install from, so its shape matters.

Layout

acme-skills/                 <- public GitHub repository
├── README.md
├── LICENSE
├── acme-education-issuer/   <- one directory = one skill
│   ├── SKILL.md
│   ├── openapi/issuer.yaml
│   ├── schemas/learner-credential.json
│   └── rulebooks/issuance.md
└── acme-education-verifier/
    ├── SKILL.md
    ├── openapi/verifier.yaml
    └── rulebooks/verification.md

• One directory per skill, each with its own SKILL.md and its own reference files. Nested locations work too - discovery walks the whole tree.
• A LICENSE file at the root. The repository licence is shown as provenance in the catalog and checked by reviewers.
• A README for humans. The marketplace reads the skills; visitors who land on GitHub read the README.

Releases and tags

Tag the repository when you want a named, stable submission point (for example 2026.08.0). Submitting a tag pins the skills to that exact state; submitting a branch pins them to the branch’s head commit at that moment. Either way, later pushes never change what was reviewed. See Source repositories.

One repository or many

Both work. A single repository holding your whole catalogue is easiest to maintain and submit; separate repositories make sense when skills have different release cadences or owners. When submitting, you can also select only a subset of the skill directories a repository contains.

Keep it public

The repository must stay public: the marketplace fetches it for verification, the catalog deep-links into it, and the skills CLI installs from it. A repository that disappears breaks installation for everyone who uses your skills.