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
- 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:
parent
346d80e07e
commit
b63f2fdfbc
55 changed files with 4388 additions and 62 deletions
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
name: whats-new
|
||||
description: Write user-facing release notes ("What's new") for a mobile app or game update from the git log since the last tag - hook in the first line, plain user language, localized into every listing language, within store limits (Google Play 500, App Store 4000 characters). Use when preparing an update, when the user asks for release notes / changelog for the stores, or before play release / apple listing for a new version.
|
||||
description: Write user-facing release notes ("What's new") for a mobile app or game update from the git log since the last tag - hook in the first line, plain user language, localized into every listing language, one file per language translated by the agent (or a provider hook the owner sets), checked against store limits (Google Play 500, App Store 4000 characters) and applied to both listings. Use when preparing an update, when the user asks for release notes / changelog for the stores, or before play release / apple listing for a new version.
|
||||
---
|
||||
|
||||
# What's new (release notes)
|
||||
|
|
@ -28,6 +28,26 @@ translation; `storebound check` warns while a translation is still identical to
|
|||
5. Push: `storebound play release ...` uses the Play notes; `storebound apple listing --version x --build N` the
|
||||
App Store ones.
|
||||
|
||||
## Many languages, one file each
|
||||
1. `storebound whats-new --languages en,de,tr,ja --dry`, then without `--dry` (MCP: `whats_new_languages`). Values
|
||||
are language ids of the config or store codes; the **first is the source**. It writes `store/whats-new/<id>.md`:
|
||||
the source gets the draft (the Play-sized one when the source language is on Play, so it fits 500), every other
|
||||
language a copy of it with the header `<!-- whats-new lang=de source=en status=translate -->`. Translated files
|
||||
(`status=translated`) are kept on later runs unless `--force`.
|
||||
2. **You translate** each `status=translate` file: replace the text below the header, keep the header line and set
|
||||
`status=translated`. Follow step 3 above (natural tone, the app's terms, same meaning). The CLI never calls a
|
||||
translation service and holds no key for one.
|
||||
Optional provider hook (the owner's choice): `--translate "<command>"` runs that command once per language with the
|
||||
source text on stdin and `STOREBOUND_SOURCE_LANG` / `STOREBOUND_TARGET_LANG` (App Store locale, else Play code) /
|
||||
`STOREBOUND_TARGET_LANG_ID` in the environment; its stdout becomes the file (`status=translated`). Any key it needs
|
||||
lives in the owner's environment, never in the config. Read hook output like any draft before applying it.
|
||||
3. `storebound whats-new check` (MCP: `whats_new_check`): per language the characters against the stores that
|
||||
language is listed on (Google Play 500, App Store 4000), untranslated files, a translation identical to the source,
|
||||
a first line over ~170 characters. Exit 1 while a language is not ready.
|
||||
4. `storebound whats-new apply --dry`, then `apply` (MCP: `whats_new_apply`): writes every file into its Play
|
||||
sections ("What's new" for each Play code of the language) and its App Store locale (`whatsNew`). It refuses while
|
||||
any language fails the check.
|
||||
|
||||
## Gotchas
|
||||
- Squash-merged repos: the PR titles are the subjects; keep them in conventional form (`feat: ...`) to get clean drafts.
|
||||
- Commits marked `[skip notes]` or `[internal]` are left out.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue