For skill publishers
If you publish agent skills on GitHub, your skill may already be listed on Skill Store 33. This page explains how skills get into the store, where each part of a listing comes from, and how to ask for a correction or removal.
How a skill gets into the store today
There is no submission form yet. The store imports skills from public GitHub repositories, mainly repositories listed on skills.sh, an index of public repositories that contain skills. The store reads the skills.sh sitemap to find repositories, then fetches each one from GitHub.
So the main way in today is to publish your skill in a public GitHub repository that skills.sh lists. The store also tracks a small number of vendor and community repositories directly.
Each SKILL.md in a repository becomes its own listing. The store skips a SKILL.md that is a symbolic link to another skill, one that is byte-for-byte identical to a skill already listed from another source, and one over 256 KB.
When the store re-imports your repository, changed SKILL.md files are updated and unchanged ones are left alone.
What your listing shows, and where it comes from
Name: the name field in your frontmatter, or the folder name if there is none. The display title is the name with hyphens turned into spaces.
Description: the description field in your frontmatter, up to 1,024 characters. Its first sentence becomes the one-line summary on result cards. If a description is empty or unusable, the store may write one from your skill's text and keep your original alongside it.
Publisher: the GitHub account or organisation that owns the repository.
Source: a link to your SKILL.md on GitHub at the commit the store imported.
Licence: your license frontmatter field. If that is missing, the store uses the nearest licence file, starting in the skill's folder and working up to the repository root.
Category and outcome class: assigned by the store from your name, description and skill text. Category or tags fields in your frontmatter are recorded but don't set the store category.
Verification state: every imported skill starts as "Not yet verified".
Size: an approximate token count, estimated from the SKILL.md's length.
SKILL.md download: offered only when your licence allows redistribution (MIT, Apache-2.0, BSD, ISC, MPL-2.0, CC-BY-4.0, CC0 or the Unlicense). Otherwise the listing links to your own copy instead. That includes skills with no licence, copyleft or non-commercial terms, and terms the store can't recognise.
How to make a good listing
Write a clear description. Search matches tasks against your skill's name and description, and agents read the description to decide whether to use your skill. Say what it does and when to use it. Name the tools, file types or products it handles, and keep the most important point in the first sentence.
Set the license field. A license field with a standard identifier such as MIT or Apache-2.0 is the clearest signal. Without a licence the store can't serve your skill's text, only link to it.
Keep each skill small and focused. One skill per job is easier to match to a task than one that covers everything. The Agent Skills specification recommends keeping SKILL.md under 500 lines and moving detail into reference files.
Include tests or worked examples. Concrete inputs and expected outputs make a skill easier to trust and check. The store's "Verified" state is reserved for skills whose own tests have run in a sandbox and passed.
Follow the specification. Use a name of lowercase letters, numbers and hyphens that matches the folder, and valid YAML frontmatter.
Corrections and removal
To have a listing corrected or your skill removed, email support@readyai.ai with the listing's URL. You don't need to file a formal notice. Copyright and licence notices follow the process in the Terms of Service.
SN33
SN33, a Bittensor subnet run by ReadyAI, is another source of skills. Miners on SN33 write skills with test plans. It has 13 skills in the store so far.