CRT/storebound
1
0
Fork 0
Code Issues Pull requests Releases 1 Packages 1 Activity Actions
storebound/skills/release-management/SKILL.md
CRT 56e107dbbe Crash and vitals health: storebound health [--weekly], validate findings, store-health skill 
Play Developer Reporting API v1beta1 (crashRateMetricSet / anrRateMetricSet DAILY queries in America/Los_Angeles,
user-perceived 28-day rates, worst device models, errorIssues:search) and App Store Connect perfPowerMetrics,
diagnostic signatures and TestFlight crash submissions. Thresholds 1.09 % crash / 0.47 % ANR / 8 % per device
(developer.android.com/topic/performance/vitals): over = blocker, from 80 % = warn, in validate too (--no-health).
Weekly Markdown report with week-over-week change in .storebound/health/. MCP: health (read-only), health_report.
2026-10-10 23:28:10 +08:00

3.9 KiB
Raw Blame History

name description
release-management Ship updates safely after the first release - App Store phased release (on, pause, resume, complete) with manual release by default, Google Play staged rollout (fraction, halt, resume, complete), waiting for review, picking build numbers, and what to do when a release goes wrong (pausing is not a rollback). Use when the user releases an update, wants a gradual rollout, needs to stop a bad release, or asks how long review takes.

Release management (updates on both stores)

CLI: storebound (on PATH as a plugin; or bunx storebound / bun <toolchain>/cli/index.ts). Rules: the owner presses release; you prepare, dry-run and report. storebound mcp deliberately offers only "phased on" and "pause".

Defaults

  • App Store: release type manual (storebound sets MANUAL on every version it touches) and phased release on. Never choose "reset ratings" when releasing an update (storebound never sets it); only an owner who really wants the rating summary wiped does that in the UI.
  • Play: production updates as a staged rollout starting at 5-10 %.

App Store

  1. Build numbers: storebound apple next-build before archiving, then attach exactly that build: storebound apple listing --version 1.3.0 --build <that number>. Never pick "the latest build": a CI or a teammate may have uploaded another one meanwhile.
  2. storebound apple release --phased on --dry, then without --dry (works while the version is being prepared).
  3. Submit (owner, UI). Wait: storebound apple status --wait-review (polls with backoff, exit 0 approved, 1 rejected, 7 timeout; --timeout 72h). Rejected: review-rejections skill.
  4. Approved = PENDING_DEVELOPER_RELEASE. Owner releases: storebound apple release --manual-release (asks to confirm) or the "Release This Version" button. With phased release on, automatic updates reach 1 %, 2 %, 5 %, 10 %, 20 %, 50 %, 100 % over 7 days; anyone can still update manually from the store.
  5. During the rollout watch crashes / reviews. Problem: storebound apple release --phased pause (up to 30 days in total). Pausing stops automatic updates only; it is not a rollback: users who updated keep the build, and new users still get the new version. The fix is a new build (expedited review is possible for critical bugs).
  6. All good early: storebound apple release --phased resume / --phased complete (owner; asks to confirm).

Google Play

  1. storebound play next-version-code before building; the versionCode must be higher than every uploaded one.
  2. Upload and start the rollout (owner confirms): storebound play release app.aab --production inProgress --fraction 0.05. Draft apps cannot do this until the first release is reviewed (play-first-release).
  3. Increase: storebound play rollout --fraction 0.2 (then 0.5, ...). Play never lowers a fraction.
  4. Problem: storebound play rollout --halt (no confirmation needed; stops new installs of the update). Like Apple's pause it is not a rollback: updated users keep it. Ship a fixed build with a higher versionCode; resume with --resume [--fraction x] only if the halted build is fine after all.
  5. Done: storebound play rollout --complete (100 %). Before each increase, storebound health --play (store-health skill): crash / ANR rates near Play's thresholds are a reason to halt, not to widen.
  6. Every rollout command runs in an edit: a Console save at the same time makes it retry once.

Review wait

  • Apple: most reviews finish within a day or two; holidays and big OS launches are slower. Expedited review is for critical fixes, not deadlines.
  • Play: updates usually take hours to a few days; new apps and policy-sensitive changes longer.
  • Do not resubmit or cancel to "jump the queue": it puts you at the back.

Release notes

whats-new skill (storebound whats-new), then apple listing / play release push them.