Menu
Cut a NowStack Mobile release. Bump version, generate changelog, and promote existing TestFlight/Play internal builds to production. Does not rebuild.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when optimizing Convex database read bandwidth, documents-read cost, query indexes, full-table scans, function-level usage dashboard findings, or code that uses .filter(), unbounded .collect(), N+1 reads, or expensive reactive Convex queries.
Build reusable Convex components with isolated tables and app-facing wrappers. Use for defineComponent, app.use, ComponentApi, or shared backend modules.
Plan safe Convex schema and data migrations. Use for widen-migrate-narrow rollouts, backfills, breaking field changes, table splits, or failed schema deploys.
Audit Convex performance for hot reads, write contention, subscriptions, function limits, OCC conflicts, latency, read amplification, and expensive reactive queries.
Set up Convex authentication and authorization. Use for Convex Auth, Better Auth, Clerk, Auth0, JWT providers, auth.config.ts, protected functions, and user mapping.
Integrate PostHog analytics into Expo apps. Use for posthog-react-native setup, providers, screen tracking, env config, identify calls, and error tracking.
| 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. |
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.
Native build numbers (iOS buildNumber, Android versionCode) are auto-incremented by EAS (mobile-app/eas.json > autoIncrement: true) — do NOT hand-edit them.
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"
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>
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.