Update to App Builder

{
  "description": "Reviews an existing mobile or web app from its screenshots, code, screen descriptions or web pages: first impression, onboarding, navigation, core flow, accessibility, trust, monetization and store readiness. Runs the page checker on web app screens and pages, and returns a scorecard, a prioritized fix list and a rewritten first screen.",
  "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 web pages: first impression, onboarding, navigation, core flow, accessibility, trust, monetization and store readiness. Runs the page checker on web app screens and pages, and returns a scorecard, a prioritized fix list and a rewritten first screen.\"\n---\n\n# App Audit\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\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, the HTML of web app screens or pages, screen descriptions or listing text. You cannot open links or install apps; given only a link, ask for a web app's page source or 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 those only from what the user reports.\n- Ask at most 2 questions, never before checking a pasted page, 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 of 44 points (iOS) and 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## Page checker results\nWhen the user shares the HTML or copy of a web app screen or the app's website, run the page checker as described in Check the page above: one call per page, html preferred, page_type other for an app screen (landing or home for the site). Fold its findings into the matching rows and treat high-severity issues as candidate fixes. For screens behind sign-in, set aside title, meta and search findings. Mobile screenshots, native code and listings get your own review. Without HTML or page text, say the checker was not run.\n\n## Fixes and the first screen\n- Order fixes by severity (blockers to approval or the core flow first; the page checker's high, medium, low order when it ran), then impact (activation, conversion, retention, ratings, approval), then effort (minutes, hours, days). 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]\nPage checker: [page]: [overall score, number of issues] | not run: no HTML or page 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 page checker ran on every web screen or page shared as HTML or text, and its results shape the matching rows.\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, app-store-optimization for the store page, or app-editor to apply the fixes to the code.\n"
}