release

# Release The maintainer drives releases in two phases, keyed off repo state. With the automation checkpoint below, one run can carry straight through both without stopping in between — pick the starting phase from what they asked and the repo state, then keep going as far as they authorize. - **Phase 1 — "bump version"**: the bump/changelog/PR are not on `main` yet. - **Phase 2 — "release it"**: the bump PR has merged to `main`; now tag and ship. `package.json` `version` is the source of truth; the tag is `v` + that exact string. CI internals, the botched-release runbook, and platform/signing notes live at the end of this skill. ## Orient first Two things to settle before touching anything, especially on a bare `/release` with no phase named. **Which phase?** Compare the working version to the latest tag: ``` node -p "require('./package.json').version" # e.g. 0.1.5 git tag --sort=-v:refname | head -1 # e.g. v0.1.4 ``` Version **equals** the latest tag → the last release shipped and nothing is pending → **Phase 1** (cut the next version). Version is **ahead** of the latest tag → a bump already merged but isn't tagged → **Phase 2** (tag and ship). When unsure, `git log --oneline --first-parent vLAST..HEAD` shows what's unreleased. **`gh` defaults to the wrong host.** This repo lives on personal GitHub, but `gh` defaults to the work host, so every `gh` call needs both the host and the repo: ``` GH_HOST=github.com gh <cmd> -R luojiahai/code-by-wire ... ``` ...