| name | ns-release |
| description | Cut a NowStack Mobile release. Bump version, generate changelog, and promote existing TestFlight/Play internal builds to production. Does not rebuild. |
Release - NowStack Mobile
Ship the version that's already on TestFlight (iOS) and the Play internal track (Android) to production — with a real changelog and a version bump. This skill does not build; it bumps the version, writes the changelog/release notes, and hands the existing beta builds to ns-ios-distribute and ns-android-distribute for the production submission. If there's no build on a testing track yet, run ns-ios-testflight / ns-android-beta first.
Turn "the beta build is verified" into "a versioned, documented production release" with one orchestrated flow: pick the version, generate the changelog, write store release notes, bump version files, then promote per platform and tag the release.
- **What this owns:** version bump, changelog/release-notes generation, git tag, and orchestrating the per-platform production submission.
- **What it delegates:** the actual store submission — iOS → `ns-ios-distribute`, Android → `ns-android-distribute` (which promotes the internal build to production).
- **What it never does:** rebuild the app, or upload a fresh binary. Production ships the binary that testers already validated.
```bash
git status --short # clean tree; commit/stash first
git rev-parse --abbrev-ref HEAD
uname -s || node -p "process.platform"
```
- Confirm a verified build exists on each target surface: TestFlight (iOS) and the Play internal track (Android). Skip a platform the user isn't releasing.
- If a requested platform has no beta build yet, do not rebuild inside this skill. Delegate to the OS-aware build skill first: `ns-ios-testflight` for iOS or `ns-android-beta` for Android. Those skills decide local macOS vs. Windows/Linux EAS cloud and run `ns-setup-expo` when required.
- Ask which platforms to release (iOS, Android, or both).
Read the current marketing version (single source for the human-facing version):
```bash
grep -m1 "version:" mobile-app/app.config.ts # e.g. version: '1.0.0'
node -p "require('./mobile-app/package.json').version"
```
Decide the bump with the user: `patch` (fixes), `minor` (features), `major` (breaking). Compute the new semver `X.Y.Z`.
Native build numbers (iOS buildNumber, Android versionCode) are auto-incremented by EAS (mobile-app/eas.json > autoIncrement: true) — do NOT hand-edit them.
Collect commits since the last release tag:
```bash
LAST=$(git describe --tags --abbrev=0 2>/dev/null || echo "")
git log ${LAST:+$LAST..}HEAD --no-merges --pretty="- %s"
```
From that list produce TWO things:
1. **`CHANGELOG.md` entry** — a new `## vX.Y.Z — ` section (developer-facing, grouped by feat/fix/chore). Prepend it under the title; pass the date in, don't invent one.
2. **Store release notes** — a concise, user-facing "what's new" (≤500 chars, no commit hashes, no internal jargon). This is what App Store / Play reviewers and users read.
Show both to the user and let them edit before anything ships.
Set the new `X.Y.Z` in both files (keep them in sync):
- `mobile-app/app.config.ts` → `version: 'X.Y.Z'`
- `mobile-app/package.json` → `"version": "X.Y.Z"`
Commit the bump + changelog together:
git add mobile-app/app.config.ts mobile-app/package.json CHANGELOG.md
git commit -m "chore(release): vX.Y.Z"
Hand the store submission to the distribute skills, passing the store release notes from phase 3. Confirm with the user before each store mutation.
- **iOS** → follow `.agents/skills/ns-ios-distribute/SKILL.md` (submits the TestFlight build for App Store review with the new version + release notes).
- **Android** → follow `.agents/skills/ns-android-distribute/SKILL.md` (promotes the internal build to the production track with a staged rollout + release notes).
These can run in parallel; report each platform's outcome separately.
After the submissions are accepted/queued, tag and push:
```bash
git tag vX.Y.Z
git push && git push --tags
```
The tag becomes the baseline for the next release's changelog (phase 3).
- Never rebuild or upload a new binary here — promote the validated beta build. A rebuild means a new, untested binary in production.
- Store mutations (App Store submit, Play production promote) always need explicit user confirmation; the iOS App Store review submission and the Android 100% rollout each get their own confirmation.
- Keep `app.config.ts` and `package.json` versions identical. Don't touch `buildNumber`/`versionCode` — EAS owns them.
- Release notes are user-facing prose, not a commit dump.
<success_metrics>
- New semver in
app.config.ts + package.json, committed with the changelog and tagged vX.Y.Z.
CHANGELOG.md has a dated entry; store release notes written and approved.- Each requested platform's existing beta build is promoted to production (no rebuild), each confirmed by the user.
</success_metrics>
