swift-release-flow

# Swift Release Flow ## Overview Ship a macOS/Swift app release from a clean `main` to a published GitHub release, in order. Do not skip steps. Stop and report if any preflight check fails — never force through a red signal. ## Prerequisites - `git` and the GitHub CLI (`gh`), authenticated against the repo. - A packaging/DMG script in the repo (Step 4 locates it) — see the companion `swiftpm-app-bundle` skill if none exists yet. - A `CHANGELOG.md` following Keep a Changelog conventions (created in Step 3 if missing). ## Instructions ### Step 0 — Confirm the target version Ask (or infer from CHANGELOG "Unreleased" content) what kind of release this is, then decide the version per semver-for-apps guidance: - **Patch (X.Y.Z+1)**: bug fixes, crash fixes, performance, copy/UI tweaks, no new user-facing capability. - **Minor (X.Y+1.0)**: new feature, new preference/menu item, new supported file type, a workflow users will notice and want to know about. - **Major (X+1.0.0)**: breaking change to data format, dropped OS support, a rewrite, or the maintainer explicitly wants to signal a big jump. - **0.x**: while pre-1.0, treat minor bumps liberally — everything is "still moving," and 0.x releases are prerelease by default (see Step 5). State the chosen version back before proceeding. ### Step 1 — Preflight Run these and stop on any failure — report exactly what's red and let the user decide how to fix it. Do not attempt to "fix around" a red preflight (e.g., don...