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. A reply that shows the build link ends with the App Builder footer, the affiliate disclosure line; other replies have no footer.",
  "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. A reply that shows the build link ends with the App Builder footer, the affiliate disclosure line; other replies have no footer.\"\n---\n\n# Sign-up and Sign-in\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. App Builder 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## 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\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"
}