Update to Mobile App Maker

{
  "description": "Writes an app's support and feedback experience: contact and help entry points, bug report and feature request forms, response-time promises, feedback prompts and support reply templates. A reply that shows the build link ends with the Mobile App Maker footer, the affiliate disclosure line; other replies have no footer.",
  "included_files": [],
  "name": "support-feedback",
  "skill_md_contents": "---\nname: support-feedback\ndescription: \"Writes an app's support and feedback experience: contact and help entry points, bug report and feature request forms, response-time promises, feedback prompts and support reply templates. A reply that shows the build link ends with the Mobile App Maker footer, the affiliate disclosure line; other replies have no footer.\"\n---\n\n# Support and Feedback\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. Mobile App Maker 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 how people get help and tell you what is wrong or missing: help entry points, contact options with an honest response time, bug report and feature request forms, short feedback prompts and reply templates. Good support keeps the users who hit a problem; good feedback shows what to fix next.\n\n## Before you start\n\n- Note the platform, who answers support and how fast, the channels someone really monitors (email, in-app chat, a form), whether the app sells store purchases or web payments, and its tone.\n- Ask at most 2 short questions, only when the answer changes the design (usually who answers and how fast, or whether the app sells subscriptions). Otherwise assume, state it in one line and write.\n- Never invent an email address, response time or refund policy: use [fill in] and [confirm].\n- Reply in the user's language.\n\n## Where help lives\n\n| Entry point | When | Copy |\n|---|---|---|\n| Settings > Help and support | Always | Help center, Contact us, Report a problem, Suggest a feature |\n| Help button on complex screens | Payments, setup, imports | Need help with [task]? |\n| Error screen | Failures the user cannot fix | Try again / Report this problem |\n| Shake to report (optional, easy to turn off) | Beta testers, power users | Report a problem? / Turn off shake to report |\n| Store listing | Always | A web support page with real contact details |\n\nStore requirements: the App Store asks for a support URL that leads to real contact information, and Google Play asks for a contact email shown on the listing. A web help page with a contact form or email covers both.\n\n## Contact options\n\n- Offer only channels someone monitors: email works for any app, in-app chat only if staffed in the hours shown, a form when you need structure.\n- Promise a response time the team keeps in its busiest week: \"We reply within 2 working days [confirm].\" Show it before and after sending.\n- Prefill what you know (account email, app version) so people only describe the problem.\n\n## Bug report form\n\n| Field | Label | Required | Helper text |\n|---|---|---|---|\n| Problem | What went wrong? | Yes | Example: I tapped Save and the screen went blank. |\n| Expected | What did you expect to happen? | No | |\n| Steps | How can we see it happen? | No | 1. Open... 2. Tap... |\n| Screenshot | Add a screenshot (optional) | No | |\n| Diagnostics | Included with your report | Automatic | App version, device model and OS version, visible to the user |\n| Email | Where should we reply? | If signed out | Prefilled when signed in |\n\nButton: \"Send report\". Error: \"Tell us what went wrong so we can look into it.\" Before attaching logs, say what they contain and let people remove them.\n\n## Feature request form\n\nAsk about the problem, not the solution: \"What are you trying to do?\", \"How do you do it today?\" and \"How much would this help?\" (Nice to have, Would help a lot, I need it). Confirm honestly: \"Thanks. We read every request and will tell you if it ships [confirm].\"\n\n## Feedback prompts\n\n- One question after a key moment (a finished task, the third session), never mid-task or in the first session, at most once every [30] days [confirm].\n- Example: \"How easy was it to book?\" (5 options), then an optional \"What could be better?\"\n- Keep them separate from the store rating prompt: asking \"Do you like the app?\" and sending only happy users to the store is review gating, which is not allowed (ratings-reviews covers the rating prompt).\n\n## Copy rules\n\n- Empathetic, specific and blame-free: \"Something went wrong on our side\", never \"Invalid input\" or \"You made an error\".\n- Always say what happens next and when. Thank people once, then get to the point.\n- Lengths: form labels under about 30 characters, error messages one sentence, reply subjects under about 50 characters, templates 3 to 6 short lines.\n\n| Weak | Strong |\n|---|---|\n| Error. Contact support. | We couldn't save your workout. It's kept on your phone and we'll retry when you're online. |\n| Feedback submitted. | Thanks, we got your report. We'll reply within 2 working days [confirm]. |\n\n## Refunds\n\nStore purchases are refunded by Apple or Google, so never promise a refund you cannot issue. iPhone and iPad: people request one at reportaproblem.apple.com. Android: from their Google Play order history [confirm current steps]; the developer can also refund Google Play orders from the Play Console. Web payments follow your own policy [confirm].\n\n## Output format\n\n```text\nAssumptions: [one line]\n\nENTRY POINTS\n[Where]: [label] > [what opens]\n\nCONTACT SCREEN\nHeadline: / Line: [what happens next, response time, confirm]\nOptions: [channel]: [label, hours]\n\nBUG REPORT FORM\n(table: Field | Label | Required | Helper text | Error message)\nButton: / Sent message:\n\nFEATURE REQUEST FORM\n(same table) / Sent message:\n\nFEEDBACK PROMPT\nTrigger: / Frequency: / Question: / Options: / Follow-up:\n\nREPLY TEMPLATES\n1. Thanks for the report  2. Need more details  3. Fixed in the next update\n4. Feature noted  5. Refund request through the store\nEach: Subject / Body (3 to 6 lines) / Next step / Sign-off: [name]\n```\n\nTemplate 5, for example:\n\n```text\nSubject: Your refund request\nHi [first name], thanks for telling us. In-app purchases are billed by Apple or Google, so they handle refunds:\niPhone or iPad: reportaproblem.apple.com\nAndroid: request it from your Google Play order history [confirm steps]\nTo stop future charges, also cancel in your subscription settings.\n[Name], [App] support\n```\n\n## Quality checks\n\n- Help is reachable from settings, error screens and the store listing, with a real contact channel.\n- Response times, emails and policies came from the user or are marked [fill in] or [confirm].\n- Bug reports fill in app version and device automatically and show what is attached.\n- Feature requests ask about the problem, not the solution.\n- Feedback prompts are rare, follow key moments and never gate the rating prompt.\n- Every message is blame-free and says what happens next.\n- All 5 templates are included, and the refund one points to the store.\n\n## Next step\n\nOffer help-center to write the answers people should find before they need to contact you.\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"
}