Spark Release Skill

Overview

This skill creates a new version of Spark iOS:

1. Updates the CHANGELOG.md with the .script/update-changelog.swift script and the spark-changelog skill, then pushes it on main.
2. Creates the git tag (on the changelog commit) and the GitHub release with the notes generated by GitHub.

Prerequisites

1. gh must be installed and authenticated (gh auth status). If not, stop and tell the user to run ! gh auth login.
2. The current branch must be main and up to date with origin/main (git fetch origin --tags then git status). If not, stop and ask the user.
3. The working tree must be clean.
4. Do not mention Claude.

Steps

• Get the latest tag: git fetch origin --tags then git tag --sort=-v:refname | head -1 (e.g. 2.2.1).
• Ask the user the new version (semantic versioning X.Y.Z, no v prefix). Propose the patch, minor and major bumps of the latest tag (e.g. 2.2.2, 2.3.0, 3.0.0). Check the tag does not already exist.
• Generate the default release notes from GitHub:

  gh api repos/leboncoin/spark-ios/releases/generate-notes \
    -f tag_name=<new-version> \
    -f target_commitish=main \
    -f previous_tag_name=<latest-tag> \
    --jq .body
  

  The expected content looks like:

  ## What's Changed
  * fix(button): include padding in UIKit button intrinsic content size by @robergro in https://github.com/leboncoin/spark-ios/pull/1128
  
  
  **Full Changelog**: https://github.com/leboncoin/spark-ios/compare/2.2.0...2.2.1
  

• Propose a release title: <new-version> - <summary>, where <summary> is a short lowercase sentence (no final period) describing the main changes of the release. Examples:
  • 2.2.1 - include padding in UIKit button intrinsic content size
  • 2.2.0 - drop iOS 16 support and set iOS 17 as minimum deployment target
  • 2.1.0 - improve segmented control and spinner, update documentation Check the previous titles with gh release list -L 5 to keep the same style.
• Show the version, the release title and the release notes to the user and ask for confirmation before going further.
• Update the changelog first (it must be in the released commit), staying on main:
  • Run the script from the repository root: swift .script/update-changelog.swift <new-version> "<release notes>".
  • Use the spark-changelog skill to replace the placeholder with the real content.
  • Once the changelog is validated, use the spark-push skill to commit (chore(changelog): update for <new-version>) and push directly on main (do not create a branch for this commit).
• Ask for confirmation before creating the tag and the release (they are public).
• Create and push the tag on the changelog commit:

  git tag <new-version>
  git push origin <new-version>
  

• Create the GitHub release with the generated notes (pass them through a temporary file to keep the formatting):

  gh release create <new-version> --title "<release-title>" --notes-file <notes-file> --verify-tag --latest
  

• Show the release URL to the user.

Notes

• If the tag push or the release creation fails, do not retry blindly: show the error to the user. If the tag was pushed but the release failed, only retry the gh release create step.
• Never delete or move an existing tag without an explicit request of the user.