// Prepare a new release for the pipelex-starter-js project. Bumps version in package.json, syncs package-lock.json, updates CHANGELOG.md, manages the release/vX.Y.Z branch, runs checks, and commits. Use when the user says "release", "prepare a release", "bump version", "new version", or "cut a release".
| name | release |
| description | Prepare a new release for the pipelex-starter-js project. Bumps version in package.json, syncs package-lock.json, updates CHANGELOG.md, manages the release/vX.Y.Z branch, runs checks, and commits. Use when the user says "release", "prepare a release", "bump version", "new version", or "cut a release". |
Guides the user through preparing a new pipelex-starter-js release in 8 interactive steps. Every step requires explicit user confirmation before proceeding.
Read the following and present a summary:
package.json ("version": "X.Y.Z")CHANGELOG.md (if it exists — this repo may not have one yet; see Step 6)git branch --show-current)git status --short)If the working tree is dirty, warn the user and ask whether to continue or abort.
Calculate the three semver bump options from the current version:
X.Y.Z+1X.Y+1.0X+1.0.0Present these options to the user using AskUserQuestion. If the current branch already looks like release/vA.B.C and the version in package.json was already bumped, offer a "Keep current (A.B.C)" option.
Store the chosen version as TARGET_VERSION (no v prefix, e.g. 0.1.3).
The release branch must be named release/v{TARGET_VERSION}.
dev, main, or another branch: confirm with the user, then create and switch to release/v{TARGET_VERSION}.Edit the "version": "..." line in package.json to "version": "{TARGET_VERSION}".
The version in package.json must not have a v prefix (e.g. 0.1.3, not v0.1.3).
After updating package.json, regenerate the lock file so it reflects TARGET_VERSION:
npm install --package-lock-only
This updates package-lock.json without modifying node_modules.
The changelog entry must match the format: ## [vX.Y.Z] - YYYY-MM-DD.
If CHANGELOG.md does not exist yet (this starter shipped without one initially), offer to create it with a # Changelog heading plus the new entry. Otherwise check whether it already contains a ## [v{TARGET_VERSION}] - entry.
git log main..HEAD --oneline (or git log --oneline -20 if on main) to review recent commits. Draft a changelog entry from those commits and propose it to the user for approval. Insert the approved entry at the top of the changelog (after the # Changelog heading) formatted as:## [v{TARGET_VERSION}] - {TODAY'S DATE in YYYY-MM-DD}
### Added
- Item one
### Changed
- Item two
### Fixed
- Item three
Use the appropriate subsections (Added, Changed, Fixed, Removed, Breaking Changes) based on the commits. Only include subsections that have content. The user may accept, edit, or rewrite the proposed entry.
Run:
make all
This runs lint + format-check + typecheck + unit tests + production build (per the project's Makefile and CLAUDE.md). It deliberately excludes make test-e2e, which hits the live Pipelex API and costs an LLM call.
If the release touches the SDK call path (src/actions/, src/lib/pipelexClient.ts, src/lib/loadBundle.ts, src/lib/errors.ts, src/lib/fileEncoding.ts, or methods/), offer to also run make test-e2e — but only with explicit user approval, since it costs LLM calls.
Present a full summary:
v{TARGET_VERSION}release/v{TARGET_VERSION}package.json, package-lock.json, CHANGELOG.mdAsk the user to confirm. On confirmation:
package.json, package-lock.json, and CHANGELOG.md — never use git add . or git add -A.Bump version to {TARGET_VERSION} and update changelogThen offer (but do not automatically execute):
git push -u origin release/v{TARGET_VERSION})main using gh pr create (per CLAUDE.md, the PR target branch for this repo is main)Wait for explicit user approval before pushing or creating a PR.
git add . or git add -A — only stage package.json, package-lock.json, and CHANGELOG.md.v prefix appears in branch names and changelog headers, but not in package.json.YYYY-MM-DD).