Update to App Builder

{
  "description": "Writes a conversion-focused first-run experience for an app: welcome screens, the value promise, sign-up timing, personalization questions, permission requests with clear reasons and the first success moment.",
  "included_files": [],
  "name": "onboarding-flow",
  "skill_md_contents": "---\nname: onboarding-flow\ndescription: \"Writes a conversion-focused first-run experience for an app: welcome screens, the value promise, sign-up timing, personalization questions, permission requests with clear reasons and the first success moment.\"\n---\n\n# Onboarding Flow\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## Purpose\n\nWrite the first-run experience that gets a new user to their first success fast: a welcome screen with a clear value promise, sign-up at the right moment, a few personalization questions, permission requests with honest reasons and the first success moment. Deliver screen-by-screen copy, permission texts, empty states and the metric to watch, for mobile and web apps.\n\n## Before you start\n\n- Note what the app does, who it is for, the platform, the first success (the moment of real value: first plan made, first expense logged), the permissions it truly needs and whether an account is required.\n- Ask at most 2 short questions, only when the answer changes the flow (usually the first success or whether an account is required). Otherwise assume, state the assumptions in one line at the top and write.\n- If the user pastes their current onboarding, keep every true fact, fix the friction and explain each change in one line.\n- Reply in the user's language.\n\n## Flow structure\n\n1. Welcome: a value promise in under 8 words, one supporting line, a primary button and \"I already have an account\".\n2. Value screens (0 to 3): only when the value is not obvious, one benefit each, shown with a real screen. Simple apps go straight into action; doing beats reading.\n3. Personalization (1 to 3 questions): only questions whose answers change what the user sees next. Large tappable options, a \"Not sure yet\" choice and one line on why you ask.\n4. First action: the user does the core task, one hint at a time.\n5. First success: name the result (\"Your first workout plan is ready\") and offer the next step.\n6. Sign-up: right after the first success, framed as saving it (\"Save your plan\"), with guest mode or \"Try it first\" as the alternative. It comes earlier only when the core feature needs an account. Apple's guidelines expect apps without significant account-based features to work without sign-in (check the current guideline 5.1.1).\n7. Permissions: when a feature needs them (reminders once a plan exists), each primed by your own screen (below).\n\nShow progress (dots or \"Step 2 of 4\") and a skip option on optional screens; skipping keeps sensible defaults.\n\n## Copy rules\n\n| Element | Length | Weak | Strong |\n|---|---|---|---|\n| Welcome headline | under 8 words | Welcome to [App] | Workouts that fit your week |\n| Other headlines | about 40 characters | Let's get started! | Pick your starting level |\n| Body | 2 short lines | Our AI personalizes everything. | Tell us your goal. We'll build the plan. |\n| Button | 2 to 4 words, verb plus result | Next, Submit | Start my plan |\n| Answer option | 1 to 4 words | Option A | Build strength |\n\n- Never \"Welcome to [App]\": the name is already on the icon. One idea per screen, \"you\" over \"we\", no feature names the user has not learned yet.\n- Weak question: \"How did you hear about us?\" (changes nothing). Strong: \"How many days a week can you train?\" (changes the schedule).\n- Accessible: text scales with the system font size, contrast at least 4.5:1, tap targets at least 44 by 44 points (iOS) and 48 by 48 dp (Android).\n\n## Permission requests\n\n- Ask in context: camera when the user taps \"Scan\", location when they open the map, notifications after they set a goal worth a reminder. Never all at launch.\n- Pre-prompt: a benefit headline, one line on why and what they control, a primary button (\"Turn on reminders\") and \"Not now\". Only the primary button opens the system dialog: iOS shows it once per permission, and Android stops showing it after repeated denials.\n- If denied, keep the feature working where possible and offer a quiet \"Turn on in Settings\" link. Never imitate the system dialog or reward people for allowing; before Apple's tracking prompt (App Tracking Transparency), keep the button neutral, such as \"Continue\".\n- iOS shows your usage description string inside the system dialog: NSCameraUsageDescription, NSLocationWhenInUseUsageDescription, NSPhotoLibraryUsageDescription, NSMicrophoneUsageDescription, NSHealthShareUsageDescription. Apple rejects vague strings. Weak: \"This app needs your camera.\" Strong: \"Scan a receipt to add an expense without typing.\" In Expo, set them under ios.infoPlist in app.json.\n- iOS notifications have no usage string and Android dialogs show no custom text, so the pre-prompt carries the reason. Android 13 and later asks for notification permission at runtime.\n- Ask for location \"while using the app\" first. Background location and health data carry extra store rules (Google Play's prominent disclosure, HealthKit, Health Connect); tell the user to check the current policies.\n\n## Empty states\n\nEach first screen that starts empty gets a headline saying what to do first, one line on the result and one button. Weak: \"No data.\" Strong: \"Your week is empty. Add a workout to see your plan.\" Button: \"Add a workout\".\n\n## Output format\n\n```text\nAssumptions: [one line]\nFirst success: [moment] | Screens before it: [n]\n\nSCREEN 1: [Name]\nHeadline:\nBody:\nPrimary button:\nSecondary action:\nProgress / Skip:\nNotes: [visual, what the answer changes]\n(repeat for each screen)\n\nPERMISSIONS\n[Permission], asked when: [moment]\nPre-prompt: Headline / Body / [primary] | Not now\niOS usage string ([key]):\nIf denied:\n\nEMPTY STATES\n[Screen]: Headline / Line / Button\n\nFIRST SUCCESS\nHeadline / Body / Primary / Secondary\n\nMETRIC TO WATCH\nActivation rate: share of new users who reach [first success] within [first day, confirm]\nAlso track: drop-off per screen, permission opt-in, time to first success\n```\n\nIf onboarding was pasted, add CHANGES: one line per change and why.\n\n## Quality checks\n\n- The welcome headline is a value promise under 8 words, never \"Welcome to [App]\".\n- Headlines are about 40 characters or fewer, bodies 2 short lines, buttons a verb plus a result.\n- Every personalization question changes the experience, and sign-up comes after value unless the core feature needs an account.\n- Every permission has a pre-prompt with a real reason, a \"Not now\" path, a fallback and, on iOS, a specific usage string.\n- Progress and skip are shown; text size, contrast and tap targets meet the minimums.\n- Pasted onboarding kept every true fact, with each change explained.\n- The reply names the first success and the activation metric.\n\n## Next step\n\nOffer signup-login to design the sign-up screens this flow leads to, or retention-notifications to bring new users back on day 2.\n"
}