campfire: Skill for Claude Code

Campfire release preparation

Produce one throwaway markdown file whose whole contents the user pastes into the description of a new GitHub release: the notes people read, followed by the hidden block publish-all.yml reads. Publishing that release is the entire release process, so the file has to be complete as it is — nothing to fill in, nothing to cut before pasting. Match the style of the existing notes at https://github.com/pandulapeter/campfire/releases.

Also update the tracked in-app message resources and the store listings where the release changed what they say, and regenerate the tracked Android profiles before the release is tagged. These are part of preparing every release, including a small release with empty notes.

Campfire is an app, not a library. The notes are for the people who use it — musicians — not for developers reading the source. Nothing about modules, classes, Gradle, Koin or the build belongs in them. If a change has no effect a user could notice, it is not in the notes.

Process

1. Determine the version. The release version is campfire.versionName in gradle.properties (campfire.buildNumber, which every platform shares, moves with it). The GitHub tag is that number without the v prefix (4.0.1), even though the bump commit spells it with one.

2. Find the previous release boundary — the last release tag, never a version bump commit (a bump can land for a version that was never published, and a release is what the tag marks):

   grep -n 'campfire.versionName' gradle.properties
   git fetch --tags origin
   gh release list --limit 3
   git describe --tags --abbrev=0 --match '[0-9]*.[0-9]*.[0-9]*' --exclude "$(sed -n 's/^campfire\.versionName=//p' gradle.properties)"
   git tag --list '[0-9]*.[0-9]*.[0-9]*' --sort=-v:refname | head -3
   

   The git describe line prints <last tag>: release tags are bare version numbers, so older v-prefixed tags (v1.0.0) are never a boundary, and the version being prepared is excluded so that a run after that version was already tagged (on HEAD or on a commit before it) still finds the release before it. The range is <last tag>..HEAD, for the GitHub notes, the stores' blurb and the in-app message alike: every change since the last published release is in scope, whatever else was prepared or reverted in between. Fetch the tags first: a release is published on GitHub, which creates its tag there and nowhere else, so a clone that has not fetched since misses the newest one and would put a release that already shipped into these notes. The <last tag> must be the newest non-pre-release that gh release list shows (other than the version being prepared); if the two disagree, stop and find out why before writing anything.