How to publish an AI skill

You have a working AI skill and have chosen where to publish it. It might be an Agent Skills-compatible client, a repository, a marketplace, or a hosted service.

Now you need to turn the version that works in your setup into one that another person can find, understand, and use. That means matching the destination's requirements, checking exactly which files will be shared, previewing the real experience, and testing the live version after publication.

If you have not chosen a destination yet, compare an AI skill marketplace with your own page first. The steps below begin once that choice has been made.

1. Read what the destination accepts

Before moving any files, read the destination's publishing requirements.

An Agent Skills-compatible client may expect a directory containing a required SKILL.md. A marketplace may require listing fields, screenshots, a licence, and a downloadable package. A hosted service may accept the skill's public material while keeping its operating rules on the server. A repository may store the source without providing any usable buyer experience at all.

Write down the answers to these questions:

These answers are your checklist. They stop you from treating every platform as if it accepts the same folder and provides the same buyer experience.

2. Adapt the package without changing the method

Keep one working source for the skill. Compare it with the destination's requirements and change only what the published version needs.

The open Agent Skills specification defines a skill as a directory with a required SKILL.md. That file contains required name and description frontmatter followed by the instructions. Scripts, references, and assets are optional. A destination can add its own rules around that base format.

You may need to:

• rename the skill directory so it matches the required skill name;
• add the metadata the destination uses for discovery or display;
• replace local absolute paths with paths that work inside the package;
• declare system, network, or runtime requirements;
• move large references out of the main instruction file;
• add a public promise, example, version, and access explanation; and
• remove generated files, local notes, and credentials that do not belong.

Avoid changing the core instructions while you are adapting the package. A file format problem and a change to the method need different tests. If you do change the instructions, run the skill's examples again and treat it as a new version.

Saucekit's current flow accepts a public GitHub repository, a folder selected in the browser, or a ZIP within its upload limits. It converts those inputs into one internal package and checks that package against the hosted skill format.

3. Decide what becomes public

Before uploading, check what the destination will expose to buyers or visitors.

If you distribute the complete source package, assume the recipient can read the instructions inside it. If you want the method to remain private, do not put those rules in the public download and hope a label will hide them. Use a delivery model that keeps execution behind a boundary you control.

Separate the material into two lists.

Public or buyer-facing material may include:

• the result the skill produces;
• who it is for and when to use it;
• representative inputs and outputs;
• compatibility and access requirements;
• limits, version, support, and data-path facts.

Private operating material may include:

• the detailed rules and decision sequence;
• proprietary references or examples;
• internal evaluation cases;
• service credentials and private infrastructure details.

This choice must be reflected in the files and in the way the skill runs. Saucekit's current hosted format keeps supported private rules on the server while the public page and access instructions explain what the buyer can use. Other destinations expose different material.

4. Validate the version you plan to upload

Run the destination's available checks before uploading.

At minimum, check:

1. required files and metadata are present;
2. names, slugs, paths, and archive shape follow the contract;
3. referenced scripts and assets exist inside the package;
4. declared dependencies match the destination's environment;
5. no credentials, private notes, or accidental files are included;
6. one representative input still produces the expected result.

For a skill prepared for Saucekit's current repository intake, the local checks are:

node scripts/intake.mjs init ./my-skill
node scripts/intake.mjs lint ./my-skill

The linter checks Saucekit's current manifest, instructions, paths, size, encoding, and secret rules. It is not a universal Agent Skills validator. It only tells you whether the package meets Saucekit's current requirements.

Fix errors in the working source or in a repeatable publishing adapter. Avoid a separate folder whose history and purpose nobody can explain later.

5. Preview it as another person

A successful upload only proves that the files arrived. Preview the experience another person will actually receive.

The preview should render the same page, assets, access explanation, and package state intended for publication. Open it as a person who did not build the skill.

Check the visible promise first:

• Is the creator identifiable?
• Is the result clear before the setup details begin?
• Does a representative example survive the renderer?
• Are access, compatibility, limits, and current status visible?
• Does the call to action lead to the right next step?

Then use a clean browser or account. Complete the access or installation step and run one representative input. This is where you find problems that your own signed-in setup may hide.

Saucekit keeps validated drafts private so a creator can inspect the real skill page before publication. The live Check by Luke page shows the kind of surface being reviewed: creator, promise, example, access, and install direction in one place.

6. Publish one reviewed version

Publish the exact version you just tested.

Before pressing publish, record:

• the version or commit being released;
• the destination and public address;
• current compatibility and known limits;
• who owns support and rollback;
• the previous live version, if one exists.

If the destination rebuilds or changes the package after approval, preview the final result too.

Saucekit's current creator flow lets the creator select one validated draft and publish it in one operation. The version being edited does not become visible piece by piece while its files are changing.

Keep the working source separate from the live state. Publication copies or promotes a reviewed version; it should not make the public platform the only place where the skill can be maintained.

7. Test the live skill

After publishing, test the version that is actually live.

Open the public address from outside your signed-in creator session. Confirm that the page is available, the shown version is correct, and private material is not exposed. Complete the access action. Follow the installation or use instructions. Run one normal input. Trigger one obvious error. Check where a person would ask for help.

Classify what you find:

• Usable: the intended person can find, access, and run the reviewed skill.
• Present but blocked: the page exists, but access or first use fails.
• Wrong version: the route works, but the published artifact is not the one approved.
• Unsafe: private material, credentials, or unsupported claims are visible.

Only the first state is a successful publication. If the skill is usable, you can now share it with a first real user. Distribution, sales, and the wider business are the next decisions; they do not need to be solved during the publishing step.