| name | release-workflow |
| description | Use when releasing or publishing @bjorntech/alchemy-azure; covers version bumps, changelog promotion, compatibility docs, gates, GitHub trusted publishing, GitHub Releases, and npm verification. |
| license | MIT |
| compatibility | opencode |
| metadata | {"domain":"release","repo":"alchemy-azure"} |
Release Workflow
Use this skill when the user asks to release or publish this package.
Versioning
- Keep the Alchemy beta suffix aligned with the pinned dependency line, for example
0.1.0-beta.57 with alchemy@2.0.0-beta.57.
- For new resources or meaningful user-facing behavior, prefer a minor beta bump.
- For fixes only, prefer a patch beta bump.
- Do not bump
alchemy, effect, or package version independently. If dependency pins change, update package.json, README.md compatibility table, and CHANGELOG.md together.
Release Metadata
- Promote
CHANGELOG.md Unreleased notes into ## [x.y.z-beta.N] - YYYY-MM-DD.
- Keep an empty
## [Unreleased] heading at the top.
- Add the new package version to the top of the
README.md compatibility table.
- Update
package.json version.
- Do not edit
bun.lock for a package-only version bump unless Bun changes it through a required install/update operation.
Pre-Publish Checks
- Confirm the target version is not already published:
npm view "@bjorntech/alchemy-azure@<version>" version.
- Run all gates in order:
bun run check, bun test, bun run coverage:check.
- Run
git diff --check.
- Inspect
git status --short and git diff before committing.
Commit And Publish
- Commit release metadata as
chore: release <version>.
- Prefer PR flow for release commits unless the user explicitly asks for direct release or has already approved direct push.
- Merge the release commit to
main before publishing. The trusted-publishing workflow should normally run from main.
- If pushing directly to
main, note any branch-rule bypass reported by GitHub.
- Publish through GitHub trusted publishing using
gh workflow run release.yml --ref main.
- Watch the workflow with
gh run watch <run-id> --exit-status.
- Ensure npm dist-tags are updated after publish: every release should point
latest at the released version, and beta/prerelease versions should also point next at the released version.
GitHub Release
- After npm publish is verified, create a GitHub Release tagged
v<version> from the release commit.
- Use the promoted changelog entry as the release notes.
- Mark beta/prerelease versions with
--prerelease.
- Verify the release exists with
gh release view "v<version>".
Verification
- Verify npm after workflow success:
npm view "@bjorntech/alchemy-azure@<version>" version dist-tags.
- Confirm npm dist-tags point to the released version:
latest for every release, plus next for beta/prerelease versions.
- Verify GitHub Release metadata: tag
v<version>, target release commit, and prerelease state for beta versions.
- Confirm final local state with
git status --short --branch.
Final Report
- Report the released version, release commit, workflow URL, GitHub Release URL, npm dist-tags, and final git state.
- Mention if release publishing skipped because the exact version already existed.
