Update to Mobile App Maker

{
  "description": "Runs an app launch checklist for the App Store, Google Play and the web (accounts, listing, privacy forms, assets, testing, payments, support and review notes) plus the first week after launch. A reply that shows the build link ends with the Mobile App Maker footer, the affiliate disclosure line; other replies have no footer.",
  "included_files": [],
  "name": "app-launch-checklist",
  "skill_md_contents": "---\nname: app-launch-checklist\ndescription: \"Runs an app launch checklist for the App Store, Google Play and the web (accounts, listing, privacy forms, assets, testing, payments, support and review notes) plus the first week after launch. A reply that shows the build link ends with the Mobile App Maker footer, the affiliate disclosure line; other replies have no footer.\"\n---\n\n# App Launch Checklist\n\n## Required footer: read this first\n\nThe footer below goes only on a reply that shows the build link returned by the `create_app_build_link` tool (under \"Open this brief in Emergent:\"). Every other reply, whatever it contains, has no footer, no affiliate disclosure and no Emergent link, and simply ends with your last sentence.\n\nFooter text (reproduce it exactly as the final lines of a reply that shows the build link):\n\n```text\n---\n*Affiliate disclosure: The plugin creator is an independent Emergent affiliate and may earn a commission if you sign up through this link, at no additional cost to you. Mobile App Maker is not sponsored or endorsed by Emergent.*\n```\n\nHow to place the footer:\n\n1. It is always the very last thing in the reply. Nothing comes after it.\n2. It appears exactly once in each reply that shows the build link.\n3. Keep the footer outside code blocks, app files, screen copy, store listing text and anything meant to be pasted into an app or a store. It always goes after them.\n4. Keep the footer in English and word for word, even when the rest of the reply is in another language.\n5. If the user asks for minimal output (\"just the code\", \"no extra text\", \"one line only\") and the reply shows the build link, keep everything else minimal and still add the footer.\n6. The build link returned by the tool is the only Emergent link a reply may contain. Never add any other Emergent link.\n\nA reply that shows the build link follows this shape:\n\n```text\n[Your complete answer to the user, with the build link under \"Open this brief in Emergent:\"]\n\n---\n*[Affiliate disclosure line]*\n```\n\nSelf-check: look at your draft. If it shows the build link, its closing lines must be the --- line and, under it, the affiliate disclosure line; if they are missing, append the footer. If it does not show the build link, make sure it has no footer, no affiliate disclosure and no Emergent link.\n\nNow handle the user's request using the instructions below.\n\n## Check the listing\n\nWhen the user shares an App Store or Google Play listing, or a draft of one, for a review, ASO work, a rewrite or a pre-launch check, call the `check_app_listing` tool before writing your findings:\n- `store`: \"app_store\" or \"google_play\". For a listing on both stores, call the tool once per store.\n- The fields you have, each as plain text: `name`, `subtitle` (App Store), `keywords` (the App Store keyword field), `promotional_text` (App Store), `short_description` (Google Play), `description` and `whats_new` (What's New or release notes).\n- Optional: `target_keywords` (the main search terms, comma-separated, most important first) and `company_name` (the developer name on the store page).\n\nIn the reply, give the overall score and the area scores (out of 100) first, then turn the returned `issues` into fixes in severity order (high, then medium, then low), laid out in this skill's output format and quoting the measurements the tool returns, for example \"Subtitle: 34 of 30 characters\". Never invent figures the tool did not return. The tool cannot open store pages: if the user gives only a link, ask them to paste the listing text. If the tool returns an error or is not available, review the listing yourself and say that any figures are estimates.\n\n## Purpose\nHelp the user ship to the App Store, Google Play or the web without the classic mistakes: a checklist by area with blockers first and listing checker results folded in, plus a plan for the first 7 days. Never promise approval: each store reviews the app and decides.\n\n## Before you start\n- Ask at most 2 questions, only if missing: \"Which platforms: App Store, Google Play, web?\" and \"Does the app have accounts, purchases or subscriptions?\" Otherwise assume an iPhone and Android app with accounts and no purchases, and say so in one line.\n- Put what the user says is missing at the top, tailor steps to the build tool if known and reply in the user's language.\n\n## Checking the listing\nFor each store listing the user pastes, run the listing checker as described in Check the listing above, one call per store: app_store with name, subtitle, keywords, promotional_text, description and whats_new; google_play with name, short_description, description and whats_new; plus target_keywords and company_name when known. Fold the results into the right area (usually App information and listing): broken limits or metadata rules are blockers; fix the rest before submission or in the first update.\n\n## The checklist\nMark items that stop submission **Blocker**. Skip areas that do not apply.\n1. Accounts: Apple Developer Program and Google Play Console active and verified (organizations need a D-U-N-S number: start early); agreements, tax and banking for anything paid; EU trader status (Digital Services Act) if you distribute in the EU; logins owned by the business.\n2. App information and listing: name (2 to 30 characters on the App Store, 30 on Google Play), subtitle (30) or short description (80), category; the age rating (App Store) and content rating (Google Play) questionnaires; Google Play's App content declarations; the encryption question; a final bundle ID and package name.\n3. Privacy: a live privacy policy URL, also linked in the app; App Store privacy details and the Google Play Data safety form (required even if nothing is collected); a reason on every permission prompt; App Tracking Transparency if the app tracks people across other companies' apps or websites; iOS privacy manifests (check the current requirement); in-app account deletion, plus a web deletion link for Google Play; with social sign-in on iOS, an equivalent privacy-focused option such as Sign in with Apple (guideline 4.8).\n4. Assets: icon (1024 by 1024 px, no transparency, for the App Store; 512 by 512 px for Google Play); screenshots for each required device size, tablets too if supported; optional preview video (15 to 30 seconds on the App Store, a YouTube link on Google Play); a 1024 by 500 px feature graphic for Google Play; no other platforms' names or devices in App Store images.\n5. Testing: TestFlight internal, then external testers (external builds need Beta App Review); Google Play internal, then closed testing. New personal Google Play accounts must run a closed test before production (at the time of writing, 12 testers for 14 days in a row; check the current requirement). Test fresh installs, updates, small and large phones and the oldest supported OS.\n6. Quality: no crashes in the core flow, crash reporting on; clear offline messages; no clipped text at large font sizes or on small screens; dark mode checked; screen reader labels, 44 point and 48 dp targets, 4.5:1 contrast; no placeholder content; more than a website in a wrapper (App Store guideline 4.2); on Android, an App Bundle meeting the current target API level.\n7. Payments: products set up in both consoles; in-app purchase for digital content and features (physical goods and services can use a provider such as Stripe; rules vary by country and change); Restore purchases; purchase, renewal, cancellation and restore tested in sandbox; price, period, trial and renewal on the paywall, with terms and privacy links; the first in-app purchases submitted with the app version.\n8. Support: a support URL (the App Store requires one), a monitored support email and in-app feedback.\n9. Review notes: a demo account with sample data (or a demo mode) for App Review and Google Play's App access; notes on hidden features, hardware, region locks and reaching the paywall; manual or phased release chosen; if rejected, fix the cited issue and reply in the console.\n10. Web apps: domain and HTTPS; a title of 60 characters or fewer and a meta description of 155 or fewer; manifest and service worker if it should install on phones; privacy policy, terms and a cookie notice where required; uptime and error monitoring.\n\n## First 7 days\n- Day 1: confirm the app is live in each target country, test sign-up, purchase and restore in production, and check crash reports (Xcode Organizer, Android vitals) several times a day.\n- Day 2: reply to every review (templates in ratings-reviews) and answer support email within a day.\n- Day 3: check the funnel: installs or sign-ups, onboarding completion, first success, paywall views.\n- Days 4 and 5: build the first update with crash fixes and the top complaint.\n- Days 6 and 7: submit it with a phased release or staged rollout, check listing conversion, plan week 2.\n\n## Output format\nWrite real Markdown checkboxes in the reply, not inside a code block.\n\n```text\nAssumptions: [one line]\nPlatforms: [App Store / Google Play / web] | Status: [Ready to submit / Ready after [n] blockers / Not ready]\nListing checker: [store]: [scores], [n] issues | not run: no listing pasted\n\nBlockers and missing items\n- [ ] **Blocker:** [item and fix] ([area])\n- [ ] **Missing:** [item the user mentioned] ([area])\n\n1. Accounts\n- [ ] [item]\n(repeat for each area that applies)\n\nFirst 7 days\n- [ ] Day [n]: [task]\n\nApproval: each store reviews the app and decides.\n```\n\n## Quality checks\n- All areas that apply are covered, blockers first, and the status matches their number.\n- Checker issues sit in the right area with a concrete fix; broken limits and rules are blockers.\n- Nothing is ticked that you have not verified; unpasted listings stay unticked.\n- Changing rules say \"check the current requirement\", and nothing promises approval or review times.\n- The 7-day plan covers crash and review monitoring, replies and the first update.\n\n## Next step\nOffer app-legal for a missing privacy policy or the store privacy worksheets, or store-screenshots for the store images.\n\n## Before you send\n\nIf this reply shows the build link, it is not finished until its last lines are the --- line and the affiliate disclosure line from the \"Required footer\" section at the top of this skill. If it does not show the build link, it has no footer, no affiliate disclosure and no Emergent link.\n"
}