134 lines
13 KiB
Markdown
134 lines
13 KiB
Markdown
<!-- generated by tools/gen-adapters.ts from docs/agents-core.md and skills/*/SKILL.md; do not edit -->
|
|
|
|
# storebound for GitHub Copilot
|
|
|
|
Mobile app and game store releases (Google Play, App Store). Skills live in `skills/<name>/SKILL.md` (Agent Skills
|
|
format; `storebound install --agent copilot` copies them to `.github/skills/` of an app or game project).
|
|
|
|
These rules apply to every AI tool that uses storebound (skills, MCP server or the CLI in a terminal).
|
|
|
|
## First rule: do it, don't ask
|
|
|
|
storebound plus you, the AI agent, do the work. The owner is not your pair of hands.
|
|
|
|
1. **You do everything yourself:** API calls, uploads, builds, template and CSV downloads and exports, every console
|
|
navigation (open, Get Started, Edit, Next, Continue, Save draft), console forms, and the verification afterwards.
|
|
Never tell the owner "run this yourself" or "click X yourself" for any of these.
|
|
2. **The owner keeps only the final public or irreversible buttons:** Submit for review (App Review or Beta App
|
|
Review), releasing a version or completing / resuming a production rollout, App Privacy Publish, accepting legal
|
|
agreements; plus deleting store data, changing live prices, sending review replies and inviting or removing
|
|
testers. (Also the owner's: canceling a submission, starting or stopping a store experiment, a console form's final
|
|
Submit / Create that a console plan lists in `buttons.final`, signing in and granting account permissions.) For
|
|
these you prepare everything, show the dry run, and the owner presses one button or says yes.
|
|
**Updates are agent steps:** a new version of an app that is already on the store (Play: the production track holds
|
|
a published release; App Store: a version of the platform is or was on sale) is yours end to end, no owner gate
|
|
per update: `storebound play release <aab> --production completed --yes`, `storebound play upload --track
|
|
production --yes`, `storebound apple submit --build <n> --yes`, `storebound apple release --manual-release --yes`
|
|
(docs/bypass.md). Only the **first-ever release** of an app stays the owner's (exit 3 `OWNER_STEP`: after the
|
|
owner's yes re-run with `--first-release`), plus removal from sale, live price changes and anything that costs money.
|
|
**Bypass mode** (`storebound settings bypass status`): when the owner turned it on, you run these owner steps too:
|
|
MCP `owner_step` (dry run first, then `dry_run: false`), `storebound api ... --yes --confirm <operationId>`, and
|
|
console plans' `buttons.final`. Say in one line what you pressed; every action is logged to
|
|
`.storebound/owner-actions.log`. Legal agreements, passwords and 2FA stay with the owner if your own rules say so.
|
|
3. **Ask the owner only for facts that no code, config or doc can prove:** compliance answers such as Data safety,
|
|
App Privacy, age rating, export compliance, partial data deletion. Collect ALL of them in ONE batch at the start
|
|
(`storebound check` and `storebound validate` list them), never one at a time during the run. Reuse answers that
|
|
are already in the config.
|
|
4. **Default loop:** plan, then you drive (the API first, your browser tool for consoles without an API), then verify
|
|
(read it back), then continue. No round trip to the owner in between.
|
|
5. **Catch rejections offline.** Before a write, `storebound check` and `--dry` must catch what the store would refuse
|
|
(live-shape fixtures, id and pair checks). A failure belongs in the dry run, not in a 400 at write time; when a
|
|
store refuses something the dry run passed, fix the check (pitfalls), not just the data.
|
|
|
|
Every hour of "please click this" is an hour the owner did not want to spend. If you catch yourself writing "you
|
|
need to ...", do it instead, unless it is one of the owner steps in point 2.
|
|
|
|
## The other rules
|
|
|
|
**Read `skills/store-pitfalls/SKILL.md` before any store task.** It lists the mistakes already made in real releases
|
|
(store lists that lag after a create, dry runs without a plan, taken App Store names, byte limits, ...) and what to do.
|
|
|
|
1. **The owner presses only the owner steps** (point 2 of the first rule). Prepare them completely, say what will
|
|
happen, and let the owner press the button, or run the command only after a clear yes in chat. storebound's MCP
|
|
server does not offer these at all. Everything else you run yourself.
|
|
2. **Dry run first, then run it yourself.** Every write command has `--dry` (MCP: `dry_run`, default true). Run the
|
|
dry run, check and show it (the rows that change, not just a count), then run the real command yourself (`--yes`
|
|
where it asks for a confirmation) and read the result back. Wait for the owner's yes only before an owner step.
|
|
3. **Read before you write.** `storebound scan` (offline: rejection risks in the project itself), `storebound check`
|
|
(offline) and `storebound validate` (read-only, both stores) tell you what is missing and in which order to fix it.
|
|
4. **Credentials only from the environment, `.storebound/`** in the project (gitignored) **or a credential profile**
|
|
(`~/.storebound/credentials/<profile>.json`, named by `--account <profile>` or a workspace). Never ask for keys,
|
|
passwords or tokens in chat, never print them, never write them into the config, docs or commits. The same goes
|
|
for the App Review demo account (`reviewDemoAccount` in `.storebound/credentials.json`): the owner puts it there.
|
|
5. **Never answer a compliance question you cannot know.** Export compliance, Data safety, App Privacy, age rating,
|
|
target audience: ask the owner when the code does not prove the answer, all such questions in one batch at the
|
|
start (first rule, point 3), and write the answers into the config. A wrong "no" is worse than a slow "ask".
|
|
6. **Pick builds by explicit number.** Use the build number / versionCode you just uploaded, never "the latest".
|
|
7. **Long uploads run in the background with a log** (`storebound play images > .storebound/images.log 2>&1 &`) and
|
|
you report the progress lines, not guesses.
|
|
8. **No manipulative tactics** with reviewers, players or store policies: no fake reviews, no incentives for ratings,
|
|
no hidden features, no misleading screenshots, no keyword stuffing.
|
|
9. **Personal data stays local.** Tester lists, review reply drafts, health reports and analytics snapshots live in
|
|
`.storebound/` (gitignored). Never put tester emails, reviewer names or crash logs into issues, docs or commits,
|
|
and never ask for tester emails in chat (storebound masks them in its output).
|
|
10. **Console forms without an API: drive them yourself, agent-first.** `storebound console plan <form> --json` (MCP
|
|
`console_plan`) gives the start URL, steps, the answer sheet, the buttons you must never press and the verified UI
|
|
facts. Drive the page with your own browser tool, adapt to what it shows, run long flows as an in-page async loop
|
|
that writes `window.__log` (one evaluate call times out around 45 s), stop only before the final button (Publish,
|
|
Submit, Create, a final Save) and tell the owner exactly what to press, then `storebound console verify <form>`.
|
|
Never sign in, accept an agreement or grant a permission (a service account's app access) for the owner.
|
|
`storebound console fill` is the optional scripted fast path; it never blocks you.
|
|
11. **Console pages: always the absolute deep link.** When you send the owner to a console page, give the absolute
|
|
deep link (storebound prints it; `storebound console plan` has start URLs), never just "go to App Store Connect"
|
|
or "App Store Connect > App Information" alone.
|
|
|
|
## Tools
|
|
|
|
- CLI: `storebound <command>` (`storebound help`; outside the plugin: `npx storebound` on Node 20+ or `bunx storebound` on Bun); config `storebound.config.ts`, credentials in env or `.storebound/`.
|
|
- MCP: `storebound mcp` (stdio). MCP 2026-07-28 + 2025-11-25. Write tools default to `dry_run: true`; submit / release / cancel / delete / send are not exposed.
|
|
- Readiness: `storebound scan` (offline rejection risks in the project files), `storebound check` (offline), `storebound validate` (read-only, both stores).
|
|
- Every endpoint: `storebound api apple|play <operationId>` (skill store-api). GETs run; writes are dry unless the owner adds `--yes` in a terminal; MCP has the read-only `api_get`.
|
|
|
|
## Skills
|
|
|
|
| skill | for |
|
|
|---|---|
|
|
| `account-deletion` | Make account deletion pass App Store and Google Play review for an app with sign-up or sign-in |
|
|
| `adhoc-distribution` | Get a test build of a mobile app or game onto specific devices without a store review |
|
|
| `ads-levelplay-checks` | Renamed to ads-mediation-checks (AdMob, AppLovin MAX and Unity LevelPlay / ironSource). Kept so existing installs and links keep working. Use ads-mediation-checks for any ad mediation, app-ads.txt, SKAdNetwork or "no fill" question |
|
|
| `ads-mediation-checks` | Diagnose and verify ad mediation in a mobile app or game before and after store release |
|
|
| `app-icons` | Generate every icon a mobile app or game needs from one artwork |
|
|
| `app-previews` | Make App Store app preview videos and a Google Play promo video for a mobile app or game from real footage (gameplay or app flows) |
|
|
| `app-store-promotion` | App Store promotion tools for a mobile app or game through the App Store Connect API |
|
|
| `apple-ads` | Read Apple Ads (formerly Apple Search Ads) results for a mobile app or game and make small, owner-approved bid, daily budget and pause changes |
|
|
| `appstore-first-release` | Step-by-step first (and later) App Store release of a mobile app or game |
|
|
| `aso-basics` | App store optimization basics for a mobile app's or game's text |
|
|
| `build-and-sign` | Sign, build and upload a mobile app or game from the terminal |
|
|
| `console-autofill` | Fill App Store Connect and Google Play Console forms that have no API (New App, App Privacy, Play Create app, IARC content rating, every Play App content card, Play Store settings category, first production release countries and send-for-review). Agent-first by default |
|
|
| `export-compliance` | Answer App Store export compliance (encryption) for a mobile app or game correctly |
|
|
| `game-services` | Set up Game Center (App Store) and Play Games Services (Google Play) for a mobile game from one config section |
|
|
| `listing-localization` | Translate the store listing of a mobile app or game into more languages |
|
|
| `migrate-from-fastlane` | Move a mobile app or game from fastlane (deliver, supply, snapshot / screengrab, Appfile, Deliverfile) to storebound with `storebound import fastlane` |
|
|
| `play-first-release` | Step-by-step first (and later) Google Play release of a mobile app or game |
|
|
| `portfolio-originality` | Originality gate for studios and developers that ship many similar mobile apps or games (templates, white-label apps, reskins) |
|
|
| `ppp-pricing` | Propose purchasing power parity (PPP) prices for a mobile app's or game's in-app products in every App Store territory and Google Play region with `storebound prices ppp` |
|
|
| `privacy-manifest` | Add and check Apple privacy manifests (PrivacyInfo.xcprivacy) for an iOS app or game |
|
|
| `privacy-policy` | Write and host one studio-wide privacy policy page for all of a developer's mobile apps and games |
|
|
| `release-flows` | Repo-local workflows for a mobile app or game |
|
|
| `release-management` | Ship updates safely after the first release |
|
|
| `revenuecat-sync` | Optional adapter that keeps a RevenueCat project's catalog in step with the storebound config |
|
|
| `review-access` | Give App Store and Google Play reviewers working access to an app behind a sign-in |
|
|
| `review-rejections` | Triage and answer an App Store or Google Play rejection, policy warning or strike for a mobile app or game |
|
|
| `review-replies` | Reply to App Store and Google Play reviews of a mobile app or game the safe way |
|
|
| `store-analytics` | Take store analytics snapshots for a mobile app or game (App Store impressions, product page views, downloads and conversion through the Analytics Reports API; Google Play store listing visitors, acquisitions and installs from the Play reports bucket) and compare them with listing, screenshot and experiment changes from git; download App Store sales / finance reports and Play earnings / sales reports with a summary per product and currency |
|
|
| `store-api` | Call any App Store Connect API or Google Play Developer API operation that storebound's commands do not wrap, safely |
|
|
| `store-declarations` | Answer the store compliance forms for a mobile app or game |
|
|
| `store-health` | Watch a released mobile app's or game's crash and ANR health on both stores |
|
|
| `store-iap-setup` | Create and price in-app purchases (consumables, non-consumables like "remove ads" or a Pro unlock, non-renewing passes, coin/gem packs, starter packs) on Google Play and App Store Connect from one product list |
|
|
| `store-pitfalls` | Known pitfalls with App Store Connect, Google Play and storebound itself, learned from real releases, and what to do about each |
|
|
| `store-preflight` | Run and read the storebound readiness checks before submitting a mobile app or game |
|
|
| `store-screenshots` | Produce store screenshots and the Play feature graphic for a mobile app or game in every required size and many languages |
|
|
| `store-subscriptions` | Set up auto-renewable subscriptions on the App Store and Google Play from one config |
|
|
| `testflight` | Run TestFlight for a mobile app or game through the App Store Connect API |
|
|
| `web-presence` | Set up the web side of a mobile app or game |
|
|
| `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 |
|