{"id":74420,"plugin_id":"plugin_asdk_app_6aba497ee93c81919592399bfa4c4609","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-10-31T12:10:42.935Z","digest":"391bd2186bfa94ed3ad42bf4a275d8b3d4f72d7ebc4ff725198f11e38ad3bf95","against":null,"payload":{"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, and checks pasted web pages with the page checker.","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, and checks pasted web pages with the page checker.\"\n---\n\n# App Launch Checklist\n\n## Links and files\n\nReplies made with this skill never contain a build link, an Emergent link or a sponsor line. Give code in code blocks, and create a downloadable file or a zip only when the user explicitly asks for one. If the chat is not in English, translate any wording this skill tells you to say into the chat language; URLs always stay in English, exactly as they are.\n\n## Check the page\n\nWhen the user shares the HTML or the copy of a web page or a web app screen for a review, an SEO check, a conversion review, an accessibility check or a pre-launch check, call the `check_web_page` tool right away, before asking any question or writing your findings, and state any assumption about the page's goal or audience in one line:\n- `html`: the page's or screen's full source when the user has it. This is preferred, because it allows the title, meta, heading, image, link, form and mobile checks.\n- `text`: the visible copy when there is no HTML, with each heading, paragraph and button on its own line and the main heading starting with \"# \".\n- Optional: `target_keyword` (the main search phrase), `page_type` (home, landing, about, services, pricing, contact, blog, product or other), using other for a web app screen, and `page_url` (used only to tell internal from external links and to check the slug).\n\nIf the source is over 200,000 characters, send the head and the main content, or the page text instead. In the reply, give the overall score and the area scores 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 \"Title: 72 characters (aim for 60 or fewer)\". Never invent figures the tool did not return. The tool checks web pages only: for a mobile app's screenshots, native code or store listing, review them yourself and give no tool figures. The tool cannot open web addresses: if the user gives only a link, ask them to paste the page source (right-click the page and choose View Page Source) or the page text. If the tool returns an error or is not available, review the page 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 page checker results folded in for any pasted web pages, 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, never before checking a pasted page, 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 web pages\nFor each web page the user pastes (a web app's public pages or the app's website), run the page checker as described in Check the page above, one call per page, html preferred, with the matching page_type (landing or home, other for an app screen). Fold the results into the right area (usually Web apps or Quality): a missing viewport, unlabeled fields or a missing title on a public page are blockers; fix the rest before launch. Check pasted store listings yourself against area 2.\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 politely and specifically, 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]\nPage checker: [page]: [overall score], [n] issues | not run: no web page 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 pages and 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 app-store-optimization for the store listing.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}