Update to App Builder

{
  "description": "Rewrites an App Store or Google Play listing to turn more store visitors into installs: stronger name and subtitle, a description that leads with the promise, benefit-led features, real proof and screenshot captions, within store limits. 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": "listing-rewrite",
  "skill_md_contents": "---\nname: listing-rewrite\ndescription: \"Rewrites an App Store or Google Play listing to turn more store visitors into installs: stronger name and subtitle, a description that leads with the promise, benefit-led features, real proof and screenshot captions, within store limits. 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# Store Listing Rewrite\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\nTurn a store listing that gets views but too few installs into one that converts: measure it with the listing checker, diagnose what holds it back, rewrite the text around one clear promise, add captions for the first 3 screenshots, and show before and after with 2 tests for the stores' own experiments.\n\n## Before you start\n- Work from pasted text: the listing fields, or screenshots you transcribe. If the user only gives a store link, ask for the text; you cannot open links.\n- Ask at most 2 questions, only if the listing does not answer them: \"Which store and country is this for?\" and \"Which search keywords must it keep?\" Otherwise infer, state your assumptions in one line and proceed.\n- Keep every true fact: features, plans, names and numbers. Never invent ratings, review quotes, user counts, awards, press or deadlines. Mark new claims [confirm] and leave proof only the user can supply as [fill in].\n- Write the listing in the store's language and your notes in the user's language.\n\n## Step 1: Measure and diagnose\nBefore changing a word, run the listing checker as described in Check the listing above on the original. Send store, name and description, plus subtitle, keywords and promotional_text for app_store, or short_description for google_play; set target_keywords to the keywords the listing must keep and company_name to the developer name if known. Note the scores, then write 3 to 5 diagnosis bullets, each quoting the line that shows the problem:\n- Company-first or vague opening: \"Welcome to X, the all-in-one solution.\"\n- Buried promise: the first 2 lines do not say what the user gets.\n- Feature names instead of benefits, or a wall of text with no bullets.\n- No proof, or proof that breaks the rules (anonymous testimonials, \"#1\").\n- Limit and rule problems the checker reports.\n\n## Step 2: Rewrite\n- Name (30 characters): brand plus the main keyword. Keep the brand unless the user asks to change it.\n- Subtitle (App Store, 30) or short description (Google Play, 80): the core benefit with the main keyword, in words a user would say.\n- Description (4000): the first 2 lines carry the promise and the proof, because most people never tap \"more\". Then 4 to 7 benefit bullets (the benefit first, then the feature that delivers it), who it is for, real social proof and a closing line that invites the first step.\n- Proof must be real and attributed: a named press quote, an award with its source, or a review with the reviewer's name, used with permission. On Google Play, leave out anonymous testimonials, rankings and awards.\n- Promotional text (App Store, 170): current news such as a new feature or seasonal content. No fake urgency or countdowns.\n- Screenshot captions for the first 3 frames: 2 to 6 words each, benefits that echo the promise.\n- Keywords: keep the ones the listing ranks for in the same fields, so the rewrite does not lose search traffic; on the App Store, drop from the keyword field any word the new name or subtitle now holds.\n\n| Weak | Strong |\n|---|---|\n| The best fitness app! Download now! | Get stronger in 20 minutes a day, at home [confirm] |\n| Features: reminders, sync, widgets | Never miss a workout: reminders that fit your day |\n| \"Amazing app!!!\" (no name) | \"[fill in: real quote]\", [Name], [Source] |\n| Hurry, limited offer! | New: plans for complete beginners [confirm] |\n\nStore rules: no ranking, price or promotion claims, no unattributed testimonials, no keyword lists, no emoji or ALL CAPS in Google Play titles, no names of other platforms (Android, Google Play) in App Store metadata, and \"For Kids\" or \"For Children\" only in the App Store Kids category.\n\nTiming: App Store name, subtitle, keywords and description change with the next version; promotional text changes any time. Google Play listing edits go live without an app update, after review. Tell the user to confirm current limits in App Store Connect and Play Console.\n\nThen run the checker again on the new listing with the same fields and report before and after scores, noting that they measure limits and rules, not real install rates.\n\n## Step 3: Test ideas\n- App Store product page optimization tests the icon, screenshots and preview videos against the original, not the text; custom product pages let a link or ad open a version made for one audience.\n- Google Play store listing experiments test graphics and, per language, the short and full descriptions.\n- Give each test a hypothesis (\"If we [change], [audience] will install more because [reason]\"), change one element at a time and run it until the console reports a clear result. Tools change, so check what each one supports today.\n\n## Output format\n```text\nAssumptions: [store | country and language | keywords kept] (one line)\nChecker: before [score] | after [score] (limits and rules, not install rates)\n\nDIAGNOSIS\n- [Problem]: \"[quote]\". [Why it costs installs]\n\nBEFORE AND AFTER\n| Field | Before ([n] characters) | After ([n] characters) |\n| Name | | |\n| Subtitle or short description | | |\n| Description, first 2 lines | | |\n| Promotional text | | |\n\nNEW LISTING\nName ([n]/30 characters): [...]\nSubtitle ([n]/30) or short description ([n]/80 characters): [...]\nPromotional text ([n]/170 characters, App Store): [...]\nDescription ([n]/4000 characters):\n[Promise line]\n[Proof line]\n- [Benefit]: [feature that delivers it]\n[Who it is for] [Real, attributed proof] [Closing line]\n\nSCREENSHOT CAPTIONS\n1. [...] 2. [...] 3. [...]\n\nWHAT CHANGED AND WHY\n- [3 to 5 bullets]\n\nTESTS\n1. [Store tool]: [one change] | Hypothesis: [...]\n2. [Store tool]: [one change] | Hypothesis: [...]\n\nTo confirm or fill in: [list]\n```\n\n## Quality checks\n- The checker ran on the original first and on the rewrite after, and both scores are shown.\n- Every field fits its limit, with its count shown.\n- The first 2 description lines state the promise and a real proof point.\n- Features read as benefits; no keyword lists, claims, fake urgency or forbidden platform names.\n- Every true fact kept; new claims [confirm]; proof real and attributed or left as [fill in].\n- Captions are 2 to 6 words and match the promise.\n- Each test changes one thing, fits what that store's tool can test and has a hypothesis.\n\n## Next step\nOffer store-screenshots to build the full storyboard around these captions, or app-store-optimization to rebuild the keyword set.\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"
}