Update to App Builder

{
  "description": "Designs sign-up and sign-in flows for an app: email, passwordless, phone and social sign-in, guest mode, form fields and error messages, password reset, verification, waitlists and the copy that keeps people from dropping off.",
  "included_files": [],
  "name": "signup-login",
  "skill_md_contents": "---\nname: signup-login\ndescription: \"Designs sign-up and sign-in flows for an app: email, passwordless, phone and social sign-in, guest mode, form fields and error messages, password reset, verification, waitlists and the copy that keeps people from dropping off.\"\n---\n\n# Sign-up and Sign-in\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\nDesign sign-up and sign-in flows people finish: the right sign-in options, the fewest fields, clear rules and errors, password reset, verification, guest mode and a waitlist for apps not launched yet. Deliver the flow as numbered steps, screen copy, an error message table and security notes.\n\n## Before you start\n\n- Note the platform, what the account is for (sync, purchases, social features, sensitive data), the audience and the authentication provider, if chosen.\n- Ask at most 2 short questions, only when the answer changes the flow (usually whether an account is needed before use, or which platforms). Otherwise assume, state it in one line and write.\n- Reply in the user's language.\n\n## Choose the sign-in options\n\n| Option | Best for | Notes |\n|---|---|---|\n| Sign in with Apple | iPhone users | People can hide their email behind a relay address; name and email arrive only on the first sign-in, so save them |\n| Google sign-in | Android and web | On Android, use Credential Manager |\n| Email code or magic link | Most consumer apps | No password to forget; on phones a 6-digit code beats a link that opens in the wrong browser |\n| Email and password | Business tools, people without social accounts | Needs reset, rules and attempt limits |\n| Phone code (SMS) | Messaging, delivery, markets where the phone number is the ID | Each SMS costs money and attracts SMS fraud: limit sends per number and device |\n| Passkeys | Any app on current iOS, Android and browsers | Phishing-resistant; keep a fallback |\n\n- Consumer default: Sign in with Apple (iOS), Google and an email code. Business tools: email and password, with single sign-on later.\n- App Store guideline 4.8: an iOS app that offers Google or another third-party or social sign-in for the main account must also offer an equivalent privacy-focused option, such as Sign in with Apple. Email or phone sign-in alone does not trigger it, and there are exceptions (such as enterprise and education apps); tell the user to check the current guideline.\n- Use a proven authentication provider (for example Firebase Authentication, Supabase Auth, Auth0 or Clerk) instead of building sign-in.\n\n## Flow rules\n\n- Let people try first: guest mode or delayed sign-up, then \"Create an account to save your [plans]\" when there is something to save. Keep guest data and merge it into the new account.\n- Ask for the fewest fields: email or a social button first; name later, and only if used.\n- Show password rules before typing: \"At least [8] characters [confirm].\" Prefer length to symbol rules, and allow paste and password managers.\n- Add a show-password control with an accessible label (\"Show password\").\n- Set autofill types (email, new password, current password, one-time code) so phones fill fields in.\n- Errors appear next to the field and say how to fix it.\n- Password reset: enter email, get a one-time link or code that expires [confirm], set a new password, land signed in.\n- Verification: let people keep using the app, with a banner, a resend button after a short wait and \"Wrong email? Change it\".\n- Settings link to Delete account (required by both stores for apps with accounts).\n- Headlines name the benefit (\"Save your plan on every device\", not \"Register\") and buttons the result (\"Create account\", \"Continue with Apple\", \"Send my code\"). Never \"Submit\".\n- Lengths: headlines about 40 characters, labels 1 to 3 words, errors one sentence under about 80 characters, SMS within one segment (160 characters, or 70 once it contains emoji or scripts such as Hebrew or Arabic).\n\n## Error messages\n\n| Situation | Message | Fix |\n|---|---|---|\n| Email format | Enter an email like name@example.com. | Keep the text, focus the field |\n| Password too short | Use at least [8] characters. | Live rule check |\n| Wrong email or password | That email and password don't match. | Try again / Reset password |\n| Email already used (sign-up) | This email already has an account. | Sign in / Reset password |\n| Too many attempts | Too many tries. Wait [15] minutes or reset your password. | Reset password |\n| Code wrong or expired | That code didn't work or has expired. | Send a new code |\n| Offline | You're offline. Check your connection and try again. | Keep what they typed |\n\nOn sign-in and password reset, never reveal whether an email has an account: \"If an account exists for that email, we've sent a link.\" For sensitive apps (health, dating), handle sign-up the same way.\n\n## Waitlist (not launched yet)\n\nOne field (email), a clear promise and a confirmation. Headline: \"Be first to try [App]\". Line: \"One email when it launches [confirm].\" Button: \"Join the waitlist\". Confirmation: \"You're on the list. We'll email [email] when [App] is ready.\" No fake counts or queue positions. App Store pre-orders and Google Play pre-registration are store-side options.\n\n## Security notes\n\n- Never store plain-text passwords; the provider hashes them.\n- Limit sign-in and code attempts per account, device and IP address.\n- Use HTTPS for every request.\n- Keep session tokens in the Keychain or Keystore (for example expo-secure-store), or secure HTTP-only cookies on the web.\n- Ask people to sign in again before changing the email or password or deleting the account; after a reset, sign out other devices.\n- Never log passwords or codes, and keep secrets out of the app code.\n\n## Output format\n\n```text\nAssumptions: [one line]\nSign-in options: [list] | Provider: [name or recommendation]\n\nFLOW\n1. [Step]: [what the user sees and does]\n2. ...\n\nSCREEN COPY\n[Screen]: Headline / Line / Fields (label, type, helper) / Primary button / Secondary links\n\nERROR MESSAGES\n(table: Situation | Message | Fix)\n\nWAITLIST (if not launched)\nHeadline / Line / Field / Button / Confirmation\n\nSECURITY NOTES\n- ...\n```\n\n## Quality checks\n\n- Options fit the audience, and guideline 4.8 is respected on iOS.\n- People can try the app first where possible, and guest data is kept.\n- Sign-up asks for the fewest fields, shows password rules up front and has a show-password control.\n- Every error says what happened and how to fix it, without revealing at sign-in whether an account exists.\n- Reset, verification and the Delete account link are covered.\n- Security notes cover hashed passwords, attempt limits and HTTPS.\n- The waitlist has one field, a true promise and a confirmation.\n\n## Next step\n\nOffer onboarding-flow to design the first-run screens around this sign-up.\n"
}