Update to App Builder

{
  "description": "Reviews an existing mobile or web app from its screenshots, code, screen descriptions or store listing: first impression, onboarding, navigation, core flow, accessibility, trust, monetization and store readiness. Returns a scorecard, a prioritized fix list and a rewritten first screen. 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": "app-audit",
  "skill_md_contents": "---\nname: app-audit\ndescription: \"Reviews an existing mobile or web app from its screenshots, code, screen descriptions or store listing: first impression, onboarding, navigation, core flow, accessibility, trust, monetization and store readiness. Returns a scorecard, a prioritized fix list and a rewritten first screen. 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# App Audit\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## 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\nReview an existing app the way a new user and a store reviewer meet it, and tell the owner what to fix first. Deliver a scorecard across 8 areas (1 to 5, each with one line of evidence), the top 5 fixes ranked by impact and effort, a rewritten first screen and quick wins, for iPhone, Android or web apps.\n\n## Before you start\n- Work only from what the user shares: screenshots, a screen recording described in words, code, screen descriptions or listing text. You cannot open links or install apps; given only a link, ask for the listing text and screenshots of the first screens (welcome, sign-up, home, main task, paywall).\n- Audit the new user's path from first launch to the first success, and list the rest as not reviewed.\n- Screenshots cannot show speed, crashes, screen reader labels or text scaling: judge speed and stability only from what the user reports.\n- Ask at most 2 questions, only when the material does not answer them: \"What is the one main action users should take?\" and \"Who is your ideal user?\" Otherwise infer, state the assumption in one line and proceed. Reply in the user's language.\n\n## The 8 areas\n| Area | What to judge |\n|---|---|\n| First impression | Five-second test on the first screen (what it is, who it is for, what to do next); consistent type, colors and spacing; no placeholder text |\n| Onboarding | Screens before any value, sign-up timing, field count, permission requests without a reason, a way to skip |\n| Navigation | 3 to 5 labeled destinations, the main action easy to reach, predictable back behavior, platform conventions |\n| Core flow | Taps to the first success, defaults, empty, loading and error states, reported speed, reasons to return (saved progress, opt-in reminders) |\n| Accessibility | Contrast at least 4.5:1, tap targets at least 44 by 44 points (iOS) and 48 by 48 dp (Android), labels on icon buttons for VoiceOver and TalkBack, text that grows with the system font size, nothing shown by color alone |\n| Trust | Permissions asked at the moment of use with a reason, privacy policy in the app, in-app account deletion when accounts exist, visible support, honest claims |\n| Monetization | Paywall after people see value; price, period, trial end and renewal stated plainly, the billed amount most prominent; Restore purchases; an easy close button. \"Not applicable\" for a free app without ads |\n| Store readiness | Listing clarity and limits, plus the review risks below. For a web app: HTTPS, title and meta description, installability |\n\nCommon review risks: crashes or placeholder content; login with no demo account; digital features sold outside in-app purchase; a website in a wrapper with little app value (App Store guideline 4.2); Google or other social sign-in on iOS without an equivalent privacy-focused option such as Sign in with Apple (guideline 4.8); no account deletion; other platforms named in App Store text; \"#1\" or \"best\" claims on Google Play. Rules change: present these as risks and tell the user to check the current guidelines.\n\n## Scoring\n- 5: strong. 4: minor polish. 3: works, with friction users will feel. 2: problems that cost users or risk rejection. 1: broken or blocking.\n- Each score gets one line of evidence pointing to the material (a screen, button text, a line of code). Where the material does not show an area, write \"Not judged\"; never guess. Contrast and sizes read from screenshots are estimates: say so.\n- An unanswered five-second question caps first impression at 3; a likely rejection reason caps store readiness at 2.\n\n## Listing results\nWhen the user shares listing text, run the listing checker as described in Check the listing above: one call per store, with store set to app_store or google_play and only the fields the user gave, as plain text (App Store: name, subtitle, keywords, promotional_text, description, whats_new; Google Play: name, short_description, description, whats_new), plus target_keywords if the user named the searches they want to win and company_name if known. Fold its scores and top issues into the store readiness row and treat its high-priority issues as candidate fixes. Without listing text, say the listing was not checked.\n\n## Fixes and the first screen\n- Rank fixes by impact (activation, conversion, retention, ratings or approval), then effort (minutes, hours, days). Anything blocking approval or the core flow outranks polish. Each fix names the screen, the change and the expected effect.\n- Rewrite the first screen from facts in the material only; mark anything new [confirm]. Headline: the user's outcome in under 8 words, never \"Welcome to [App]\". Subheadline: who it is for and how it works, in one sentence. Button: a verb plus the result, never \"Next\", with an optional \"I already have an account\".\n- Weak: \"Welcome to Billy / The smart way to manage money / Next\". Strong: \"Never miss a bill again / Add your bills once and get a reminder before each is due / Add my first bill\".\n- Quick wins: 3 to 6 fixes under an hour each (button text, a reason line before a permission prompt, icon button labels, Restore purchases).\n\n## Output format\n```text\nAssumptions: [one line]\nApp: [name] | Platform: [iOS / Android / web] | Material: [what was shared]\nListing checker: [store]: [scores, number of issues] | not run: no listing text\n\nScorecard\n| Area | Score (1 to 5) | Evidence |\n| First impression | [n] | [one line pointing to a screen, text or code] |\n(all 8 areas, or \"Not judged\")\n\nTop 5 fixes\n| # | Fix (screen and change) | Why it matters | Impact | Effort |\n\nRewritten first screen\nHeadline: [text]\nSubheadline: [text]\nButton: [text] | Secondary: [text]\n\nQuick wins (under an hour each)\n- [fix]\n\nCould not judge from this material\n- [item]: [what would show it, such as crash reports or a large-text screenshot]\n```\n\n## Quality checks\n- All 8 areas appear, each with app-specific evidence or \"Not judged\".\n- The listing checker ran whenever listing text was shared, and its results shape store readiness.\n- Fixes are ranked by impact, then effort, and each can be acted on today.\n- Accessibility is judged against 4.5:1 contrast and 44 point and 48 dp targets.\n- The new first screen passes the five-second test and adds nothing without [confirm].\n- What you could not judge is listed.\n\n## Next step\nOffer onboarding-flow to rebuild the first run around these fixes, listing-rewrite for the store page, or app-editor to apply the fixes to the code.\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"
}