band-play: Skill for Claude Code

Release $ARGUMENTS in two phases and track their steps as a checklist. Phase 2 changes GitHub and starts only after the user confirms in chat; a confirmation for one release never covers the next one, and the store upload is done by the maintainer by hand.

Accounts

• Repository: borbiuk/band-play on github.com, personal account borbiuk.
• Every gh command runs as GH_TOKEN=$(gh auth token --user borbiuk) gh … -R borbiuk/band-play. Never run gh auth switch: it changes the global state.
• git push goes over SSH and needs the personal key; the default key belongs to another account: git -c core.sshCommand="ssh -i ~/.ssh/id_rsa -o IdentitiesOnly=yes" push …. The same applies to git fetch when it fails with a permission error.

Versioning

• Semantic versioning: patch for fixes only, minor for new features that stay compatible (settings and history stored in chrome.storage.local keep working), major for breaking changes (for example stored settings or shortcuts that older data cannot be read into, or a removed feature).
• No argument: propose the version from the changes since the last tag (git log <last-tag>..HEAD; tags are plain x.y.z, without a v) and ask the user before changing files.
• public/manifest.json is the source of truth. set-version.sh copies the version to package.json and public/manifest.firefox.json; tag-releases.sh finds the release commit by that version.

Phase 1: prepare (local only)

1. State: on master, git fetch origin and confirm master is not behind origin/master. Only changes that belong to the release are in the working tree.
2. Version: set "version" in public/manifest.json, run ./.husky/set-version.sh, then npm install --package-lock-only --ignore-scripts (it asks first). git diff package-lock.json must show only the two root version fields.
3. Release notes: RELEASE_NOTES.md gets a ## x.y.z section at the top (newest first; the tag script reads these headings): a one-line summary, a blank line, then ### Added, ### Changed and ### Fixed lists as needed. The summary line is also the GitHub Release title. User-visible changes are also in docs/usage.md and LISTING.md. Write in English and add no attribution lines.
4. Store images: there is no skill for them. If the popup, the feed player or the branding changed, tell the user that the store images need a manual update.
5. Checks: run /verify; every step must pass. Then run npm run test:live (smoke test against real bandcamp.com; it needs network) and report its result in step 7. A failure there means Bandcamp changed its markup, not that the build is broken: tell the user and let them decide. Also check for an open markup-drift issue (GH_TOKEN=$(gh auth token --user borbiuk) gh issue list -R borbiuk/band-play --label markup-drift): the daily markup.yml opens it when the tests fail on Bandcamp's current markup, and master CI stays red until it is fixed, so report it before releasing.
6. Commit: one commit Release x.y.z: <summary> with a short bullet list of changes, no co-author or "generated by" lines (git asks for confirmation). The Husky pre-commit hook copies the version, formats, runs git add -u (every modified tracked file goes into the commit; stage new files on purpose), rebuilds both targets and writes artifacts/band-play-build-chrome_<dd-mm-yyyy_hh:mm:ss>_x.y.z.zip and artifacts/band-play-build-firefox_<dd-mm-yyyy_hh:mm:ss>_x.y.z.zip (artifacts/ is gitignored). It needs jq and zip.
7. Stop and report: the commit hash, the two local zip paths (for local testing only), what was verified, the test:live result and the markup-drift state. Ask the user to test the build locally and to confirm the push.