CRT/storebound
1
0
Fork 0
Code Issues Pull requests Releases 1 Packages 1 Activity Actions

Store operations: TestFlight wait / expire, IAP review submissions, listing pulls, release notes per language, offers, custom product pages, in-app events, reports, triage, keyword ranks, AdAttributionKit scan

Browse source 
- apple testflight wait --build N (progress, timeout, exit 0/1/7) and expire --keep N | --older-than D (dry run, asks)
- apple iap-submit: IAP / subscription / group versions into a review submission; first of a type only with the app
  version (--with-version), --no-submit keeps the draft; read-only MCP plan
- apple listing pull, play listing pull (diff, --write), catalog pull (config proposal, never rewritten)
- whats-new --languages / check / apply: one file per language, agent or hook translation, per-store limits
- apple offer-codes, win-back, promoted, preorder; Play pre-registration as a guide (no API)
- apple cpp and apple events: list, create, upload, submit (asks)
- reports: Apple sales / finance, Play earnings / sales into .storebound/reports with summary and CSV
- triage: TestFlight crash / feedback and Play error reports grouped by signature, device, OS
- aso rank: iTunes Search API ranks and competitors, rate limited
- ads scan: AdAttributionKit / SKAdNetwork Info.plist and source checks
- tests against recorded, sanitized answers; skills, README, CHANGELOG
This commit is contained in:
CRTkafa 2026-10-11 23:58:17 +08:00
parent 346d80e07e
commit b63f2fdfbc
55 changed files with 4388 additions and 62 deletions
Download patch file Download diff file Expand all files Collapse all files

18
skills/store-health/SKILL.md
View file

@ -1,6 +1,6 @@
---
name: store-health
description: Watch a released mobile app's or game's crash and ANR health on both stores - Google Play Android vitals (user-perceived crash rate 1.09 % and ANR rate 0.47 % bad behavior thresholds, 8 % per device model) through the Play Developer Reporting API, App Store power and performance metrics, diagnostic signatures and TestFlight crash reports, a weekly Markdown report, and validate blockers when a threshold is crossed. Use when the user asks about crashes, ANRs, vitals, stability, a weekly health check, or why Play shows a quality warning.
description: Watch a released mobile app's or game's crash and ANR health on both stores - Google Play Android vitals (user-perceived crash rate 1.09 % and ANR rate 0.47 % bad behavior thresholds, 8 % per device model) through the Play Developer Reporting API, App Store power and performance metrics, diagnostic signatures and TestFlight crash reports, crash and feedback triage grouped by signature, device and OS version, a weekly Markdown report, and validate blockers when a threshold is crossed. Use when the user asks about crashes, ANRs, vitals, stability, a weekly health check, or why Play shows a quality warning.
---
# Store health (crashes, ANRs, diagnostics)
@ -29,8 +29,22 @@ instead). `storebound validate` runs the same checks for live apps. MCP: `health
launch time, memory, disk writes, battery) and on diagnostic signatures with a large share of reports (Xcode >
Organizer shows the stack traces). TestFlight crash reports count crashes testers sent from the beta.
## Triage: which crash first
`storebound triage [--days 14] [--build N] [--apple | --play] [--json]` (MCP: `triage`, read-only) groups what testers
and players hit:
- **TestFlight crashes**: every crash report's log is read and turned into a signature (exception type + the first
frame of the crashed thread inside the app; text and `.ips` crash formats), then grouped with its top device models,
OS versions and builds.
- **TestFlight screenshot feedback**: grouped by device; `--comments 3` shows up to three comments per group (cut to 120
characters). Tester emails are never requested (the reads list their fields without `email` / `tester`).
- **Google Play**: the top `--issues` (default 10) crash / ANR issues of the window (Play's own clusters), then their
error reports for the spread by device (marketing name), API level and versionCode. Counts are of the sampled
reports; the issue's total reports and users come from Play.
Fix the top signature first, then check its device / OS column: one model or one OS version points at a device bug.
## Act on it
1. Start with the top issues table (Play: cause + location + versionCode; Apple: signature + build).
1. Start with the top issues table (Play: cause + location + versionCode; Apple: signature + build), or with
`storebound triage` for the grouped view.
2. Reproduce on the named device model / OS; for ANRs look for main-thread work (I/O, ads SDK init, big asset
loads), for crashes the null / out-of-memory paths.
3. Ship the fix with a higher versionCode / build number (release-management skill). Halting a rollout stops new