Release Helper

You are assisting with a release. Detect the project type first, then follow the relevant checklist.

Project Type Detection

Auto-detect before proceeding:

• app.json or app.config.* → Expo / React Native
• next.config.* → Next.js
• package.json only → Node.js library or generic web
• Check for eas.json, Fastfile, Podfile → mobile-specific tooling
• Check for Dockerfile, deploy scripts, CI config → containerized / web deployment

Pre-Release Checklist

All project types — verify each item:

1. Clean working tree — git status shows no uncommitted changes.
2. Correct branch — on the release branch or main, per project convention.
3. Tests pass — run the test suite and confirm green.
4. No leftover markers — grep for TODO:, FIXME:, HACK: in files changed since the last release.
5. Dependencies current — npm outdated / yarn outdated to check for stale deps.
6. No security advisories — npm audit / yarn audit for known vulnerabilities.

Version Bumping

• Follow semver: breaking change → major, new feature → minor, bug fix → patch.
• If conventional commits are used, derive the version bump from commit prefixes (feat: → minor, fix: → patch, BREAKING CHANGE → major).
• Update package.json version field.

Mobile additional

• Update app.json / app.config.*: version string + ios.buildNumber / android.versionCode.
• Ensure native version numbers align with package.json.

Changelog (generated, not hand-maintained)

The changelog is a derived view of git history — never authored by hand. Generate it at the release boundary only.

Source of truth. Commit messages are the source of truth; CHANGELOG.md is a rendering of them. The one thing git cannot derive is deploy state — whether a change has actually shipped. The human must confirm that. Example: an Expo app built locally but not yet EAS-submitted stays under [Unreleased] even though its commits are already merged.

Input contract. Generation is only reliable when commits follow the URM convention: <area>: <imperative summary> (URM-###). Match the format of /Users/tiki/Code/urm-mobile/CHANGELOG.md as the concrete template.

Generate / refresh. At release time, rebuild the changelog from git:

1. Collect commits: git log <last-tag>..HEAD — fall back to full history if no tags exist.
2. Map each commit's area/type prefix to a Keep-a-Changelog category:
   • feat → Added
   • fix → Fixed
   • refactor / style / docs → Changed (or omit if noise)
   • removals → Removed; security patches → Security
3. Extract any (URM-###) ticket tag and keep it as a reference on that line.

One accumulating [Unreleased]. Maintain a SINGLE [Unreleased] section that accumulates. When you cut a version, RENAME [Unreleased] to the new version + date and open a fresh, empty [Unreleased] above it. Never append endless per-commit entries; never create a new heading per commit.

Format:

## [Unreleased]

### Added
- Short description (URM-123)

### Fixed
- Short description (URM-124)

## [X.Y.Z] - YYYY-MM-DD

### Changed
- Short description (URM-120)

Anti-pattern — do not do this. Do NOT add changelog-writing to the per-commit flow or the commit skill. A line written per commit is redundant with the commit message and drifts out of sync with it. Changelog work happens at the release boundary only.

Mobile-Specific Steps

• Suggest EAS build commands: eas build --platform ios --profile production, eas build --platform android --profile production
• Check that version/build numbers don't collide with existing app store submissions.
• Advise on OTA vs native update: JS-only changes can use OTA (eas update), native dependency changes require a full build.

Web-Specific Steps

• Run the build and confirm it succeeds cleanly (npm run build / yarn build).
• Create git tag: git tag v<version>
• Note any post-deploy verification steps (smoke tests, health checks).

Post-Release

1. Commit version bump + changelog changes.
2. Create git tag (git tag v<version>).
3. Summarize for the user:
   • Version number
   • Key changes included
   • Any manual steps remaining (pushing tags, triggering deploys, app store submission)