# Release Publishing

> Use when preparing, testing, tagging, or publishing beta and stable releases of the Meteor agent-skills plugin for Codex and Claude Code.

- Skill: `meteor/release-publishing` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add meteor/release-publishing`
- Raw SKILL.md: https://api.skillmd.com/api/skills/meteor/release-publishing/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: meteor (https://skillmd.com/u/meteor)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/meteor/release-publishing

---


# Publish Meteor agent skills

Prepare one catalog version for Codex, Claude Code, GitHub release assets, and
direct skill installation. Read [`RELEASING.md`](../../../RELEASING.md) before
changing release state.

## Choose the release stage

| Stage | Repository visibility | Version and tag | Purpose |
|---|---|---|---|
| Working-tree test | Private or public | No new tag required | Validate local manifests and behavior. |
| Public beta | Public | `X.Y.Z-beta.N` and `vX.Y.Z-beta.N` | Test the exact remote installation path. |
| Stable | Public | `X.Y.Z` and `vX.Y.Z` | Publish the accepted catalog and submit it to directories. |

A GitHub repository does not need to be public for local working-tree tests.
It must be public before testing installation through
`meteor/agent-skills@<tag>` or submitting to public directories.

Catalog releases may be published independently for skill additions, corrections,
evaluation improvements, packaging changes, or other catalog maintenance. For an
independent release, follow the normal beta or stable flow without requiring a Meteor
release audit, compatibility mapping, or Meteor artifact gates. Apply the coordinated
rules below only when the catalog is intentionally paired with a Meteor release.

## Coordinate with a Meteor release

When Meteor's release process requests a paired catalog, record the Meteor version,
release commit, Agent Skills audit report, audited Agent Skills revision, publish
commit, and exact catalog tag. Catalog semver is independent from Meteor semver. Do
not derive one version from the other.

| Meteor stage | Agent Skills stage |
|---|---|
| Beta | Public beta, `X.Y.Z-beta.N` |
| RC | Public beta, `X.Y.Z-beta.N` |
| Official | Stable, `X.Y.Z` |

The documented catalog stages are public beta and stable, so a Meteor RC remains paired
with an Agent Skills beta unless the repository adopts a separate RC policy.

Before preparing the catalog version:

1. Require a completed release audit against the final Meteor release commit and a
   clean Agent Skills candidate revision resolved from the freshly fetched default
   branch. If an earlier audit used uncommitted documentation or a different Agent
   Skills revision, require a new incremental report and preserve the earlier committed
   record.
2. Confirm every authorized release-blocking finding is implemented and its affected
   manual cases pass.
3. Confirm the maintenance branch is merged and CI is green on the candidate commit.
4. Select the catalog version explicitly. A user may approve a new beta snapshot with
   no distributable skill change when the purpose is to record tested compatibility
   with a Meteor candidate.

Load this publishing skill from the same clean checkout and revision selected for the
release candidate. Record that commit as `AGENT_SKILLS_CANDIDATE_SHA`. If the remote
default branch advances before version preparation, report the drift and explicitly
choose whether to keep the reviewed candidate or update it. Updating requires a new
audit of every affected catalog claim and another validation pass.

Publish the Agent Skills tag only after the paired Meteor packages, tool builds, and
bootstrap tarballs are live. A stable catalog must be based on a tagged beta that
passed local checks, remote installation tests, and affected behavioral cases. If its
guidance changed afterward, publish and test another beta before stable promotion.

After publication, record the exact Meteor-to-catalog mapping and live GitHub release
URL in the release handoff. Request Meteor's dedicated Agent Skills changelog section
only when this is a newly published paired tag and its remote installation tests pass;
otherwise the section must be omitted, not filled with `N/A`. Independent catalog
releases never create that Meteor changelog section.

Keep the Meteor changelog handoff concise and client-neutral. For a Meteor beta or RC,
record the exact tested `vX.Y.Z-beta.N` release link and promote the generic
`npx skills@latest add 'meteor/agent-skills#vX.Y.Z-beta.N'` installer. For an official
Meteor release, use the same shape with the verified stable tag in both the link and
command. Test the displayed npm command remotely and verify its installed files match
the tag. Keep client-specific commands in this catalog's release notes. Link the
changelog section to the official
[Meteor Agent Skills guide](https://docs.meteor.com/ai/agent-skills) for further
installation options.

On a repeated `skills add`, selected existing skill directories are replaced and their
`skills-lock.json` refs are updated; unselected installed skills remain in place.

## Prepare the version

Inspect the worktree first and preserve unrelated changes. Set the same global
version in both plugin manifests with:

```bash
pnpm release:bump 1.0.0-beta.1
```

Use a stable version only after its beta has passed local and tagged remote
installation tests:

```bash
pnpm release:bump 1.0.0
```

Do not add versions to `package.json` or individual `SKILL.md` files. The
repository tag identifies the complete catalog snapshot.

## Verify

Run the checks in `RELEASING.md`. The tag workflow automatically rejects a tag
that does not match both manifests.

Test from the working tree before making the repository public. After pushing a
beta tag, repeat the Codex, Claude Code, and individual-skill installations
from that exact tag.

## Publish

Treat preparation and publication as separate operations.

- A request to prepare a release authorizes local version changes and checks.
- A request to publish a release authorizes the requested commit, tag, push,
  and GitHub release flow.
- Marketplace submissions require the publisher account, approved listing
  details, and explicit authorization for that submission.

When publication is authorized, commit the verified release preparation and resolve
that commit as `AGENT_SKILLS_PUBLISH_SHA`. Show the diff from
`$AGENT_SKILLS_CANDIDATE_SHA` and require it to contain only the approved maintenance
and deterministic release preparation. Run the release checks from that clean exact
commit, tag that commit with the matching `v` prefix, and push the tag. Do not load the
publishing skill from one revision and tag another.

The GitHub workflow validates the version again, builds skill ZIPs, and creates the
GitHub release. Beta tags are marked as prereleases. Confirm the release succeeds
before testing remote installation.

Do not reuse or move a published tag. Prepare a new beta number or patch
version when a tagged release needs a correction.