releaselisted

# release `script/publish` does the release. This skill runs the checks that script does *not* do, then hands over. ## Preflight — run all of these before touching script/publish 1. **Working tree clean.** `git status --porcelain`. The script warns and offers to continue, but a dirty tree means uncommitted work gets swept into the release commits by the `git add .` after the build. Stop and ask. 2. **On the default branch, and pushed up to date.** `git status -sb`. 3. **Tests and lint green.** `script/test` and `script/lint` if present, otherwise `npm test`. Do not skip this — `script/publish` tags and pushes without running either. 4. **`## [Unreleased]` has content.** If `CHANGELOG.md` exists and that section is empty, stop: the release will ship with empty notes. Offer the `changelog-entry` skill. 5. **The version argument makes sense.** Semver, and not the version already in `package.json`. Breaking changes in the changelog mean a major. Report anything that fails and stop. Do not "fix" a failing test to unblock a release. ## Then hand off ```bash script/publish <version> ``` **It is interactive** — readline prompts for the version, and for whether to create the GitHub release. Never run it in the background, never pipe it, never try to answer its prompts for the user. Tell them to run it, or run it in the foreground and let them type. If they want it non-interactive, pass the version as the argument — that skips the version prompt, but the GitHub r