# Jb Local Release

> Use when the user asks to run a local release flow: prepare version/changelog changes, run local checks, commit, tag, and optionally publish only when explicitly requested.

- Skill: `bjesuiter/jb-local-release` (Agent Skill)
- Install (CLI): `npx skillmds@latest add bjesuiter/jb-local-release`
- Raw SKILL.md: https://api.skillmd.com/api/skills/bjesuiter/jb-local-release/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: bjesuiter (https://skillmd.com/u/bjesuiter)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/bjesuiter/jb-local-release

---


# JB Local Release

Author: bjesuiter

## Purpose

Use this as the **local release workflow skill** when preparing a release from the current checkout: update version/changelog files, run local verification, commit, tag, and only publish when explicitly requested or documented.

## Precedence

Repo-specific instructions win. Before acting, check for release guidance in:

- `AGENTS.md`, `CLAUDE.md`, `README.md`, `CONTRIBUTING.md`, `CHANGELOG.md`
- package manager scripts in `package.json`
- project-specific skills or docs, such as `docs/release*`, `.github/*`, or maintainer notes

If specific instructions exist, follow them instead of this generic workflow. Use this skill only to fill gaps for local release preparation.

## Local release workflow

1. **Identify release type and target**
   - Confirm the package/app to release if the repo has multiple packages.
   - Determine version bump: `patch`, `minor`, `major`, prerelease, or exact version.
   - If the user did not specify the bump/version, ask before changing files.

2. **Inspect current release state**
   - Check clean/dirty git state with `git status --short`.
   - Find latest tag: `git tag --sort=-version:refname | head`.
   - Review commits since the last release tag: `git log <last-tag>..HEAD --oneline`.
   - Check package metadata and publish scripts.

3. **Update release files**
   - Update the version in `package.json` and lockfiles using the repo's package manager when possible.
   - Add a concise `CHANGELOG.md` entry based on commits since the last release tag.
   - Keep changelog entries user-facing and grouped when useful: Added, Changed, Fixed, Removed.

4. **Verify**
   - Run the repo's normal checks before tagging:
     - lint
     - tests
     - build/typecheck
   - Prefer existing package scripts over inventing new commands.
   - If a check cannot be run, record why.

5. **Commit, tag, and push**
   - Commit release changes with a clear message, e.g. `chore: release v1.2.3`.
   - Tag the release commit with the version prefixed by `v`, e.g. `v1.2.3`.
   - Push code and tags.

6. **Publish only when requested or documented**
   - Do not publish to npm, app stores, or other registries unless the user explicitly asks or repo instructions require it.
   - If publishing, use the documented release script/CLI and verify the published version afterward.

## Guardrails

- Never create a branch unless the user asks.
- Do not overwrite project-specific release automation.
- Do not skip failing checks silently; stop and report the failure.
- Do not tag before release files are committed and checks have passed, unless repo-specific instructions say otherwise.
- Avoid changing unrelated files during a release.

## Deliverable

End with a short summary containing:

- released version
- changelog entry added/updated
- checks run and results
- commit hash and tag
- whether anything was published