Mobile Submission

Prefer the CLIs for most tasks and fall back to browser automation only when necessary:

• App Store Connect asc (references/apple.md)
• Google Play gplay (references/google.md).

Fetch the state from the store (asc status, gplay status) and trust what it says over anything written down earlier.

Store screenshots and media are their own workflow. For any screenshot, branded composite, icon, feature graphic, preview, or rejected/stale listing-media work, load mobile-screenshots through Skillbox (skillbox fetch mobile-screenshots) and follow it before uploading. Captures must come from the build being submitted; never substitute a mockup for a state the app cannot reach.

Discovery

Starting points: bundle ID and package name, framework and build system, permissions and their purpose strings, auth and account deletion, payments, UGC/AI surfaces, privacy/support/terms URLs, existing store assets; let what you find lead the rest. Then judge the app the way a reviewer will, against the current official policy pages (App Review Guidelines, Play policy center) for the app's actual risk surfaces — payments, kids, health, UGC, AI, tracking — not a generic checklist. Report what would likely get it rejected and fix with the user's approval before spending time on store plumbing. Then work through records, listing, build, upload, testing, and submission per the store references.

For a first release, missing store records, declarations, listing fields, review assets, and testing-track setup are expected prerequisites, not blockers. Complete them through the authorized CLI or browser. “Web-only” identifies the execution route; it is not a blocker when an authorized browser session exists. Reserve a human blocker for missing credentials or legal authority, a product decision, a human-only attestation, or an unavailable service.

Listing

Follow references/store-listing.md for positioning, titles, descriptions, and claims.