30 Claude Prompts for Mobile Developers

You are a mobile growth engineer who writes App Store short descriptions that survive review and still convert. <context> Our short description is generic and I need a rewrite that names the job the app does, stays inside the character limit, and does not make claims we cannot back up. </context> <inputs> - Current short description: [PASTE CURRENT SHORT DESCRIPTION] - Primary job to be done: [ONE SENTENCE JOB] - Differentiator: [WHAT YOU DO THAT THE TOP 3 COMPETITORS DO NOT] - Character limit: [170 FOR IOS OR 80 FOR PLAY SHORT] - Claims we cannot make: [LIST FORBIDDEN CLAIMS] </inputs> <task> Write five short description options that fit [CHARACTER LIMIT], each with a different opening hook, and mark which one you would ship first. </task> <constraints> Do not use superlatives we cannot prove. Do not include any item from [LIST FORBIDDEN CLAIMS]. Keep each option inside [170 FOR IOS OR 80 FOR PLAY SHORT] characters including spaces. Write for a person scanning the store on a phone, not for a brand deck. </constraints> <format> Return a numbered list of five options with character counts, then one sentence saying which to ship and why. </format>

You are a senior mobile marketer who writes Play Store full descriptions that stay scannable and pass policy review. <context> I am rewriting the Play Store full description for a feature launch and I want sectioned copy that a reviewer and a shopper can both parse quickly. </context> <inputs> - App name: [APP NAME] - New feature: [FEATURE NAME AND WHAT IT DOES] - Current full description: [PASTE CURRENT PLAY DESCRIPTION] - Target keyword phrases: [3 TO 5 PHRASES] - Policy sensitive topics: [PAYMENTS, HEALTH, KIDS, OR NONE] </inputs> <task> Rewrite the full description with a first-screen lead, three feature sections, and a short who-it-is-for close, weaving in [3 TO 5 PHRASES] without stuffing. </task> <constraints> Do not repeat the same phrase more than twice. Do not invent features that are not in [FEATURE NAME AND WHAT IT DOES] or the current description. If [PAYMENTS, HEALTH, KIDS, OR NONE] is not NONE, add a one-line compliance note and avoid medical or financial promises. </constraints> <format> Return the full description in plain text with heading lines, then a keyword placement table showing where each phrase appears. </format>

You are a mobile product designer who sequences App Store and Play Store screenshots for conversion. <context> We are launching a feature and I need a screenshot order, captions, and device frames that put the new value in the first two frames shoppers actually see. </context> <inputs> - Stores: [APP STORE, PLAY STORE, OR BOTH] - Feature: [FEATURE NAME AND USER OUTCOME] - Current screenshot topics: [LIST CURRENT FRAME TOPICS] - Devices to frame: [IPHONE 15, PIXEL 8, IPAD, OR LIST] - Caption language: [ENGLISH PLUS ANY LOCALES] </inputs> <task> Propose an 8-frame screenshot sequence with caption copy, what the frame should show, and which two frames are mandatory for the launch. </task> <constraints> Frame 1 and frame 2 must communicate [FEATURE NAME AND USER OUTCOME] without requiring the shopper to swipe. Captions must stay under 12 words. Do not ask for UI that does not exist in the build. Provide [ENGLISH PLUS ANY LOCALES] caption variants only for frames 1 to 3. </constraints> <format> Return a table with columns frame number, on-screen content, caption, and why it sits in that slot. </format>

You are a localization lead who adapts mobile store listings for a new country without sounding like a machine translation. <context> We are adding a store locale and I need listing copy that keeps the same claims as English while using phrases people in that market actually search for. </context> <inputs> - Source listing: [PASTE ENGLISH TITLE, SUBTITLE, AND DESCRIPTION] - Target locale: [LOCALE CODE, E.G. DE-DE OR JA-JP] - Local search phrases: [3 TO 6 PHRASES USED IN THAT MARKET] - Features that do not ship there: [LIST UNAVAILABLE FEATURES] - Legal wording required: [AGE RATING, PRIVACY, OR PAYMENT NOTES] </inputs> <task> Produce title, subtitle or short description, and full description in the target locale, plus an English back-translation so I can review claims. </task> <constraints> Do not mention any item in [LIST UNAVAILABLE FEATURES]. Keep the same factual claims as [PASTE ENGLISH TITLE, SUBTITLE, AND DESCRIPTION]. Use at least two of [3 TO 6 PHRASES USED IN THAT MARKET]. Include [AGE RATING, PRIVACY, OR PAYMENT NOTES] where the locale expects it. </constraints> <format> Return target-locale copy in labeled blocks, then an English back-translation, then a short list of phrases you avoided because they sound like ads. </format>

You are a mobile growth analyst who reads competitor store listings to find copy and feature gaps we can honestly fill. <context> I am preparing a listing refresh and I want a gap analysis against the top apps in our category before I rewrite anything. </context> <inputs> - Our listing: [PASTE OUR TITLE AND FIRST SCREEN OF DESCRIPTION] - Competitor A listing: [PASTE COMPETITOR A COPY] - Competitor B listing: [PASTE COMPETITOR B COPY] - Competitor C listing: [PASTE COMPETITOR C COPY] - Features we actually ship: [LIST SHIPPED FEATURES] </inputs> <task> Compare the four listings on promised outcomes, proof, and keyword themes, then list gaps we can fill using only [LIST SHIPPED FEATURES]. </task> <constraints> Do not recommend claims we cannot support with [LIST SHIPPED FEATURES]. Separate gaps that are copy-only from gaps that need a product change. Keep the analysis to facts present in the pasted listings. </constraints> <format> Return a comparison table with rows for outcome, proof, keywords, and social proof, then a ranked list of five listing changes to make this week. </format>

You are a mobile release manager who turns ticket titles into store release notes people actually read. <context> I have a list of tickets in this build and I need user-facing release notes that skip internal jargon and do not promise fixes we cannot confirm. </context> <inputs> - Tickets in the build: [PASTE TICKET TITLES AND TYPES] - App version: [VERSION NAME, E.G. 4.18.0] - Audience: [CONSUMER, SMB, OR ENTERPRISE] - Tone: [PLAIN, PLAYFUL, OR FORMAL] - Do not mention: [INTERNAL TOOLS, REFACTORS, OR UNCONFIRMED FIXES] </inputs> <task> Write store release notes for [VERSION NAME, E.G. 4.18.0] grouped by New, Improved, and Fixed, using only tickets that a user would notice. </task> <constraints> Drop anything in [INTERNAL TOOLS, REFACTORS, OR UNCONFIRMED FIXES]. Do not invent features that are not in [PASTE TICKET TITLES AND TYPES]. Keep the whole note under 500 characters unless a ticket is a major launch. Match [PLAIN, PLAYFUL, OR FORMAL] without slang that would fail store review. </constraints> <format> Return the release notes ready to paste, then a discarded-ticket list with one-line reasons, then an optional longer in-app What is New variant. </format>

You are a mobile engineering lead who writes internal release notes that support and success can act on during a rollout. <context> The public store notes are short, and support needs a longer internal brief so they know what changed, what to say, and which bugs we already know about. </context> <inputs> - Version: [VERSION NAME] - User facing notes: [PASTE PUBLIC RELEASE NOTES] - Known issues: [LIST KNOWN ISSUES AND WORKAROUNDS] - Support macros to update: [LIST MACRO NAMES] - Rollout percent at start: [PERCENTAGE] </inputs> <task> Write an internal release brief that maps each public note to the real change, lists known issues, and says which macros to edit before [PERCENTAGE] of users get the build. </task> <constraints> Do not contradict [PASTE PUBLIC RELEASE NOTES]. If a known issue has no workaround, say so instead of inventing one. Keep the brief readable in five minutes. Flag any change that will generate tickets in the first 24 hours. </constraints> <format> Return a one-page brief with sections: what shipped, what support should say, known issues, macros to update, and first-day watch items. </format>

You are a mobile release engineer who runs staged rollouts on App Store and Play Console. <context> I am about to start a staged rollout and I want halt criteria tied to crash-free sessions and support volume, not a gut feel at 2 a.m. </context> <inputs> - Version: [VERSION NAME] - Stores: [APP STORE, PLAY STORE, OR BOTH] - Baseline crash-free rate: [PERCENT FROM LAST STABLE BUILD] - Support volume baseline: [TICKETS PER DAY] - Feature flags in this build: [LIST FLAGS AND DEFAULTS] </inputs> <task> Propose a staged rollout schedule with percentages, hold times, and halt criteria for crash-free sessions, ANR, and support volume. </task> <constraints> Halt if crash-free sessions drop more than a stated delta below [PERCENT FROM LAST STABLE BUILD]. Include a path that pauses the store rollout and flips [LIST FLAGS AND DEFAULTS] without waiting for a new binary. Do not assume someone is watching the dashboard overnight unless you specify an oncall check. </constraints> <format> Return a timeline table with percent, hold duration, metrics to check, and halt or continue. Add a short oncall checklist. </format>

You are a mobile release manager writing store and in-app notes for a hotfix that most users will never notice. <context> We are shipping a hotfix for a crash or billing bug and I need short What is New copy that is honest without alarming people who never hit the bug. </context> <inputs> - Hotfix version: [VERSION NAME] - What we fixed: [BUG IN ONE SENTENCE] - Who was affected: [PERCENT OR COHORT] - Stores we will update: [APP STORE, PLAY STORE, OR BOTH] - Legal or billing sensitivity: [YES OR NO, PLUS DETAIL] </inputs> <task> Write store What is New copy and a shorter in-app banner line for [VERSION NAME] that states the fix without oversharing. </task> <constraints> Do not name internal ticket IDs. If [YES OR NO, PLUS DETAIL] is YES, avoid wording that admits a charge error unless legal already approved that sentence. Keep store copy under 200 characters. Do not pretend this is a feature release. </constraints> <format> Return three store variants labeled calm, direct, and minimal, then one in-app banner line, then a sentence support can paste. </format>

You are a senior mobile engineer who translates a developer changelog into store release text without losing the user-visible changes. <context> The changelog in git is accurate and unreadable to shoppers, and I need store text that keeps every user-visible change and drops the rest. </context> <inputs> - Changelog: [PASTE GIT LOG OR CHANGELOG MD] - Version: [VERSION NAME] - Product name: [APP NAME] - Max length: [STORE FIELD LIMIT] - Locale: [EN OR OTHER LOCALE] </inputs> <task> Convert [PASTE GIT LOG OR CHANGELOG MD] into store release text for [APP NAME] [VERSION NAME] that fits [STORE FIELD LIMIT]. </task> <constraints> Keep every user-visible behavior change. Drop dependency bumps, lint, and internal refactors unless they change something a user can see. Do not add marketing adjectives. If a line is ambiguous, ask one clarifying question instead of guessing. </constraints> <format> Return the store text, a mapping table from changelog line to keep or drop, and any clarifying questions. </format>

You are a staff mobile engineer who triages crash clusters in Sentry, Crashlytics, or Play Vitals before assigning an owner. <context> A new crash cluster spiked after a release and I need a first-pass triage that names the likely owner, the suspected cause, and whether we should halt the rollout. </context> <inputs> - Stack traces: [PASTE 2 TO 4 REPRESENTATIVE STACKS] - Version and rollout: [VERSION AND PERCENT ROLLED OUT] - Affected OS versions: [IOS OR ANDROID VERSIONS] - Recent changes: [COMMITS OR PRS IN THIS RELEASE] - Crash-free baseline: [PERCENT FROM PRIOR BUILD] </inputs> <task> Group the stacks, name the suspected root area, recommend an owner team, and say whether to halt [VERSION AND PERCENT ROLLED OUT]. </task> <constraints> Do not invent frames that are not in [PASTE 2 TO 4 REPRESENTATIVE STACKS]. Separate symbolicated frames from missing symbols. If the traces are not enough to name a cause, say what extra log or breadcrumb you need instead of guessing. Compare volume language to [PERCENT FROM PRIOR BUILD] only if I gave a number. </constraints> <format> Return a triage card with suspected cause, owner, halt or continue, and the next three diagnostic steps. </format>

You are a mobile QA lead who turns crash reports into a repro plan an engineer can run on a device in under 20 minutes. <context> I have a crash report with breadcrumbs and device metadata, and I need a step-by-step repro before we spend a day staring at the stack. </context> <inputs> - Crash report: [PASTE REPORT METADATA AND BREADCRUMBS] - Stack summary: [PASTE TOP FRAMES] - App entry points: [LIST HOW A USER CAN REACH THE SCREEN] - Feature flags on the device: [FLAGS AND VALUES IF KNOWN] - Device class: [PHONE MODEL, OS, LOCALE, NETWORK] </inputs> <task> Write a repro plan that starts from a clean launch, names required account state, and lists the shortest path to the crashing screen. </task> <constraints> Use only facts in [PASTE REPORT METADATA AND BREADCRUMBS] and [PASTE TOP FRAMES]. If a step is unknown, mark it as a hypothesis. Include a path that matches [DEVICE CLASS]. Do not require debug builds unless a step cannot be done on prod. </constraints> <format> Return numbered repro steps, a required-state checklist, and a table of hypotheses to confirm or kill after the first attempt. </format>

You are an Android performance engineer who reads ANR traces and main-thread dumps to rank likely blockers. <context> Play Console flagged an ANR cluster and I have thread dumps. I need a ranked list of suspects so we do not start by rewriting the wrong screen. </context> <inputs> - ANR traces: [PASTE MAIN THREAD AND KEY WORKER STACKS] - Version: [VERSION NAME] - Screens seen in breadcrumbs: [LIST SCREEN NAMES] - Recent main-thread work added: [PRS THAT TOUCH UI OR IO] - Devices most affected: [DEVICE MODELS OR API LEVELS] </inputs> <task> Rank the likely ANR causes, map each to a frame or lock, and recommend the first measurement to confirm or reject it. </task> <constraints> Treat the main thread dump as the source of truth. Do not blame a worker thread unless it holds a lock the main thread waits on. Prefer causes that match [PRS THAT TOUCH UI OR IO] and [LIST SCREEN NAMES]. Separate disk, lock, binder, and layout suspects. </constraints> <format> Return a ranked table with columns suspect, evidence frame, how to confirm, and a one-line fix direction. </format>

You are a mobile engineering manager writing a short RCA after a crash fix so the next person does not repeat the same miss. <context> We shipped a crash fix and I need a one-page RCA that states impact, root cause, why we missed it, and the guard that would have caught it. </context> <inputs> - Incident summary: [WHAT CRASHED AND WHO WAS HIT] - Root cause: [TECHNICAL CAUSE IN A FEW SENTENCES] - Fix PR: [PR LINK OR SUMMARY] - Why tests missed it: [WHAT THE EXISTING TESTS DID NOT COVER] - Detection time: [TIME FROM SHIP TO FIRST ALERT] </inputs> <task> Write an RCA that a staff engineer and a PM can both read, covering impact, cause, miss, fix, and the follow-up guard. </task> <constraints> Do not blame a person by name. Stick to [TECHNICAL CAUSE IN A FEW SENTENCES] and [WHAT THE EXISTING TESTS DID NOT COVER]. Keep the document under 600 words. Include one concrete test or lint rule, not a vague process note. </constraints> <format> Return markdown with headings Impact, Root cause, Why we missed it, Fix, and Guardrails, plus a two-line summary at the top. </format>

You are a mobile staff engineer deciding whether a crash spike needs a hotfix binary or can wait for the next train. <context> A crash is up after the latest rollout and I need a written go or no-go on a hotfix, including the cost of a new store review versus leaving the staged rollout paused. </context> <inputs> - Crash rate now: [CURRENT CRASH-FREE OR CRASH RATE] - Baseline: [PRIOR BUILD RATE] - Users affected: [COUNT OR PERCENT, PLUS DEVICE FILTER] - Workaround: [NONE, FLAG OFF, OR USER STEPS] - Next regular train: [DATE OF NEXT PLANNED RELEASE] </inputs> <task> Recommend hotfix now, pause rollout and wait, or keep rolling, and show the numbers that drive the call. </task> <constraints> If [NONE, FLAG OFF, OR USER STEPS] is FLAG OFF and that kill switch is already live, prefer pause over a new binary unless the remaining crash still exceeds [PRIOR BUILD RATE] by a stated delta. Do not treat a crash that only hits a debug menu as a hotfix. State review risk for [DATE OF NEXT PLANNED RELEASE] versus an emergency submission. </constraints> <format> Return a one-paragraph decision, a small numbers table, and a list of people to notify either way. </format>

You are a mobile engineer who writes App Store Resolution Center replies that answer the rejection point and do not pick a fight with the reviewer. <context> We received an App Store rejection and I need a reply that maps each guideline cited to what we changed or how the reviewer can verify the current behavior. </context> <inputs> - Rejection text: [PASTE FULL REJECTION INCLUDING GUIDELINE NUMBERS] - What we changed: [FIXES IN THIS NEW BUILD] - How to reproduce the good path: [STEP BY STEP FOR THE REVIEWER] - Demo account: [USERNAME AND PASSWORD OR MAGIC LINK] - Build number: [BUILD SUBMITTED] </inputs> <task> Draft a Resolution Center reply for [BUILD SUBMITTED] that addresses every guideline in [PASTE FULL REJECTION INCLUDING GUIDELINE NUMBERS]. </task> <constraints> Do not argue that the guideline is wrong. If we disagree, ask a clarifying question after stating how to verify the current build. Include [USERNAME AND PASSWORD OR MAGIC LINK] and [STEP BY STEP FOR THE REVIEWER]. Keep the tone factual. Do not promise a feature we have not built. </constraints> <format> Return the reply ready to paste, then a short internal note on what we should still change if they reject again. </format>

You are an Android release lead who writes Play Console appeals that cite the policy section and show proof in the current bundle. <context> Play has flagged the app or a store listing and I need an appeal that a policy specialist can verify without watching a 20 minute video. </context> <inputs> - Policy email or console text: [PASTE PLAY POLICY NOTICE] - Policy section cited: [POLICY NAME OR URL] - Proof in the current bundle: [SCREENS, DECLARATIONS, OR CODE PATHS] - Store listing lines involved: [PASTE FLAGGED COPY] - What we already changed: [CHANGES SINCE THE NOTICE] </inputs> <task> Write a Play appeal that restates the issue, points to proof in the current bundle, and lists the listing or code changes already live. </task> <constraints> Quote [PASTE PLAY POLICY NOTICE] only as needed. Do not claim [CHANGES SINCE THE NOTICE] that are not shipped. If the notice is about [PASTE FLAGGED COPY], show the replacement lines. Keep the appeal under 400 words. </constraints> <format> Return the appeal body, a proof checklist the reviewer can click through, and a list of attachments to upload. </format>

You are a mobile privacy engineer who audits permission usage before an App Store or Play submission. <context> We are about to submit a build and I need a permission audit that matches Info.plist and the Play Data safety form to the actual call sites. </context> <inputs> - Declared permissions: [PASTE PLIST KEYS OR PLAY PERMISSIONS] - Call sites: [LIST APIS AND SCREENS THAT TOUCH THEM] - Purpose strings: [PASTE CURRENT PURPOSE STRINGS] - Features that need each permission: [FEATURE TO PERMISSION MAP] - Stores submitting: [APP STORE, PLAY STORE, OR BOTH] </inputs> <task> Audit each permission against [LIST APIS AND SCREENS THAT TOUCH THEM], flag unused declarations, and rewrite purpose strings that are vague. </task> <constraints> If a permission in [PASTE PLIST KEYS OR PLAY PERMISSIONS] has no call site, mark it for removal. Purpose strings must name the user-visible job, not a generic improve the experience line. Call out any permission that will trigger a sensitive review on [APP STORE, PLAY STORE, OR BOTH]. </constraints> <format> Return a table with columns permission, call site, purpose string, keep or remove, and review risk. </format>

You are a mobile engineer writing App Review notes for a restricted API such as camera, HealthKit, background location, or StoreKit 2. <context> The next build uses a restricted API and I need reviewer notes that tell Apple or Google exactly where to tap, what account to use, and why the API is required. </context> <inputs> - Restricted API: [API NAME, E.G. HEALTHKIT OR BACKGROUND LOCATION] - Why we need it: [USER JOB THAT REQUIRES THE API] - Reviewer path: [SCREENS AND TAPS TO REACH THE PROMPT] - Demo account: [CREDENTIALS AND REQUIRED DATA ON THE ACCOUNT] - Fallback if denied: [WHAT THE APP DOES IF THE USER SAYS NO] </inputs> <task> Write Review Notes that a first-time reviewer can follow without Slacking us, covering path, account, and the deny fallback. </task> <constraints> The notes must include [SCREENS AND TAPS TO REACH THE PROMPT] and [CREDENTIALS AND REQUIRED DATA ON THE ACCOUNT]. Do not hide [WHAT THE APP DOES IF THE USER SAYS NO]. Keep the note under 250 words. Do not tell the reviewer to ignore a prompt. </constraints> <format> Return Review Notes ready to paste, then a shorter Play Console testing-instructions variant. </format>

You are a mobile privacy lead updating App Privacy labels and Play Data safety before a release that adds a new SDK or data type. <context> We added a data collection path and I need a checklist that updates the nutrition label and Data safety form so they match the build we are submitting. </context> <inputs> - New data types: [LIST DATA TYPES ADDED] - New SDKs: [SDK NAMES AND WHAT THEY COLLECT] - Current privacy label: [PASTE CURRENT ANSWERS] - Linked vs not linked: [OUR CURRENT LINKED ACCOUNT POLICY] - Tracking: [YES OR NO, PLUS ATT STATUS] </inputs> <task> Produce an update checklist for the App Privacy nutrition label and the Play Data safety form that covers [LIST DATA TYPES ADDED] and [SDK NAMES AND WHAT THEY COLLECT]. </task> <constraints> If an SDK collects a type we do not declare, flag it as a blocker. Do not mark data as not linked if [OUR CURRENT LINKED ACCOUNT POLICY] says we attach it to the account. Keep tracking answers consistent with [YES OR NO, PLUS ATT STATUS]. Write answers a lawyer can review, not marketing copy. </constraints> <format> Return two checklists, one per store, with the exact form fields to change and the proposed answer for each. </format>

You are a mobile client architect who designs offline-first sync and conflict rules for phone apps. <context> Users edit data offline and I need a written conflict policy before we implement the sync queue, so iOS and Android do not invent different merge behavior. </context> <inputs> - Data types: [LIST LOCAL ENTITIES THAT SYNC] - Conflict cases already seen: [DESCRIBE REAL CONFLICTS] - Source of truth: [SERVER WINS, CLIENT WINS, OR FIELD MERGE] - Multi-device: [YES SAME ACCOUNT ON TWO PHONES] - User-visible merge: [SHOULD THE USER SEE A PROMPT] </inputs> <task> Write a conflict policy for [LIST LOCAL ENTITIES THAT SYNC] covering last-write-wins, field merge, and user prompt cases. </task> <constraints> Default to [SERVER WINS, CLIENT WINS, OR FIELD MERGE] unless a case in [DESCRIBE REAL CONFLICTS] needs a different rule. If [YES SAME ACCOUNT ON TWO PHONES] is YES, include clock-skew handling. Do not require a prompt unless [SHOULD THE USER SEE A PROMPT] says so. Keep rules implementable without a custom CRDT unless you justify it. </constraints> <format> Return a policy table by entity, a queue retry diagram in text, and three example timelines with the expected end state. </format>

You are a mobile product engineer who designs push categories, interruption levels, and copy that will pass store review. <context> We are adding push types and I want a category plan with copy templates, collapse keys, and a rule for what never goes out as a push. </context> <inputs> - Events we might notify: [LIST PRODUCT EVENTS] - Platforms: [IOS, ANDROID, OR BOTH] - Quiet hours: [USER SETTINGS OR NONE] - Legal limits: [MARKETING VS TRANSACTIONAL RULES] - Deep links per event: [EVENT TO URL OR SCREEN] </inputs> <task> Group [LIST PRODUCT EVENTS] into notification categories, write title and body templates, and map each category to [EVENT TO URL OR SCREEN]. </task> <constraints> Separate transactional from marketing. Honor [USER SETTINGS OR NONE] for quiet hours. Do not send a push for events that only matter inside an already-open session. Keep titles under 40 characters. Follow [MARKETING VS TRANSACTIONAL RULES] and say when we need an in-app inbox instead. </constraints> <format> Return a category table with columns event, category, title template, body template, interruption level, collapse key, and deep link. </format>

You are a mobile engineer who owns Universal Links, App Links, and in-app routing tables. <context> Marketing wants a campaign URL that opens a specific screen with parameters, and I need a routing spec that covers installed, not installed, and logged-out users. </context> <inputs> - Campaign URL: [FULL HTTPS URL PLUS QUERY PARAMS] - Destination screen: [SCREEN NAME AND REQUIRED ARGS] - Auth rule: [LOGGED IN ONLY, GUEST OK, OR PAYWALL] - Fallback web page: [URL IF THE APP IS MISSING] - Existing routes: [PASTE CURRENT DEEP LINK TABLE] </inputs> <task> Specify the route, associated-domain or assetlinks needs, parameter validation, and fallbacks for [FULL HTTPS URL PLUS QUERY PARAMS]. </task> <constraints> Do not collide with [PASTE CURRENT DEEP LINK TABLE]. If [LOGGED IN ONLY, GUEST OK, OR PAYWALL] requires login, describe the return-to-screen after auth. Validate [SCREEN NAME AND REQUIRED ARGS] and reject unknown params instead of ignoring them silently. Include a deferred-deeplink note for first install from [URL IF THE APP IS MISSING]. </constraints> <format> Return a routing spec with path, params, auth, fallbacks, and a test matrix of six cases. </format>

You are a mobile performance engineer who reviews background work against battery and OS budget rules on iOS and Android. <context> We added a background refresh or WorkManager job and I need a review that estimates battery cost and names what the OS will kill under Low Power or App Standby. </context> <inputs> - Job description: [WHAT THE BACKGROUND TASK DOES] - Schedule: [INTERVAL, TRIGGERS, AND CONSTRAINTS] - Platforms: [IOS BG TASK, ANDROID WORKMANAGER, OR BOTH] - Network and GPS use: [WIFI ONLY, ANY NETWORK, LOCATION YES OR NO] - Payload size: [TYPICAL BYTES UP AND DOWN] </inputs> <task> Review [WHAT THE BACKGROUND TASK DOES] against OS background rules, estimate battery and data cost, and recommend schedule cuts if the job is too eager. </task> <constraints> Assume the user has Low Power Mode or Battery Saver on for one scenario. If [WIFI ONLY, ANY NETWORK, LOCATION YES OR NO] includes location, treat that as a review and battery risk. Do not recommend a foreground service unless the job is user-visible. Keep recommendations implementable in [IOS BG TASK, ANDROID WORKMANAGER, OR BOTH]. </constraints> <format> Return a risk table, a proposed schedule, and a list of metrics to log for one week after ship. </format>

You are a mobile UX engineer who designs system permission sequences that get a grant without failing App Review. <context> We need camera access for a feature and I want a pre-prompt, system prompt, and deny path that does not loop the user or violate Apple or Google permission rules. </context> <inputs> - Feature that needs camera: [FEATURE NAME AND WHY CAMERA IS REQUIRED] - Platforms: [IOS, ANDROID, OR BOTH] - Current purpose string: [PASTE PURPOSE STRING] - What works if denied: [FALLBACK, E.G. FILE PICKER] - When we ask: [FIRST TAP ON FEATURE OR APP LAUNCH] </inputs> <task> Write the pre-prompt copy, the purpose string, the system-prompt timing, and the deny UI for [FEATURE NAME AND WHY CAMERA IS REQUIRED]. </task> <constraints> Never ask at [FIRST TAP ON FEATURE OR APP LAUNCH] if that value is APP LAUNCH. The purpose string must match [FEATURE NAME AND WHY CAMERA IS REQUIRED] and stay under 120 characters. Always include [FALLBACK, E.G. FILE PICKER] on deny. Do not show a fake system dialog. Do not ask again in the same session after a deny. </constraints> <format> Return a sequence diagram in text, the copy for each step, the purpose string, and the settings deep-link behavior after a deny. </format>