CRT/storebound
1
0
Fork 0
Code Issues Pull requests Releases 1 Packages 1 Activity Actions
storebound/skills/whats-new/SKILL.md
CRT b63f2fdfbc 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
2026-10-11 23:58:17 +08:00

4.4 KiB
Raw Blame History

name description
whats-new 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)

CLI: storebound whats-new [--since v1.2.0] [--dry]. It reads git log <tag>..HEAD, drops housekeeping commits (chore, ci, docs, refactor, test, merges, version bumps), turns feat: / fix: / perf: subjects into bullets and writes a draft into the default language of store/listing.md (Play "What's new") and store/appstore.md (whatsNew). Nothing is sent to a store. --all writes the draft into every language as a starting point for translation; storebound check warns while a translation is still identical to the source.

Write it for your users

  1. Run storebound whats-new --dry, read the draft with the owner.
  2. Rewrite:
    • First line = hook (the stores show roughly the first 170 characters before "more"): the most exciting change in user words ("New: shared lists with your family" for an app, "New: 20 desert levels and a daily challenge!" for a game).
    • Then 2-5 bullets, most visible first. User words, not code words: "Lists open faster" / "Levels load faster", not "refactor asset loader"; never internal ids, branch names or ticket numbers.
    • Fixes in one line unless a fix was a known user complaint.
    • No promises of future features, no prices, no other platforms.
  3. Translate into every listing language (natural tone, the app's own terms, same meaning; not word by word). Arabic stays RTL; keep numbers and product names as they are.
  4. Limits: Google Play 500 characters per language, App Store 4000; storebound check enforces both. A first App Store version has no "What's new" (storebound leaves it empty there).
  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.
  • Release notes are public: nothing about cheats, exploits, unreleased content or private names.