← ClaudeAtlas

releaselisted

Prepare dynobox packages for release to npm. Use this skill whenever the user asks to release, publish, ship, bump, or cut a version of any dynobox package — including dry runs, version bumps, changelog updates, and git tagging. Also trigger when the user asks about the release process or wants to verify publish readiness.
dynobox/dynobox · ★ 0 · AI & Automation · score 68
Install: claude install-skill dynobox/dynobox
# Release This skill prepares dynobox packages for release. It handles everything up to but not including `npm publish` — tests, version bumps, changelog updates, tarball inspection, committing, and tagging. At the end it presents the publish commands for the user to run manually. Read `RELEASES.md` before making release changes. If this skill and `RELEASES.md` disagree, follow `RELEASES.md`. ## Before you start Verify the repository is ready: ```bash git status --short git branch --show-current pnpm test ``` Continue only when: - `git status --short` is empty. - The current branch is `main`, unless the user explicitly approves another branch. - `pnpm test` passes. Abort and report the blocker if the working tree is dirty or tests fail. ## Determine what to release Identify the package name, package directory, and requested bump: ```bash pnpm --filter <package-name> exec node -p "require('./package.json').version" ``` Use these package names for public releases: - `dynobox` for `packages/cli` - `@dynobox/sdk` for `packages/sdk` Current package policy: - Publish `dynobox` and `@dynobox/sdk` to npm. - Keep `@dynobox/runner-local` and `@dynobox/evaluators` private. - The `dynobox` CLI bundles private runtime workspace packages instead of exposing them as public npm dependencies. If releasing multiple packages, identify workspace dependencies and plan to publish dependencies first. For example, publish `@dynobox/sdk` before `dynobox`. If the user did not specif