Softcover: Skill for Claude Code

Orchestrate a release-prep pass by composing the existing skills. Never commit or tag; leave all changes unstaged for the user to review.

Steps:

1. Invoke the update-readme skill via the Skill tool to bring the README current with the latest features.

2. Invoke the style-check skill via the Skill tool to auto-fix style and run the full gate. If the gate is not green, stop and report — do not bump the version on a red build.

3. Read the current versionCode and versionName from app/build.gradle.kts and show them to the user. Ask for the new versionName (suggest the next semantic version). If the user provided one as an argument, use that.

4. Invoke the set-version-name skill via the Skill tool with the new version name. It sets the version name across all platforms (Android versionName, iOS MARKETING_VERSION, desktop packageVersion) and bumps the build number together — do not edit any of those fields yourself.

5. Write the CHANGELOG.md entry. Read the commits since the previous tag (git log --no-merges --format=%s $(git describe --tags --abbrev=0)..HEAD) and add the entry at the top of the entries, directly below the intro line (anything above the first entry is never shown in the app; anything below it is, so keep notes and comments out of the file):

   ## <version>: <headline>
   
   *<today, YYYY-MM-DD>*
   
   <optional one-sentence lede>
   
   - <bullet per reader-visible change>
   

   Write in the public editorial voice: what a reader gets, not what changed internally. No em-dashes or other AI tells. Then run python3 scripts/changelog/extract_release_notes.py <version>; if it errors, fix the entry or stop and report — do not continue.

   Why it belongs here: releases tag the merge commit on main, so the entry must be part of the release PR before the tag exists. The app fetches CHANGELOG.md from main, and the release workflow publishes this same entry as the GitHub Release body (and fails the release if it is missing).

6. Close the shipped milestone. If a GitHub milestone matches the version being released, ask the user to confirm, then close it (gh api -X PATCH repos/{owner}/{repo}/milestones/{n} -f state=closed). This is the one live GitHub write in an otherwise local skill, so confirm first; it is trivially reversible by reopening.

   Why it belongs here: the public roadmap is built from open milestones, so leaving it open makes ROADMAP.md name the new version as the current release and list it as a future release in the same file. Skipping this ships a self-contradictory roadmap to the in-app Roadmap screen.

7. Update the "what shipped" sentence in scripts/roadmap/header.md. This is the only line in the public roadmap that no machine can derive, and release time is the only moment it can be written.

   • Read the commits since the previous tag (git log --no-merges --format=%s $(git describe --tags --abbrev=0)..HEAD) and summarise the release in the public, editorial voice already used in that file — what a reader gets, not what changed internally.
   • Lead with the new version and prune older detail rather than letting the sentence accumulate every patch forever. One or two sentences total.
   • Leave {{CURRENT_VERSION}} alone — it is substituted from Gradle at generation time.

8. Regenerate the public roadmap: python3 scripts/roadmap/generate_roadmap.py --write.

   This is mandatory, not optional. ROADMAP.md is a generated file, and the Roadmap workflow runs --check on any pull request touching ROADMAP.md or scripts/roadmap/**. Editing header.md in step 7 without regenerating leaves the file stale and fails CI on the release PR. Verify with --check before reporting.

9. Remind the user to verify R8 after the tag is pushed. On the tag run, the R8 release smoke job must have passed, the Softcover-<tag>-mapping.txt file must be attached to the GitHub release, and the mapping must be visible under the release in Play Console. Details in docs/reference/r8.md.