Release the SDK
Read the SDK release guide and the root
AGENTS.md. Follow the guide for commands, npm setup, validation, tagging, and
recovery; inspect the current workflow and package metadata before executing it.
Scope
- “Bump” or “prepare a release” authorizes preparation, validation, and a release
PR as appropriate; it does not by itself authorize publishing to npm.
- “Release/publish a new patch” authorizes the full process, including the release
PR, merging once required checks/reviews permit it, and pushing the release tag.
Honor existing session authorization without asking for it again. If release
authorization is missing, finish the reviewable preparation before asking.
- Creating or editing this skill or its documentation does not authorize a release.
Execution
- Inspect the worktree, current branch,
origin/main, npm versions, release tags,
and any existing release PR/run. Preserve unrelated changes. Determine the
next stable patch from current state; resume an already prepared bump instead
of bumping twice. If versions disagree or the base is a prerelease, resolve
that before selecting a target.
- Check the guide's npm prerequisites. Make the version change, run its SDK
validation and package inspection, and prepare a PR with the old/new version
and results. Do not hide failed checks or bypass repository review rules.
- For an authorized publication, merge after required checks/reviews pass and
pin the actual merged commit. Verify its version, workflow, and ancestry on
freshly fetched
origin/main; check npm and remote tags again for collisions.
- Push only the matching
sdk-vX.Y.Z tag. Watch the exact tag/commit's Publish SDK
run, then verify that version and the npm dist-tag. A version bump, a pushed
tag, or a green validation job alone is not proof of publication.
- Follow the guide's bounded recovery steps for failures. Never move an existing
release tag or retry publishing an already published version. If access,
required reviews, or npm setup block progress, report the completed preparation
and precise remaining action.
Return the old/new version, PR and release commit, tag, Actions run URL, and npm
verification. Clearly distinguish prepared, awaiting merge, publishing, failed,
and published states; include only artifacts that actually exist.
1---2name: release-sdk3description: Prepare or publish a patch release of @macro-inc/sdk in this repository. Use when asked to bump the SDK patch version or release it to npm.4---56# Release the SDK78Read [the SDK release guide](../../../packages/sdk/RELEASING.md) and the root9`AGENTS.md`. Follow the guide for commands, npm setup, validation, tagging, and10recovery; inspect the current workflow and package metadata before executing it.1112## Scope1314- “Bump” or “prepare a release” authorizes preparation, validation, and a release15 PR as appropriate; it does not by itself authorize publishing to npm.16- “Release/publish a new patch” authorizes the full process, including the release17 PR, merging once required checks/reviews permit it, and pushing the release tag.18 Honor existing session authorization without asking for it again. If release19 authorization is missing, finish the reviewable preparation before asking.20- Creating or editing this skill or its documentation does not authorize a release.2122## Execution23241. Inspect the worktree, current branch, `origin/main`, npm versions, release tags,25 and any existing release PR/run. Preserve unrelated changes. Determine the26 next stable patch from current state; resume an already prepared bump instead27 of bumping twice. If versions disagree or the base is a prerelease, resolve28 that before selecting a target.292. Check the guide's npm prerequisites. Make the version change, run its SDK30 validation and package inspection, and prepare a PR with the old/new version31 and results. Do not hide failed checks or bypass repository review rules.323. For an authorized publication, merge after required checks/reviews pass and33 pin the actual merged commit. Verify its version, workflow, and ancestry on34 freshly fetched `origin/main`; check npm and remote tags again for collisions.354. Push only the matching `sdk-vX.Y.Z` tag. Watch the exact tag/commit's Publish SDK36 run, then verify that version and the npm dist-tag. A version bump, a pushed37 tag, or a green validation job alone is not proof of publication.385. Follow the guide's bounded recovery steps for failures. Never move an existing39 release tag or retry publishing an already published version. If access,40 required reviews, or npm setup block progress, report the completed preparation41 and precise remaining action.4243Return the old/new version, PR and release commit, tag, Actions run URL, and npm44verification. Clearly distinguish prepared, awaiting merge, publishing, failed,45and published states; include only artifacts that actually exist.