{"id":90197,"plugin_id":"plugin_asdk_app_6ae249752da48191b2bfcef9fa277fea","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-11-11T00:09:33.385Z","digest":"5a4dfaa7901a33dac8a0ea75e1feabf30f75ed0b4c97dc1322a3019fd7662a61","against":null,"payload":{"description":"Builds an app's ratings and reviews plan: when to show the native rating prompt, store rules on asking for reviews, reply templates for positive and negative reviews, and turning review themes into fixes. 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":"ratings-reviews","skill_md_contents":"---\nname: ratings-reviews\ndescription: \"Builds an app's ratings and reviews plan: when to show the native rating prompt, store rules on asking for reviews, reply templates for positive and negative reviews, and turning review themes into fixes. 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# Ratings and Reviews\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\nHelp an app earn more and fairer ratings within the store rules, answer reviews well and learn from them. Deliver a prompt timing plan built on the native rating prompts, 5 reply templates and a theme tagging table that turns review patterns into the next release's fixes.\n\n## Before you start\n- Use what the user gives: the app's success moment, platforms, current rating and review volume, common complaints and the support email.\n- Ask at most 2 questions, only if missing: \"When do users feel the app worked for them?\" and \"Are you on the App Store, Google Play or both?\" Otherwise assume both stores and a success moment based on the app's main action, and say so in one line.\n- If the user pastes real reviews, tag them and draft replies to those. Never invent reviews, ratings or counts. Reply in the user's language, and answer each review in the reviewer's language.\n\n## When to ask\n- Right after a success moment: a finished workout, a booked appointment, a completed lesson, an exported file, a goal reached.\n- Only for people who have used the app enough to judge it, for example after the [3rd] success and at least [2] days after install [confirm], as a starting rule to tune.\n- Never on first launch, during onboarding, in the middle of a task, at checkout, or after an error, a crash or a failed payment.\n- Use the native prompts only. iOS: StoreKit's review request, which the system limits to 3 showings per user in 365 days and may not show at all. Android: the Google Play In-App Review API, which has a quota and may also not appear. The flow continues the same way whether or not the prompt shows. In Expo, expo-store-review calls both.\n- A \"Rate the app\" item in settings links straight to the store's review page (on iOS, the App Store link with action=write-review), because a native prompt triggered by a button might not appear.\n- Web apps have no store prompt: use the same timing and rules on whichever review site matters, after checking that site's own rules.\n\n## Store rules\n- No review gating. Never ask \"Do you like the app?\" or show your own star picker first and then send only happy users to the store. Apple requires its own API for rating prompts, and Google Play forbids asking questions before or during its review prompt.\n- Never offer rewards for reviews (coins, unlocks, discounts, contest entries) and never ask anyone to change a rating. No reviews from staff, friends or paid services.\n- Keep a separate feedback option in settings (\"Send feedback\" or \"Report a problem\") available at all times. It is a support channel, never a filter in front of the rating prompt.\n- Rules change: tell the user to check the current App Store Review Guidelines and Google Play policies.\n\n## Replying to reviews\n- Reply within a few days, starting with 1 and 2 star reviews and bug reports. Reviewers are usually notified and may update their review.\n- Be personal and specific: use their words, name the feature, sign with a name [fill in].\n- Never be defensive or argue. Thank them, say what changes (and when, only if true [confirm]) and move private details to [support email]. Never ask for or post account details in public.\n- Keep each reply under 350 characters to fit Google Play's reply limit [check the current limit], and never paste the same reply everywhere.\n\n```text\nPositive: Thank you, [name]! We're glad [the thing they mentioned] helps you [their goal]. If there's anything you'd like next, tell us at [support email]. [Your name], [App] team\n\nBug report: Sorry about [the problem], and thanks for telling us. [It's fixed in version [x.y] [confirm] / We're working on a fix now.] If it still happens, email [support email] with your device and app version and we'll sort it out.\n\nFeature request: Thanks for suggesting [feature]. [It's on our list / It isn't planned yet because [reason]], and ideas like yours shape what we build next. [Tip: you can already [workaround] in [screen].]\n\nBilling complaint: Sorry for the trouble with [the charge]. Subscriptions are billed by [Apple / Google], so you can cancel in your store's subscription settings and ask them about a refund. Email [support email] and we'll help with every step.\n\nAngry review: We're sorry [the app / this update] let you down, and we hear you about [their point]. We'd like to make it right: please email [support email] and [your name] will reply personally.\n```\n\n## Turning reviews into fixes\n- Tag each review with one main theme: Bug, Missing feature, Confusing, Price or Praise, plus the screen or feature it concerns.\n- Once a month, count themes per store and app version, and keep one representative quote for each.\n- Link the top theme to the next release: one fix or ticket, a line in the release notes, and a reply to the reviewers who raised it once the fix ships.\n- After each release, compare the rating and the theme counts with the month before.\n\n## Output format\n```text\nAssumptions: [one line]\n\nPROMPT TIMING PLAN\nSuccess moment: [event]\nShow the native prompt: after [condition] [confirm]\nNever show it: [first launch, onboarding, mid-task, checkout, after errors]\niOS: StoreKit review request | Android: In-App Review API\nRate item in settings: opens the store's review page\nFeedback option: Settings > [Send feedback], always available\n\nREPLY TEMPLATES\n1. Positive: [adapted to this app]\n(through 5. Angry review)\n\nTHEME TAGGING TABLE (monthly)\n| Theme | Count | Share | Example quote | Screen or feature | Action for next release |\n| Bug | [n] | [x%] | \"[quote]\" | [screen] | [fix] |\n(rows for Missing feature, Confusing, Price, Praise)\n\nMonthly routine: [3 to 4 steps]\n```\n\n## Quality checks\n- The prompt appears only after a success moment, never on first launch, during onboarding or after an error.\n- Only native prompts: no pre-question, custom star picker or routing of happy users, no rewards and no requests to change a rating.\n- A feedback option in settings is always available, separate from the prompt.\n- Each template is personal, specific and calm, moves private details to [support email] and stays under 350 characters.\n- No invented reviews, ratings, version numbers or fix dates.\n- The tagging table uses the 5 themes and links the top theme to the next release.\n\n## Next step\nOffer support-feedback to build the in-app feedback form, or release-notes to announce the fixes reviewers asked for.\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"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}