App Store & Google Play agent prompts

Audit whether this app is ready to submit to the App Store and Google Play. Inspect my repository and build configuration, then read the current records in both connected store accounts. Change nothing — this is an audit.

Check at least:
- Version and build numbers: consistency between the repo, the uploaded builds, and each store record.
- Signing and identifiers: certificates, provisioning, app signing, bundle ID / package name, capabilities and entitlements.
- Uploaded artifacts: whether a valid build / app bundle exists and is processed and selectable.
- Metadata and localizations: every required field, in every language currently declared, per store.
- Screenshots and assets: required sizes and device classes, missing or stale assets, icons and graphics.
- Release notes: present, current, and appropriate per version or track.
- Pricing and availability: price, countries and regions, and anything unset.
- Testers, tracks, and TestFlight: track setup, tester groups, and anything half-configured.
- Agreements, tax, and banking status where it blocks submission.
- Policy and privacy forms: App Privacy, Data safety, content rating, and any declarations required.
- Review details: contact info, demo account, notes for the reviewer.
- Validation: run every read-only validation the APIs support and report each error and warning verbatim, plus what it means in plain English.

Then split the findings into two lists: (A) what you can fix or prepare yourself, and (B) what a human must decide, answer, or do in the console — with the exact question I need to answer for each item.

Finish with a prioritised plan: blockers first, then things that would get rejected, then improvements. Show effort and risk per item. Do not make any changes.

Take the audit you just produced and turn it into an ordered execution plan to get this app submitted.

For every step give me: what happens, why it is at that position, what it depends on (and what depends on it), the owner (agent / me / the platform), how the result will be verified, how it can be rolled back if it goes wrong, and whether it needs my explicit approval before you run it.

Mark every approval gate clearly and put one before anything that becomes public — submissions, releases, price or availability changes, and anything a store review would see.

Call out the steps only I can do (policy answers, agreements, account or payment setup, judgement calls) and put them where they actually unblock the sequence, not at the end.

Keep it in plain English, numbered, with a realistic idea of what is quick and what is slow. Do not start executing — present the plan and wait.

Research my app and propose better store metadata for both the App Store and Google Play. Do not apply anything yet.

First, research: read the app itself (repo, screens, features), my current listings on both stores, my website at [URL], and how comparable apps in [category] position themselves. Summarise in plain English what the app actually does, who it is for, and what makes it worth downloading.

Then propose, per store and per language: app name / title, subtitle or short description, full description, keywords where the store supports them, promotional text where supported, release notes for the current version, and the localizations I should have. Also propose an asset plan: which screenshots and previews to add, replace, or reorder, and what each one should show.

Constraints: stay inside each store’s current character and format limits — verify the limits from the official documentation rather than assuming — and keep my brand voice and product names intact. Make no claims the app cannot support.

Present it as: source used, rationale, character count against the limit for every field, and a clear before-and-after diff of each change. Flag anything you are unsure about. Wait for my approval before applying anything, and apply only the fields I approve.

Prepare a release-ready version of this app for [App Store / Google Play / both], version [x.y.z]. Get it to the point where a single human approval would submit it — and stop there.

Do the following, reporting after each step:
1. Verify the version and build numbers are correct and not already used.
2. Build or select the correct artifact, validate it, and upload it if needed. Confirm it finished processing and is selectable.
3. Associate the artifact with the version or release being prepared.
4. Apply the metadata, localizations, screenshots and release notes I already approved.
5. Configure distribution as requested: [TestFlight groups / Play track: internal, closed, open, production] and any testers or staged rollout percentage I specified.
6. Run every validation the APIs support, including Google Play edit validation, and report every error and warning verbatim with a plain-English explanation and a proposed fix.

Then present: a final submission checklist with each item marked ready or blocked, a complete diff of everything you changed, and anything still waiting on me.

Do not submit for review, do not commit a release to production, and do not make the app public. Wait for my explicit approval.

I approve submitting version [x.y.z] to [App Store / Google Play / both], exactly as shown in the checklist and diff you presented — nothing else changed.

Submit the approved version or commit the approved edit now. Do not enable automatic release to the public: keep release control manual unless I separately approve automatic release. If a staged rollout is configured, do not increase the rollout percentage without asking me first.

After submitting, confirm what was submitted and monitor the status. Report every state change in plain English. If anything fails, is rejected, or comes back with reviewer questions, give me the exact error or rejection text, what it means, what caused it, and a specific remediation plan with the changes you would make — then wait for my approval before acting on it.

Monitor this app on both stores and report to me. Read-only unless I approve an action.

Report: the current state of every version, build, edit, track and rollout; where each one sits in review or release; and anything that has changed since your last report.

Where the APIs support it, also read customer reviews and ratings. Summarise what users are actually saying, separate noise from actionable feedback, and group the actionable items into bugs, missing features, confusion about how the app works, and store-listing problems.

For each actionable item, propose one of: a draft reply to the review, a specific product or code fix, or a listing change that would prevent the confusion. Show me the drafts and the reasoning.

Do not publish any reply, apply any fix, or change any listing until I approve it, item by item. Be clear when something is not available through the API and would have to be done in the console by me.

Something looks wrong. Do not make further changes until I tell you to.

First, show me exactly what changed: every field, asset, release, track and setting you touched in the last [time period or session], with before-and-after values and timestamps. Then read the current live state from both stores and tell me where it differs from what I approved.

Next, tell me for each unwanted change whether it can be reverted through the API, whether it must be reverted in the console by me, or whether it cannot be undone at all (for example, something already public or already reviewed) — and what the safest mitigation is in that case.

Propose a specific rollback for each item and wait for my approval before applying any of it. After I approve and you apply it, read the live state back and confirm it matches.

Finally, explain step by step exactly how I revoke your access to each store right now, in the console, including where to click — and what happens to any in-flight work when I do.