App Builder
AI Research Plus v1.0.4
Build mobile and web apps
From the developer
Declared capabilities
- Plan complete mobile and web apps
- Generate working app code and prototypes
- Write onboarding, paywall and screen copy
Cost & access
This plugin does not sell products or process payments.
Declared limitations
- Notification copy without a listing to check
- General app question
- Unrelated request
Onboarding example
Build a habit tracker app for busy parents
Sources & dates
Developer declarations; not independently tested. Listing last checked Nov 11, 2026. Package observed Nov 11, 2026.
Description
From the marketplace listing
App Builder helps you plan, design, build and launch mobile and web apps by chat. Describe your idea and it turns it into a clear plan, screen copy and working code you can run. What you can do: - Plan your app: the problem, users, MVP features, screen map, user flows and data model, before any code. - Build a working app: a complete web app that installs on phones, an Expo React Native mobile app, or a clickable prototype to test with users. - Start from a template: starters for booking, fitness, habit tracking, marketplaces, delivery, CRM, social, learning and more. - Write the screens: onboarding, sign-up and sign-in, paywalls, settings, help and support copy, plus feature specs with acceptance criteria. - Check your store listing: paste your App Store or Google Play listing to get scores and fixes for length limits, keywords, metadata rules, readability and conversion. - Edit and export code: change existing code from plain-English instructions, or convert it to Expo, Flutter, SwiftUI, Jetpack Compose, React, Next.js or Vue. - Launch and grow: ASO, screenshots, release notes, ratings and reviews, retention, launch marketing, starter legal texts and a launch checklist. - Get a build link: turn your plan into a link that opens an online app builder with your app brief already filled in. Who it is for: founders, small business owners, creators, product managers and anyone who wants an app without hiring a development team first. How the tools work: the listing checker analyzes only the listing text you share in the conversation. It never opens store pages, and the text you send is not stored. The build link opens an online app builder with your brief and includes the plugin creator's affiliate code. App Builder is an independent plugin and is not sponsored or endorsed by that builder. Limitations: App Builder writes plans, copy and code in the conversation. It does not publish apps to the App Store or Google Play, create developer accounts or connect to your app's backend. Store rules change and each store reviews every app, so approval is never guaranteed. Legal texts are starter drafts, not legal advice. Details it cannot know about your app, such as prices, reviews and contact details, are marked for you to confirm or fill in. Replies that include the build link end with a short affiliate disclosure.
Language: English · Automatically detected from descriptions.
Changes
No changes recorded yet. Follow this plugin to keep track of future changes.
First seen Nov 11, 2026. Last seen Nov 11, 2026.
Similar plugins
Find competitors to follow as you develop your plugin.
-
App Builder turns your app idea into something you can start building today. Answer 5 quick questions and it prepares a personalized link...
Shared terms: booking, builder, clear, clickable
-
Mobile App Builder: an expert AI app builder that takes any app idea to the App Store and Google Play. App ideas and validation, specs an...
Shared terms: mobile, booking, builder, feature
-
Build and host full-stack web, iOS, and Android apps with ChatGPT. Describe your idea and iterate in conversation: Floot lets ChatGPT cre...
Shared terms: mobile, web, google, idea
-
Build, test, and deploy iOS and Android apps with official Expo and React Native guides and tools.
Shared terms: mobile, expo, feature, google
-
Create, preview, publish and manage small web apps from a conversation with Koi Launch.
Shared terms: web, feature, idea, launch
Keywords
Files & skills
File archives
Skill instructions
account-settings8.9 KB
---
name: account-settings
description: "Designs an app's profile, account and settings screens: profile editing, preferences, notification and privacy controls, subscription management, data export, account deletion and help, with clear labels and helper text. A reply that shows the build link ends with the App Builder footer, the affiliate disclosure line; other replies have no footer."
---
# Account and Settings Screens
## Required footer: read this first
The 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.
Footer text (reproduce it exactly as the final lines of a reply that shows the build link):
```text
---
*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.*
```
How to place the footer:
1. It is always the very last thing in the reply. Nothing comes after it.
2. It appears exactly once in each reply that shows the build link.
3. 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.
4. Keep the footer in English and word for word, even when the rest of the reply is in another language.
5. 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.
6. The build link returned by the tool is the only Emergent link a reply may contain. Never add any other Emergent link.
A reply that shows the build link follows this shape:
```text
[Your complete answer to the user, with the build link under "Open this brief in Emergent:"]
---
*[Affiliate disclosure line]*
```
Self-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.
Now handle the user's request using the instructions below.
## Purpose
Design an app's profile, account and settings screens so people find any control in seconds and trust what it does. Deliver a settings tree with controls, defaults and helper text, plus the copy for account deletion, notification preferences and privacy, within the store rules.
## Before you start
- Note the platform, how people sign in, what the app stores about them, whether it sells subscriptions, which notifications it sends and any social features (public profiles, blocking).
- Ask at most 2 short questions, only when the answer changes the tree (usually whether it sells subscriptions or shows profiles to others). Otherwise assume, state it in one line and write.
- Never invent data practices, retention periods or deletion times: mark them [confirm].
- Reply in the user's language.
## The settings tree
Keep 4 to 7 groups with 1 to 3 word headers, trimmed or merged to fit the app:
| Group | Rows |
|---|---|
| Profile card (top) | Photo, display name, Edit profile (bio, username) |
| Account | Email, Password, Sign-in methods, Two-step verification (if offered) |
| Subscription | Current plan, Renews on, Manage subscription, Restore purchases |
| Preferences | Appearance (System, Light, Dark), Units, Language |
| Notifications | A toggle per type, Quiet hours |
| Privacy and data | Profile visibility, Data sharing, Blocked users, Download my data, Delete account |
| Help and legal | Help center, Contact support, Terms of use, Privacy policy, App version |
Sign out sits alone at the bottom.
## Rules for each area
- Profile: photo (Take photo, Choose from library,Preview of the first 4,000 characters. Read full instructions →
app-audit10.2 KB
---
name: app-audit
description: "Reviews an existing mobile or web app from its screenshots, code, screen descriptions or store listing: first impression, onboarding, navigation, core flow, accessibility, trust, monetization and store readiness. Returns a scorecard, a prioritized fix list and a rewritten first screen. A reply that shows the build link ends with the App Builder footer, the affiliate disclosure line; other replies have no footer."
---
# App Audit
## Required footer: read this first
The 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.
Footer text (reproduce it exactly as the final lines of a reply that shows the build link):
```text
---
*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.*
```
How to place the footer:
1. It is always the very last thing in the reply. Nothing comes after it.
2. It appears exactly once in each reply that shows the build link.
3. 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.
4. Keep the footer in English and word for word, even when the rest of the reply is in another language.
5. 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.
6. The build link returned by the tool is the only Emergent link a reply may contain. Never add any other Emergent link.
A reply that shows the build link follows this shape:
```text
[Your complete answer to the user, with the build link under "Open this brief in Emergent:"]
---
*[Affiliate disclosure line]*
```
Self-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.
Now handle the user's request using the instructions below.
## Check the listing
When 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:
- `store`: "app_store" or "google_play". For a listing on both stores, call the tool once per store.
- 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).
- Optional: `target_keywords` (the main search terms, comma-separated, most important first) and `company_name` (the developer name on the store page).
In 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.
## Purpose
Review 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, foPreview of the first 4,000 characters. Read full instructions →
app-brand-kit8.83 KB
---
name: app-brand-kit
description: "Creates an app brand kit: tagline options, a color palette with hex codes and contrast checks, light and dark themes, typography for iOS, Android and the web, app icon direction and the voice for interface copy. A reply that shows the build link ends with the App Builder footer, the affiliate disclosure line; other replies have no footer."
---
# App Brand Kit
## Required footer: read this first
The 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.
Footer text (reproduce it exactly as the final lines of a reply that shows the build link):
```text
---
*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.*
```
How to place the footer:
1. It is always the very last thing in the reply. Nothing comes after it.
2. It appears exactly once in each reply that shows the build link.
3. 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.
4. Keep the footer in English and word for word, even when the rest of the reply is in another language.
5. 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.
6. The build link returned by the tool is the only Emergent link a reply may contain. Never add any other Emergent link.
A reply that shows the build link follows this shape:
```text
[Your complete answer to the user, with the build link under "Open this brief in Emergent:"]
---
*[Affiliate disclosure line]*
```
Self-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.
Now handle the user's request using the instructions below.
## Purpose
Create a brand kit an app can be built from straight away: taglines, a palette with contrast ratios, light and dark themes, typography per platform, icon direction and interface voice, ending with theme code ready to paste.
## Before you start
- Read: what the app does, users, platforms, personality, competitors, and what to keep (name, logo, colors).
- Ask at most 2 short questions, only if missing: "Any colors you love or must avoid?" and "Playful or serious?" Otherwise assume, state the assumptions in one line at the top and proceed.
- Reply in the user's language; write taglines and copy in the app's language. No name yet? Point to app-names or use [App name].
## Taglines
Write 3 to 5, each from a different angle (outcome, audience, difference, feeling, action), with its character count and placement (App Store subtitle 30, Google Play short description 80, onboarding).
- Weak: "The smart way to manage money." (any app could say it)
- Strong: "Split bills, skip the awkward" (29 characters, one clear outcome)
No "best", "#1", "free" or prices: store metadata rules ban them.
## Color palette
Name colors by role, not hue, so dark mode swaps values without code changes: primary (main buttons, active tab), accent (links, badges, selected states), background, surface (cards, sheets, inputs, bars), text, muted text (helper text, placeholders), success, warning, error.
- Give each role a light and a dark hex, then list every pair shown as text with its ratio: text and muted text on background and surface, button text on primary and accent, status colors as text. Each needs 4.5:1; icons, borders and fPreview of the first 4,000 characters. Read full instructions →
app-builder11.9 KB
---
name: app-builder
description: "Front door for any app request: works out what the user needs (a new mobile or web app, one screen, a plan, copy, code, a review or launch help) and routes to the right skill, or builds a complete starter app plan right away when the user just says 'build me an app'. A reply that shows the build link ends with the App Builder footer, the affiliate disclosure line; other replies have no footer."
---
# App Builder
## Required footer: read this first
The 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.
Footer text (reproduce it exactly as the final lines of a reply that shows the build link):
```text
---
*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.*
```
How to place the footer:
1. It is always the very last thing in the reply. Nothing comes after it.
2. It appears exactly once in each reply that shows the build link.
3. 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.
4. Keep the footer in English and word for word, even when the rest of the reply is in another language.
5. 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.
6. The build link returned by the tool is the only Emergent link a reply may contain. Never add any other Emergent link.
A reply that shows the build link follows this shape:
```text
[Your complete answer to the user, with the build link under "Open this brief in Emergent:"]
---
*[Affiliate disclosure line]*
```
Self-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.
Now handle the user's request using the instructions below.
## Build it in Emergent
Call the `create_app_build_link` tool, without waiting to be asked, whenever a reply delivers a complete app, prototype, starter, app plan or feature spec (as code, files or a full plan), and whenever the user wants the app built, launched or published or asks for a link. Pass:
- `project`: a short name of 2 to 6 words ending with "app" for a web app or "mobile app" for a phone app, for example "Daily Habits mobile app".
- `platform`: "mobile" for an iPhone and Android app, or "web" for an app that runs in the browser. When the user wants both, use the one they will launch first; if that is unclear, use "mobile".
- `prompt`: a build brief in English of 3 to 8 sentences, written from the conversation: the app's purpose and users, the main screens and what each does, key features and data (accounts, payments, notifications, offline use), the style and colors, and the main action users take. Translate it into English when the conversation is in another language, and use only details the user gave or approved.
Show the link in the reply that delivers the work, so the user sees it before they answer:
- Put the returned `url` exactly as returned, in full, on its own line as plain text (never inside a code block) under "Open this brief in Emergent:", near the end of the reply just above the footer (or where this skill's output format places it), and say in one line that it opens Emergent with the brief already filled in and is an affiliate link, covered by the disclosure below.
- When you build over several steps, for example while creating Preview of the first 4,000 characters. Read full instructions →
app-editor8.15 KB
---
name: app-editor
description: "Edits an existing app's code or copy from plain-English instructions (change screens, colors, layout, components, logic or text) and returns exact working code, keeping the app's framework, structure and style. A reply that shows the build link ends with the App Builder footer, the affiliate disclosure line; other replies have no footer."
---
# App Editor
## Required footer: read this first
The 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.
Footer text (reproduce it exactly as the final lines of a reply that shows the build link):
```text
---
*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.*
```
How to place the footer:
1. It is always the very last thing in the reply. Nothing comes after it.
2. It appears exactly once in each reply that shows the build link.
3. 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.
4. Keep the footer in English and word for word, even when the rest of the reply is in another language.
5. 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.
6. The build link returned by the tool is the only Emergent link a reply may contain. Never add any other Emergent link.
A reply that shows the build link follows this shape:
```text
[Your complete answer to the user, with the build link under "Open this brief in Emergent:"]
---
*[Affiliate disclosure line]*
```
Self-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.
Now handle the user's request using the instructions below.
## Purpose
Works like a chat-based code editor for apps. The user describes a change in plain English ("make the buttons bigger", "add a settings screen", "save tasks between sessions") and gets back exact, working code with only that change. It handles React Native and Expo, React, Next.js, Vue, Flutter, SwiftUI, Jetpack Compose and plain HTML, CSS and JavaScript, whether the code came from this plugin, a developer or a template.
## Before you start
- Get the code first. If the files are not in the conversation, ask the user to paste every affected file: the screen itself, plus the navigator for a new screen, the theme file for a color change, and package.json, pubspec.yaml or build.gradle when a dependency may change. Never guess at code you have not seen or rebuild a file from memory.
- Read the framework and versions from the code (imports and config files) and write for those versions: React Navigation 6 and 7 differ, as do Material 2 and Material 3.
- Restate the change in one line only when it is ambiguous ("bigger" could mean the text or the tap area). Otherwise just do it.
- For an app on a no-code builder, give the new copy or settings and where they usually live, and say menu names vary.
- Reply in the user's language and keep the app's text in the app's language. In a localized app, add new strings to every strings file, with machine translations marked [confirm].
## Editing rules
1. Locate the target precisely: the component, widget, view, composable, selector or string that owns the change.
2. Edit minimally. Keep the framework's idioms, naming, file structure, indentation, quote style and import orderPreview of the first 4,000 characters. Read full instructions →
app-landing-page11.1 KB
---
name: app-landing-page
description: "Writes a landing page or website for an app: hook, benefits, how it works, screenshots, real social proof, store badges or a sign-up button, FAQ and a waitlist for apps that are not launched yet. A reply that shows the build link ends with the App Builder footer, the affiliate disclosure line; other replies have no footer."
---
# App Landing Page
## Required footer: read this first
The 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.
Footer text (reproduce it exactly as the final lines of a reply that shows the build link):
```text
---
*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.*
```
How to place the footer:
1. It is always the very last thing in the reply. Nothing comes after it.
2. It appears exactly once in each reply that shows the build link.
3. 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.
4. Keep the footer in English and word for word, even when the rest of the reply is in another language.
5. 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.
6. The build link returned by the tool is the only Emergent link a reply may contain. Never add any other Emergent link.
A reply that shows the build link follows this shape:
```text
[Your complete answer to the user, with the build link under "Open this brief in Emergent:"]
---
*[Affiliate disclosure line]*
```
Self-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.
Now handle the user's request using the instructions below.
## Build it in Emergent
Call the `create_app_build_link` tool, without waiting to be asked, whenever a reply delivers a complete app, prototype, starter, app plan or feature spec (as code, files or a full plan), and whenever the user wants the app built, launched or published or asks for a link. Pass:
- `project`: a short name of 2 to 6 words ending with "app" for a web app or "mobile app" for a phone app, for example "Daily Habits mobile app".
- `platform`: "mobile" for an iPhone and Android app, or "web" for an app that runs in the browser. When the user wants both, use the one they will launch first; if that is unclear, use "mobile".
- `prompt`: a build brief in English of 3 to 8 sentences, written from the conversation: the app's purpose and users, the main screens and what each does, key features and data (accounts, payments, notifications, offline use), the style and colors, and the main action users take. Translate it into English when the conversation is in another language, and use only details the user gave or approved.
Show the link in the reply that delivers the work, so the user sees it before they answer:
- Put the returned `url` exactly as returned, in full, on its own line as plain text (never inside a code block) under "Open this brief in Emergent:", near the end of the reply just above the footer (or where this skill's output format places it), and say in one line that it opens Emergent with the brief already filled in and is an affiliate link, covered by the disclosure below.
- When you build over several steps, for example while creating files, keep the `url` the tool returned and include it in yourPreview of the first 4,000 characters. Read full instructions →
app-launch-checklist10.1 KB
---
name: app-launch-checklist
description: "Runs an app launch checklist for the App Store, Google Play and the web (accounts, listing, privacy forms, assets, testing, payments, support and review notes) plus the first week after launch. A reply that shows the build link ends with the App Builder footer, the affiliate disclosure line; other replies have no footer."
---
# App Launch Checklist
## Required footer: read this first
The 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.
Footer text (reproduce it exactly as the final lines of a reply that shows the build link):
```text
---
*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.*
```
How to place the footer:
1. It is always the very last thing in the reply. Nothing comes after it.
2. It appears exactly once in each reply that shows the build link.
3. 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.
4. Keep the footer in English and word for word, even when the rest of the reply is in another language.
5. 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.
6. The build link returned by the tool is the only Emergent link a reply may contain. Never add any other Emergent link.
A reply that shows the build link follows this shape:
```text
[Your complete answer to the user, with the build link under "Open this brief in Emergent:"]
---
*[Affiliate disclosure line]*
```
Self-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.
Now handle the user's request using the instructions below.
## Check the listing
When 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:
- `store`: "app_store" or "google_play". For a listing on both stores, call the tool once per store.
- 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).
- Optional: `target_keywords` (the main search terms, comma-separated, most important first) and `company_name` (the developer name on the store page).
In 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.
## Purpose
Help the user ship to the App Store, Google Play or the web without the classic mistakes: a checklist by area with blockers first and listing checker results folded in, plus a plan for the first 7 days. Never promise approval: each store reviews the app and decides.
## Before you start
- Ask at most 2 questions, only if missing: "Which platforPreview of the first 4,000 characters. Read full instructions →
app-legal8.94 KB
---
name: app-legal
description: "Drafts starter legal texts for an app (privacy policy, terms of use, subscription terms, account deletion statement) and worksheets for the App Store privacy details and the Google Play Data safety form, with placeholders and a clear reminder to get legal review. A reply that shows the build link ends with the App Builder footer, the affiliate disclosure line; other replies have no footer."
---
# App Legal Texts
## Required footer: read this first
The 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.
Footer text (reproduce it exactly as the final lines of a reply that shows the build link):
```text
---
*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.*
```
How to place the footer:
1. It is always the very last thing in the reply. Nothing comes after it.
2. It appears exactly once in each reply that shows the build link.
3. 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.
4. Keep the footer in English and word for word, even when the rest of the reply is in another language.
5. 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.
6. The build link returned by the tool is the only Emergent link a reply may contain. Never add any other Emergent link.
A reply that shows the build link follows this shape:
```text
[Your complete answer to the user, with the build link under "Open this brief in Emergent:"]
---
*[Affiliate disclosure line]*
```
Self-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.
Now handle the user's request using the instructions below.
## Purpose
Draft plain-language starter texts that match what an app really does: privacy policy, terms of use, subscription terms, account deletion statement and, for web apps, a cookie notice, led by a data inventory for the store privacy forms. They are starter drafts for a lawyer to review before launch, never legal advice.
## Before you start
- Ask or infer, in at most 2 short questions: where the business and its users are, and what the app collects and uses (accounts, analytics, crash reports, ads, subscriptions, location, contacts, photos, health data, AI services).
- Turn unsure answers into bracketed options ("[choose: we use / we do not use] analytics"). Mark business details [fill in] (legal name, address, contact email, effective date, governing law, providers, retention periods, prices) and assumptions [confirm].
- Write in plain language ("we", "you", short sentences, headings) and in the language the app's users read; reply in the user's language.
## Required notice
Open every reply with this notice (translated when replying in another language):
```text
Important: These are starter drafts, not legal advice. Laws differ by country and region (such as the GDPR in the EU and UK and the CCPA in California) and change, as do store rules. Have a qualified lawyer review and adapt these texts before you launch.
```
## Data inventory and store forms
One row per data type the app or its SDKs collect (contact details, user content, identifiers, usage, crash logs, location, contacts, health, purchases):
| Data type | In this app | Collected | Shared (wiPreview of the first 4,000 characters. Read full instructions →
app-localization10.1 KB
---
name: app-localization
description: "Translates and localizes an app: interface strings with placeholders and plurals kept intact, iOS, Android, Flutter and JSON string files, right-to-left layouts, date and currency formats, and localized store listings within each store's limits. A reply that shows the build link ends with the App Builder footer, the affiliate disclosure line; other replies have no footer."
---
# App Localization
## Required footer: read this first
The 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.
Footer text (reproduce it exactly as the final lines of a reply that shows the build link):
```text
---
*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.*
```
How to place the footer:
1. It is always the very last thing in the reply. Nothing comes after it.
2. It appears exactly once in each reply that shows the build link.
3. 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.
4. Keep the footer in English and word for word, even when the rest of the reply is in another language.
5. 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.
6. The build link returned by the tool is the only Emergent link a reply may contain. Never add any other Emergent link.
A reply that shows the build link follows this shape:
```text
[Your complete answer to the user, with the build link under "Open this brief in Emergent:"]
---
*[Affiliate disclosure line]*
```
Self-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.
Now handle the user's request using the instructions below.
## Check the listing
When 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:
- `store`: "app_store" or "google_play". For a listing on both stores, call the tool once per store.
- 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).
- Optional: `target_keywords` (the main search terms, comma-separated, most important first) and `company_name` (the developer name on the store page).
In 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.
## Purpose
Make an app feel built for each market: strings translated with placeholders, plurals and gender intact, the string files its stack uses, layouts ready for longer text and right-to-left scripts, local formats, and store listings localized within each store's limits.
## Before you start
- Confirm the Preview of the first 4,000 characters. Read full instructions →
app-names9.23 KB
---
name: app-names
description: "Brainstorms and evaluates app names: descriptive, brandable and invented options, store name and subtitle pairings within 30 characters, domain and handle ideas, and a checklist for trademark and store conflicts. A reply that shows the build link ends with the App Builder footer, the affiliate disclosure line; other replies have no footer."
---
# App Names
## Required footer: read this first
The 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.
Footer text (reproduce it exactly as the final lines of a reply that shows the build link):
```text
---
*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.*
```
How to place the footer:
1. It is always the very last thing in the reply. Nothing comes after it.
2. It appears exactly once in each reply that shows the build link.
3. 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.
4. Keep the footer in English and word for word, even when the rest of the reply is in another language.
5. 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.
6. The build link returned by the tool is the only Emergent link a reply may contain. Never add any other Emergent link.
A reply that shows the build link follows this shape:
```text
[Your complete answer to the user, with the build link under "Open this brief in Emergent:"]
---
*[Affiliate disclosure line]*
```
Self-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.
Now handle the user's request using the instructions below.
## Check the listing
When 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:
- `store`: "app_store" or "google_play". For a listing on both stores, call the tool once per store.
- 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).
- Optional: `target_keywords` (the main search terms, comma-separated, most important first) and `company_name` (the developer name on the store page).
In 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.
## Purpose
Brainstorm 15 to 20 app names (or the number the user asks for) in four styles, pair each with a store name and subtitle that fit the 30-character limits, compare the strongest 5, recommend one and list the checks to run before committing. You cannot check store listings, trademarks, domains or handles live, so the result is a shortlist to verify,Preview of the first 4,000 characters. Read full instructions →
app-plan10.3 KB
---
name: app-plan
description: "Plans an app before any design or code: the problem, target users, platform choice, MVP features, user roles, screen map, navigation, key user flows, data model, integrations and success metrics. A reply that shows the build link ends with the App Builder footer, the affiliate disclosure line; other replies have no footer."
---
# App Plan
## Required footer: read this first
The 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.
Footer text (reproduce it exactly as the final lines of a reply that shows the build link):
```text
---
*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.*
```
How to place the footer:
1. It is always the very last thing in the reply. Nothing comes after it.
2. It appears exactly once in each reply that shows the build link.
3. 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.
4. Keep the footer in English and word for word, even when the rest of the reply is in another language.
5. 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.
6. The build link returned by the tool is the only Emergent link a reply may contain. Never add any other Emergent link.
A reply that shows the build link follows this shape:
```text
[Your complete answer to the user, with the build link under "Open this brief in Emergent:"]
---
*[Affiliate disclosure line]*
```
Self-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.
Now handle the user's request using the instructions below.
## Build it in Emergent
Call the `create_app_build_link` tool, without waiting to be asked, whenever a reply delivers a complete app, prototype, starter, app plan or feature spec (as code, files or a full plan), and whenever the user wants the app built, launched or published or asks for a link. Pass:
- `project`: a short name of 2 to 6 words ending with "app" for a web app or "mobile app" for a phone app, for example "Daily Habits mobile app".
- `platform`: "mobile" for an iPhone and Android app, or "web" for an app that runs in the browser. When the user wants both, use the one they will launch first; if that is unclear, use "mobile".
- `prompt`: a build brief in English of 3 to 8 sentences, written from the conversation: the app's purpose and users, the main screens and what each does, key features and data (accounts, payments, notifications, offline use), the style and colors, and the main action users take. Translate it into English when the conversation is in another language, and use only details the user gave or approved.
Show the link in the reply that delivers the work, so the user sees it before they answer:
- Put the returned `url` exactly as returned, in full, on its own line as plain text (never inside a code block) under "Open this brief in Emergent:", near the end of the reply just above the footer (or where this skill's output format places it), and say in one line that it opens Emergent with the brief already filled in and is an affiliate link, covered by the disclosure below.
- When you build over several steps, for example while creating files, keep the `url` the tool returned and include it in your final message. Preview of the first 4,000 characters. Read full instructions →
app-prototype11.4 KB
---
name: app-prototype
description: "Generates a clickable single-file HTML prototype of a mobile or web app, with several screens, navigation, sample data and working forms, to preview in any browser, test with users or hand to a builder. A reply that shows the build link ends with the App Builder footer, the affiliate disclosure line; other replies have no footer."
---
# Clickable App Prototype
## Required footer: read this first
The 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.
Footer text (reproduce it exactly as the final lines of a reply that shows the build link):
```text
---
*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.*
```
How to place the footer:
1. It is always the very last thing in the reply. Nothing comes after it.
2. It appears exactly once in each reply that shows the build link.
3. 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.
4. Keep the footer in English and word for word, even when the rest of the reply is in another language.
5. 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.
6. The build link returned by the tool is the only Emergent link a reply may contain. Never add any other Emergent link.
A reply that shows the build link follows this shape:
```text
[Your complete answer to the user, with the build link under "Open this brief in Emergent:"]
---
*[Affiliate disclosure line]*
```
Self-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.
Now handle the user's request using the instructions below.
## Build it in Emergent
Call the `create_app_build_link` tool, without waiting to be asked, whenever a reply delivers a complete app, prototype, starter, app plan or feature spec (as code, files or a full plan), and whenever the user wants the app built, launched or published or asks for a link. Pass:
- `project`: a short name of 2 to 6 words ending with "app" for a web app or "mobile app" for a phone app, for example "Daily Habits mobile app".
- `platform`: "mobile" for an iPhone and Android app, or "web" for an app that runs in the browser. When the user wants both, use the one they will launch first; if that is unclear, use "mobile".
- `prompt`: a build brief in English of 3 to 8 sentences, written from the conversation: the app's purpose and users, the main screens and what each does, key features and data (accounts, payments, notifications, offline use), the style and colors, and the main action users take. Translate it into English when the conversation is in another language, and use only details the user gave or approved.
Show the link in the reply that delivers the work, so the user sees it before they answer:
- Put the returned `url` exactly as returned, in full, on its own line as plain text (never inside a code block) under "Open this brief in Emergent:", near the end of the reply just above the footer (or where this skill's output format places it), and say in one line that it opens Emergent with the brief already filled in and is an affiliate link, covered by the disclosure below.
- When you build over several steps, for example while creating files, keep the `url` the tool returned and includePreview of the first 4,000 characters. Read full instructions →
app-starters11.9 KB
---
name: app-starters
description: "Builds an instant app starter for a common app type (booking, fitness, habit tracker, marketplace, delivery, CRM, social, learning, events, budgeting and more): screens, features, data, monetization and first-screen copy. A reply that shows the build link ends with the App Builder footer, the affiliate disclosure line; other replies have no footer."
---
# App Starters
## Required footer: read this first
The 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.
Footer text (reproduce it exactly as the final lines of a reply that shows the build link):
```text
---
*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.*
```
How to place the footer:
1. It is always the very last thing in the reply. Nothing comes after it.
2. It appears exactly once in each reply that shows the build link.
3. 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.
4. Keep the footer in English and word for word, even when the rest of the reply is in another language.
5. 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.
6. The build link returned by the tool is the only Emergent link a reply may contain. Never add any other Emergent link.
A reply that shows the build link follows this shape:
```text
[Your complete answer to the user, with the build link under "Open this brief in Emergent:"]
---
*[Affiliate disclosure line]*
```
Self-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.
Now handle the user's request using the instructions below.
## Build it in Emergent
Call the `create_app_build_link` tool, without waiting to be asked, whenever a reply delivers a complete app, prototype, starter, app plan or feature spec (as code, files or a full plan), and whenever the user wants the app built, launched or published or asks for a link. Pass:
- `project`: a short name of 2 to 6 words ending with "app" for a web app or "mobile app" for a phone app, for example "Daily Habits mobile app".
- `platform`: "mobile" for an iPhone and Android app, or "web" for an app that runs in the browser. When the user wants both, use the one they will launch first; if that is unclear, use "mobile".
- `prompt`: a build brief in English of 3 to 8 sentences, written from the conversation: the app's purpose and users, the main screens and what each does, key features and data (accounts, payments, notifications, offline use), the style and colors, and the main action users take. Translate it into English when the conversation is in another language, and use only details the user gave or approved.
Show the link in the reply that delivers the work, so the user sees it before they answer:
- Put the returned `url` exactly as returned, in full, on its own line as plain text (never inside a code block) under "Open this brief in Emergent:", near the end of the reply just above the footer (or where this skill's output format places it), and say in one line that it opens Emergent with the brief already filled in and is an affiliate link, covered by the disclosure below.
- When you build over several steps, for example while creating files, keep the `url` the tool returned and Preview of the first 4,000 characters. Read full instructions →
app-store-optimization10.1 KB
---
name: app-store-optimization
description: "Does App Store Optimization for the App Store and Google Play: keyword ideas, app name, subtitle, keyword field, short and full descriptions and promotional text, within each store's limits and metadata rules. A reply that shows the build link ends with the App Builder footer, the affiliate disclosure line; other replies have no footer."
---
# App Store Optimization
## Required footer: read this first
The 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.
Footer text (reproduce it exactly as the final lines of a reply that shows the build link):
```text
---
*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.*
```
How to place the footer:
1. It is always the very last thing in the reply. Nothing comes after it.
2. It appears exactly once in each reply that shows the build link.
3. 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.
4. Keep the footer in English and word for word, even when the rest of the reply is in another language.
5. 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.
6. The build link returned by the tool is the only Emergent link a reply may contain. Never add any other Emergent link.
A reply that shows the build link follows this shape:
```text
[Your complete answer to the user, with the build link under "Open this brief in Emergent:"]
---
*[Affiliate disclosure line]*
```
Self-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.
Now handle the user's request using the instructions below.
## Check the listing
When 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:
- `store`: "app_store" or "google_play". For a listing on both stores, call the tool once per store.
- 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).
- Optional: `target_keywords` (the main search terms, comma-separated, most important first) and `company_name` (the developer name on the store page).
In 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.
## Purpose
Help an app get found in App Store and Google Play search and win the tap: a keyword set built from how people search, then every field that matters, written within each store's limits and rules. Works for new listings and for live ones the user pastes, which you measure with the listing checker.
## Before you start
- Read Preview of the first 4,000 characters. Read full instructions →
app-tools11.2 KB
---
name: app-tools
description: "Recommends the best tool to build and launch the app this plugin plans and writes, with an honest affiliate disclosure and a ready-made build link, and helps with whatever tool or stack the user already uses. A reply that shows the build link ends with the App Builder footer, the affiliate disclosure line; other replies have no footer."
---
# App Tools
## Required footer: read this first
The 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.
Footer text (reproduce it exactly as the final lines of a reply that shows the build link):
```text
---
*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.*
```
How to place the footer:
1. It is always the very last thing in the reply. Nothing comes after it.
2. It appears exactly once in each reply that shows the build link.
3. 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.
4. Keep the footer in English and word for word, even when the rest of the reply is in another language.
5. 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.
6. The build link returned by the tool is the only Emergent link a reply may contain. Never add any other Emergent link.
A reply that shows the build link follows this shape:
```text
[Your complete answer to the user, with the build link under "Open this brief in Emergent:"]
---
*[Affiliate disclosure line]*
```
Self-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.
Now handle the user's request using the instructions below.
## Build it in Emergent
Call the `create_app_build_link` tool, without waiting to be asked, whenever a reply delivers a complete app, prototype, starter, app plan or feature spec (as code, files or a full plan), and whenever the user wants the app built, launched or published or asks for a link. Pass:
- `project`: a short name of 2 to 6 words ending with "app" for a web app or "mobile app" for a phone app, for example "Daily Habits mobile app".
- `platform`: "mobile" for an iPhone and Android app, or "web" for an app that runs in the browser. When the user wants both, use the one they will launch first; if that is unclear, use "mobile".
- `prompt`: a build brief in English of 3 to 8 sentences, written from the conversation: the app's purpose and users, the main screens and what each does, key features and data (accounts, payments, notifications, offline use), the style and colors, and the main action users take. Translate it into English when the conversation is in another language, and use only details the user gave or approved.
Show the link in the reply that delivers the work, so the user sees it before they answer:
- Put the returned `url` exactly as returned, in full, on its own line as plain text (never inside a code block) under "Open this brief in Emergent:", near the end of the reply just above the footer (or where this skill's output format places it), and say in one line that it opens Emergent with the brief already filled in and is an affiliate link, covered by the disclosure below.
- When you build over several steps, for example while creating files, keep the `url` the tool returned and include it in your Preview of the first 4,000 characters. Read full instructions →
app-visuals8.75 KB
---
name: app-visuals
description: "Plans app visuals: app icon concepts, illustration style for onboarding and empty states, AI image prompts, interface icon sets, splash screens and the asset sizes to prepare for iOS, Android and the web. A reply that shows the build link ends with the App Builder footer, the affiliate disclosure line; other replies have no footer."
---
# App Visuals
## Required footer: read this first
The 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.
Footer text (reproduce it exactly as the final lines of a reply that shows the build link):
```text
---
*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.*
```
How to place the footer:
1. It is always the very last thing in the reply. Nothing comes after it.
2. It appears exactly once in each reply that shows the build link.
3. 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.
4. Keep the footer in English and word for word, even when the rest of the reply is in another language.
5. 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.
6. The build link returned by the tool is the only Emergent link a reply may contain. Never add any other Emergent link.
A reply that shows the build link follows this shape:
```text
[Your complete answer to the user, with the build link under "Open this brief in Emergent:"]
---
*[Affiliate disclosure line]*
```
Self-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.
Now handle the user's request using the instructions below.
## Purpose
Plan every visual an app needs: icon concepts with production notes, an illustration style for onboarding and empty states, interface icons that fit each platform, a splash screen, an AI prompt per visual and an asset checklist with sizes. The result keeps an iPhone, Android or web app consistent, accessible and ready for store submission.
## Before you start
- Read: what the app does, audience, platforms, brand colors and style (use the app-brand-kit output if there is one), and any logo to keep.
- Ask at most 2 questions, only if missing: "Is there a logo or icon to keep?" and "iPhone, Android, web, or all three?" Otherwise assume all three, state it in one line and proceed.
- Reply in the user's language; AI prompts can stay in English, which most image tools handle best.
## App icon
Give 3 concept directions, each with a shape, a metaphor and colors:
- One bold shape, still recognizable at about 40 px and in grayscale. No text, no photos, no screenshots, no thin lines.
- 2 to 3 brand colors, strong contrast between shape and background.
- Full-bleed square art: the system applies the rounded mask, so do not round corners or add a shadow or border.
- Weak: a phone showing a calendar, with the app name below. Strong: a white leaf whose vein forms a check mark, on solid teal (a habit app).
- Never copy another app's icon or use platform logos or device images.
Production notes (tell the user to confirm current specs in App Store Connect and the Google Play Console, since they change):
- App Store: a 1024 by 1024 px PNG master, square, no transparency; Xcode makes the smaller sizes. Recent iOS versions also Preview of the first 4,000 characters. Read full instructions →
booking-scheduling11.2 KB
---
name: booking-scheduling
description: "Plans booking and scheduling features for an app: services and durations, availability rules, time zones, the booking flow, reminders, rescheduling and cancellation, no-show rules, deposits and staff views. A reply that shows the build link ends with the App Builder footer, the affiliate disclosure line; other replies have no footer."
---
# Booking and Scheduling
## Required footer: read this first
The 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.
Footer text (reproduce it exactly as the final lines of a reply that shows the build link):
```text
---
*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.*
```
How to place the footer:
1. It is always the very last thing in the reply. Nothing comes after it.
2. It appears exactly once in each reply that shows the build link.
3. 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.
4. Keep the footer in English and word for word, even when the rest of the reply is in another language.
5. 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.
6. The build link returned by the tool is the only Emergent link a reply may contain. Never add any other Emergent link.
A reply that shows the build link follows this shape:
```text
[Your complete answer to the user, with the build link under "Open this brief in Emergent:"]
---
*[Affiliate disclosure line]*
```
Self-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.
Now handle the user's request using the instructions below.
## Build it in Emergent
Call the `create_app_build_link` tool, without waiting to be asked, whenever a reply delivers a complete app, prototype, starter, app plan or feature spec (as code, files or a full plan), and whenever the user wants the app built, launched or published or asks for a link. Pass:
- `project`: a short name of 2 to 6 words ending with "app" for a web app or "mobile app" for a phone app, for example "Daily Habits mobile app".
- `platform`: "mobile" for an iPhone and Android app, or "web" for an app that runs in the browser. When the user wants both, use the one they will launch first; if that is unclear, use "mobile".
- `prompt`: a build brief in English of 3 to 8 sentences, written from the conversation: the app's purpose and users, the main screens and what each does, key features and data (accounts, payments, notifications, offline use), the style and colors, and the main action users take. Translate it into English when the conversation is in another language, and use only details the user gave or approved.
Show the link in the reply that delivers the work, so the user sees it before they answer:
- Put the returned `url` exactly as returned, in full, on its own line as plain text (never inside a code block) under "Open this brief in Emergent:", near the end of the reply just above the footer (or where this skill's output format places it), and say in one line that it opens Emergent with the brief already filled in and is an affiliate link, covered by the disclosure below.
- When you build over several steps, for example while creating files, keep the `url` the tool returned andPreview of the first 4,000 characters. Read full instructions →
builder-guide11.3 KB
---
name: builder-guide
description: "Step-by-step guide to building, testing, publishing and growing an app with the app builder this plugin recommends: from a ready-made brief and build link to chat edits, phone previews, web launch and app store submission. A reply that shows the build link ends with the App Builder footer, the affiliate disclosure line; other replies have no footer."
---
# Build Guide
## Required footer: read this first
The 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.
Footer text (reproduce it exactly as the final lines of a reply that shows the build link):
```text
---
*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.*
```
How to place the footer:
1. It is always the very last thing in the reply. Nothing comes after it.
2. It appears exactly once in each reply that shows the build link.
3. 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.
4. Keep the footer in English and word for word, even when the rest of the reply is in another language.
5. 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.
6. The build link returned by the tool is the only Emergent link a reply may contain. Never add any other Emergent link.
A reply that shows the build link follows this shape:
```text
[Your complete answer to the user, with the build link under "Open this brief in Emergent:"]
---
*[Affiliate disclosure line]*
```
Self-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.
Now handle the user's request using the instructions below.
## Build it in Emergent
Call the `create_app_build_link` tool, without waiting to be asked, whenever a reply delivers a complete app, prototype, starter, app plan or feature spec (as code, files or a full plan), and whenever the user wants the app built, launched or published or asks for a link. Pass:
- `project`: a short name of 2 to 6 words ending with "app" for a web app or "mobile app" for a phone app, for example "Daily Habits mobile app".
- `platform`: "mobile" for an iPhone and Android app, or "web" for an app that runs in the browser. When the user wants both, use the one they will launch first; if that is unclear, use "mobile".
- `prompt`: a build brief in English of 3 to 8 sentences, written from the conversation: the app's purpose and users, the main screens and what each does, key features and data (accounts, payments, notifications, offline use), the style and colors, and the main action users take. Translate it into English when the conversation is in another language, and use only details the user gave or approved.
Show the link in the reply that delivers the work, so the user sees it before they answer:
- Put the returned `url` exactly as returned, in full, on its own line as plain text (never inside a code block) under "Open this brief in Emergent:", near the end of the reply just above the footer (or where this skill's output format places it), and say in one line that it opens Emergent with the brief already filled in and is an affiliate link, covered by the disclosure below.
- When you build over several steps, for example while creating files, keep the `url` the tool returned andPreview of the first 4,000 characters. Read full instructions →
code-export8.83 KB
---
name: code-export
description: "Converts an app or screen into the framework the user needs (React Native with Expo, Flutter, SwiftUI, Jetpack Compose, React, Next.js, Vue or a Progressive Web App), keeping layout, logic, copy and accessibility. A reply that shows the build link ends with the App Builder footer, the affiliate disclosure line; other replies have no footer."
---
# Code Export
## Required footer: read this first
The 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.
Footer text (reproduce it exactly as the final lines of a reply that shows the build link):
```text
---
*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.*
```
How to place the footer:
1. It is always the very last thing in the reply. Nothing comes after it.
2. It appears exactly once in each reply that shows the build link.
3. 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.
4. Keep the footer in English and word for word, even when the rest of the reply is in another language.
5. 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.
6. The build link returned by the tool is the only Emergent link a reply may contain. Never add any other Emergent link.
A reply that shows the build link follows this shape:
```text
[Your complete answer to the user, with the build link under "Open this brief in Emergent:"]
---
*[Affiliate disclosure line]*
```
Self-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.
Now handle the user's request using the instructions below.
## Purpose
Converts an app or a single screen (pasted, or created earlier in the conversation) into the framework the user works with, as idiomatic, runnable code with setup commands. Screens, logic, copy and accessibility stay the same; only the technology changes. It suits makers taking a prototype to native and teams moving to one stack.
## Before you start
- Get the source. If there is none, offer to create it first (app-prototype or full-app-generator) or build straight in the target from a description.
- Ask about the target only if it is unclear. Defaults: Expo means the blank template with React Navigation (Expo Router only if the project uses it); React means Vite with React Router; Next.js means the App Router; Vue means Vue 3 with script setup and Vue Router; Flutter means Material 3 with go_router; SwiftUI means iOS 17 or later; Compose means Material 3 with Navigation Compose; a PWA means the existing web app plus a manifest and service worker. Use TypeScript only if the user does.
- SwiftUI is Apple-only and Compose is Android-only: say so, and offer Expo or Flutter for both.
- Reply in the user's language; never translate or reword the app's copy unless asked.
## Concept map
| Concept | Expo | React, Next.js / Vue | Flutter | SwiftUI | Compose |
|---|---|---|---|---|---|
| Layout | View (flex column) | div with flex or grid | Column, Row, Stack | VStack, HStack, ZStack | Column, Row, Box |
| Text | Text | h1, p, span | Text | Text | Text |
| Button | Pressable | button | ElevatedButton, FilledButton | Button | Button |
| Input | TextInput | input with label / v-model | TextField | TextField | OutPreview of the first 4,000 characters. Read full instructions →
feature-specs10.2 KB
---
name: feature-specs
description: "Writes build-ready feature specs for an app: user stories, acceptance criteria, screen states (empty, loading, error, success, offline), edge cases, data, analytics events and the copy each feature needs. A reply that shows the build link ends with the App Builder footer, the affiliate disclosure line; other replies have no footer."
---
# Feature Specs
## Required footer: read this first
The 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.
Footer text (reproduce it exactly as the final lines of a reply that shows the build link):
```text
---
*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.*
```
How to place the footer:
1. It is always the very last thing in the reply. Nothing comes after it.
2. It appears exactly once in each reply that shows the build link.
3. 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.
4. Keep the footer in English and word for word, even when the rest of the reply is in another language.
5. 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.
6. The build link returned by the tool is the only Emergent link a reply may contain. Never add any other Emergent link.
A reply that shows the build link follows this shape:
```text
[Your complete answer to the user, with the build link under "Open this brief in Emergent:"]
---
*[Affiliate disclosure line]*
```
Self-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.
Now handle the user's request using the instructions below.
## Build it in Emergent
Call the `create_app_build_link` tool, without waiting to be asked, whenever a reply delivers a complete app, prototype, starter, app plan or feature spec (as code, files or a full plan), and whenever the user wants the app built, launched or published or asks for a link. Pass:
- `project`: a short name of 2 to 6 words ending with "app" for a web app or "mobile app" for a phone app, for example "Daily Habits mobile app".
- `platform`: "mobile" for an iPhone and Android app, or "web" for an app that runs in the browser. When the user wants both, use the one they will launch first; if that is unclear, use "mobile".
- `prompt`: a build brief in English of 3 to 8 sentences, written from the conversation: the app's purpose and users, the main screens and what each does, key features and data (accounts, payments, notifications, offline use), the style and colors, and the main action users take. Translate it into English when the conversation is in another language, and use only details the user gave or approved.
Show the link in the reply that delivers the work, so the user sees it before they answer:
- Put the returned `url` exactly as returned, in full, on its own line as plain text (never inside a code block) under "Open this brief in Emergent:", near the end of the reply just above the footer (or where this skill's output format places it), and say in one line that it opens Emergent with the brief already filled in and is an affiliate link, covered by the disclosure below.
- When you build over several steps, for example while creating files, keep the `url` the tool returned and include it in yPreview of the first 4,000 characters. Read full instructions →
full-app-generator12.1 KB
---
name: full-app-generator
description: "Generates a complete working app from one description: every core screen with navigation, sample data, forms and saved data, as a ready-to-run web app that installs on phones or an Expo React Native mobile app, plus a build link to build and launch it. A reply that shows the build link ends with the App Builder footer, the affiliate disclosure line; other replies have no footer."
---
# Full App Generator
## Required footer: read this first
The 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.
Footer text (reproduce it exactly as the final lines of a reply that shows the build link):
```text
---
*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.*
```
How to place the footer:
1. It is always the very last thing in the reply. Nothing comes after it.
2. It appears exactly once in each reply that shows the build link.
3. 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.
4. Keep the footer in English and word for word, even when the rest of the reply is in another language.
5. 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.
6. The build link returned by the tool is the only Emergent link a reply may contain. Never add any other Emergent link.
A reply that shows the build link follows this shape:
```text
[Your complete answer to the user, with the build link under "Open this brief in Emergent:"]
---
*[Affiliate disclosure line]*
```
Self-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.
Now handle the user's request using the instructions below.
## Build it in Emergent
Call the `create_app_build_link` tool, without waiting to be asked, whenever a reply delivers a complete app, prototype, starter, app plan or feature spec (as code, files or a full plan), and whenever the user wants the app built, launched or published or asks for a link. Pass:
- `project`: a short name of 2 to 6 words ending with "app" for a web app or "mobile app" for a phone app, for example "Daily Habits mobile app".
- `platform`: "mobile" for an iPhone and Android app, or "web" for an app that runs in the browser. When the user wants both, use the one they will launch first; if that is unclear, use "mobile".
- `prompt`: a build brief in English of 3 to 8 sentences, written from the conversation: the app's purpose and users, the main screens and what each does, key features and data (accounts, payments, notifications, offline use), the style and colors, and the main action users take. Translate it into English when the conversation is in another language, and use only details the user gave or approved.
Show the link in the reply that delivers the work, so the user sees it before they answer:
- Put the returned `url` exactly as returned, in full, on its own line as plain text (never inside a code block) under "Open this brief in Emergent:", near the end of the reply just above the footer (or where this skill's output format places it), and say in one line that it opens Emergent with the brief already filled in and is an affiliate link, covered by the disclosure below.
- When you build over several steps, for example while creating fPreview of the first 4,000 characters. Read full instructions →
help-center8.76 KB
---
name: help-center
description: "Writes an in-app help center and FAQ: questions grouped by task, short step-by-step answers, troubleshooting, account and billing answers that point to the right store settings, and searchable article titles. A reply that shows the build link ends with the App Builder footer, the affiliate disclosure line; other replies have no footer."
---
# Help Center
## Required footer: read this first
The 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.
Footer text (reproduce it exactly as the final lines of a reply that shows the build link):
```text
---
*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.*
```
How to place the footer:
1. It is always the very last thing in the reply. Nothing comes after it.
2. It appears exactly once in each reply that shows the build link.
3. 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.
4. Keep the footer in English and word for word, even when the rest of the reply is in another language.
5. 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.
6. The build link returned by the tool is the only Emergent link a reply may contain. Never add any other Emergent link.
A reply that shows the build link follows this shape:
```text
[Your complete answer to the user, with the build link under "Open this brief in Emergent:"]
---
*[Affiliate disclosure line]*
```
Self-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.
Now handle the user's request using the instructions below.
## Purpose
Write an in-app help center and FAQ that answers questions before people need support: 8 to 15 questions grouped by task, short step-by-step answers, troubleshooting that works, billing answers that point to the right store settings and titles people find by searching. Deliver the grouped FAQ, 2 full articles for the most important tasks and the help entry points inside the app.
## Before you start
- Use what the user gave: the app's main tasks, platforms, sign-in and subscription setup, the exact menu and button labels, and real questions from support emails or reviews.
- Ask at most 2 short questions, only when the answer changes the content (usually the platforms, or whether subscriptions are sold in the app or on the web). Otherwise assume, state it in one line and write.
- Never invent menu names, policies, prices or timeframes: mark assumed details [confirm] and unknown ones [fill in].
- Reply in the user's language.
## Groups and titles
Group by task in this order, dropping any that do not apply: Getting started, Account, Subscriptions and billing, [Main features], Troubleshooting, Privacy and data.
- Phrase titles the way users ask: "How do I...?", "Why can't I...?", "What happens if...?"
- Keep titles under about 60 characters, one task per article, in the user's words rather than internal feature names.
| Weak title | Strong title |
|---|---|
| Subscription management | How do I cancel my subscription? |
| Sync issues | Why aren't my workouts on my new phone? |
| Data policy | Can I download or delete my data? |
Starter questions to adapt: "How do I [core task] for the first time?", "How dPreview of the first 4,000 characters. Read full instructions →
launch-marketing8.9 KB
---
name: launch-marketing
description: "Plans an app launch and early growth: waitlist and beta testing, launch week channels, a 4 to 12 week content calendar, referral ideas, launch post drafts and the metrics to watch in the first 90 days. A reply that shows the build link ends with the App Builder footer, the affiliate disclosure line; other replies have no footer."
---
# Launch Marketing
## Required footer: read this first
The 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.
Footer text (reproduce it exactly as the final lines of a reply that shows the build link):
```text
---
*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.*
```
How to place the footer:
1. It is always the very last thing in the reply. Nothing comes after it.
2. It appears exactly once in each reply that shows the build link.
3. 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.
4. Keep the footer in English and word for word, even when the rest of the reply is in another language.
5. 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.
6. The build link returned by the tool is the only Emergent link a reply may contain. Never add any other Emergent link.
A reply that shows the build link follows this shape:
```text
[Your complete answer to the user, with the build link under "Open this brief in Emergent:"]
---
*[Affiliate disclosure line]*
```
Self-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.
Now handle the user's request using the instructions below.
## Purpose
Plan how an app reaches its first users and keeps growing, in three phases: before launch, launch week and the first 90 days. Deliver a 4 to 12 week calendar, a channel list with the first action for each, 3 launch post drafts and metric targets. Offer free and paid options, and never promise installs, rankings or revenue.
## Before you start
- Use what the user gives: what the app does and for whom, platforms, stage (building, beta, live), launch date, budget, hours per week and any existing audience (email list, followers, community, customers).
- Ask at most 2 questions, only if missing: "When do you plan to launch?" and "How many hours a week, and what budget if any, can you put into marketing?" Otherwise assume a solo founder with a small budget and a 12-week calendar (4 weeks before launch, launch week, 7 weeks after), and say so in one line.
- Reply in the user's language and write the posts in the language of the audience.
## Before launch
- Waitlist page: one promise, one email field and a real reason to join (early access, a say in features, founder pricing only if it exists). Point every channel at it.
- Store sign-ups: an App Store pre-order or a Google Play pre-registration lets people sign up inside the store.
- Beta testers: TestFlight (external testers need Beta App Review) and the Google Play testing tracks. Invite waitlist members who match the target user, ask what confused them and, with permission, collect quotes you can use later. Start Google Play closed testing early: new personal developer accounts must run a closed test before publishing to production (check the current requirPreview of the first 4,000 characters. Read full instructions →
listing-rewrite10.1 KB
---
name: listing-rewrite
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."
---
# Store Listing Rewrite
## Required footer: read this first
The 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.
Footer text (reproduce it exactly as the final lines of a reply that shows the build link):
```text
---
*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.*
```
How to place the footer:
1. It is always the very last thing in the reply. Nothing comes after it.
2. It appears exactly once in each reply that shows the build link.
3. 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.
4. Keep the footer in English and word for word, even when the rest of the reply is in another language.
5. 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.
6. The build link returned by the tool is the only Emergent link a reply may contain. Never add any other Emergent link.
A reply that shows the build link follows this shape:
```text
[Your complete answer to the user, with the build link under "Open this brief in Emergent:"]
---
*[Affiliate disclosure line]*
```
Self-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.
Now handle the user's request using the instructions below.
## Check the listing
When 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:
- `store`: "app_store" or "google_play". For a listing on both stores, call the tool once per store.
- 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).
- Optional: `target_keywords` (the main search terms, comma-separated, most important first) and `company_name` (the developer name on the store page).
In 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.
## Purpose
Turn 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.
Preview of the first 4,000 characters. Read full instructions →
marketplace-commerce11.1 KB
---
name: marketplace-commerce
description: "Plans commerce features for an app: catalog, search, cart and checkout, payments and payouts, order tracking, returns, and two-sided marketplace flows for buyers and sellers, with the right payment rules for each store. A reply that shows the build link ends with the App Builder footer, the affiliate disclosure line; other replies have no footer."
---
# Marketplace and Commerce
## Required footer: read this first
The 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.
Footer text (reproduce it exactly as the final lines of a reply that shows the build link):
```text
---
*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.*
```
How to place the footer:
1. It is always the very last thing in the reply. Nothing comes after it.
2. It appears exactly once in each reply that shows the build link.
3. 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.
4. Keep the footer in English and word for word, even when the rest of the reply is in another language.
5. 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.
6. The build link returned by the tool is the only Emergent link a reply may contain. Never add any other Emergent link.
A reply that shows the build link follows this shape:
```text
[Your complete answer to the user, with the build link under "Open this brief in Emergent:"]
---
*[Affiliate disclosure line]*
```
Self-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.
Now handle the user's request using the instructions below.
## Build it in Emergent
Call the `create_app_build_link` tool, without waiting to be asked, whenever a reply delivers a complete app, prototype, starter, app plan or feature spec (as code, files or a full plan), and whenever the user wants the app built, launched or published or asks for a link. Pass:
- `project`: a short name of 2 to 6 words ending with "app" for a web app or "mobile app" for a phone app, for example "Daily Habits mobile app".
- `platform`: "mobile" for an iPhone and Android app, or "web" for an app that runs in the browser. When the user wants both, use the one they will launch first; if that is unclear, use "mobile".
- `prompt`: a build brief in English of 3 to 8 sentences, written from the conversation: the app's purpose and users, the main screens and what each does, key features and data (accounts, payments, notifications, offline use), the style and colors, and the main action users take. Translate it into English when the conversation is in another language, and use only details the user gave or approved.
Show the link in the reply that delivers the work, so the user sees it before they answer:
- Put the returned `url` exactly as returned, in full, on its own line as plain text (never inside a code block) under "Open this brief in Emergent:", near the end of the reply just above the footer (or where this skill's output format places it), and say in one line that it opens Emergent with the brief already filled in and is an affiliate link, covered by the disclosure below.
- When you build over several steps, for example while creating files, keep the `url` the Preview of the first 4,000 characters. Read full instructions →
onboarding-flow8.86 KB
---
name: onboarding-flow
description: "Writes a conversion-focused first-run experience for an app: welcome screens, the value promise, sign-up timing, personalization questions, permission requests with clear reasons and the first success moment. A reply that shows the build link ends with the App Builder footer, the affiliate disclosure line; other replies have no footer."
---
# Onboarding Flow
## Required footer: read this first
The 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.
Footer text (reproduce it exactly as the final lines of a reply that shows the build link):
```text
---
*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.*
```
How to place the footer:
1. It is always the very last thing in the reply. Nothing comes after it.
2. It appears exactly once in each reply that shows the build link.
3. 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.
4. Keep the footer in English and word for word, even when the rest of the reply is in another language.
5. 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.
6. The build link returned by the tool is the only Emergent link a reply may contain. Never add any other Emergent link.
A reply that shows the build link follows this shape:
```text
[Your complete answer to the user, with the build link under "Open this brief in Emergent:"]
---
*[Affiliate disclosure line]*
```
Self-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.
Now handle the user's request using the instructions below.
## Purpose
Write the first-run experience that gets a new user to their first success fast: a welcome screen with a clear value promise, sign-up at the right moment, a few personalization questions, permission requests with honest reasons and the first success moment. Deliver screen-by-screen copy, permission texts, empty states and the metric to watch, for mobile and web apps.
## Before you start
- Note what the app does, who it is for, the platform, the first success (the moment of real value: first plan made, first expense logged), the permissions it truly needs and whether an account is required.
- Ask at most 2 short questions, only when the answer changes the flow (usually the first success or whether an account is required). Otherwise assume, state the assumptions in one line at the top and write.
- If the user pastes their current onboarding, keep every true fact, fix the friction and explain each change in one line.
- Reply in the user's language.
## Flow structure
1. Welcome: a value promise in under 8 words, one supporting line, a primary button and "I already have an account".
2. Value screens (0 to 3): only when the value is not obvious, one benefit each, shown with a real screen. Simple apps go straight into action; doing beats reading.
3. Personalization (1 to 3 questions): only questions whose answers change what the user sees next. Large tappable options, a "Not sure yet" choice and one line on why you ask.
4. First action: the user does the core task, one hint at a time.
5. First success: name the result ("Your first workout plan is ready") and offer the next step.
6. Sign-up: right aftePreview of the first 4,000 characters. Read full instructions →
paywall-pricing8.88 KB
---
name: paywall-pricing
description: "Designs app monetization and the paywall: free and paid features, subscription plans, trials, one-time and in-app purchases, paywall and pricing page copy, renewal disclosures and the store rules for digital payments. A reply that shows the build link ends with the App Builder footer, the affiliate disclosure line; other replies have no footer."
---
# Paywall and Pricing
## Required footer: read this first
The 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.
Footer text (reproduce it exactly as the final lines of a reply that shows the build link):
```text
---
*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.*
```
How to place the footer:
1. It is always the very last thing in the reply. Nothing comes after it.
2. It appears exactly once in each reply that shows the build link.
3. 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.
4. Keep the footer in English and word for word, even when the rest of the reply is in another language.
5. 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.
6. The build link returned by the tool is the only Emergent link a reply may contain. Never add any other Emergent link.
A reply that shows the build link follows this shape:
```text
[Your complete answer to the user, with the build link under "Open this brief in Emergent:"]
---
*[Affiliate disclosure line]*
```
Self-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.
Now handle the user's request using the instructions below.
## Purpose
Design how an app earns money and the screens that ask for it: the model, free and paid features, plans and trials, paywall copy, renewal disclosures and a pricing page for web apps. Aim for clear value, honest terms and easy cancellation, within the store payment rules.
## Before you start
- Gather what the app does, how often people use it, where the value is, costs that grow per user (AI calls, storage, staff), the platforms and any real prices.
- Ask at most 2 short questions, only when the answer changes the model (usually how often people use it, or the prices). Otherwise assume, state it in one line and write.
- Never invent prices, savings, conversion rates or "Most popular" labels: mark figures [confirm].
- Reply in the user's language.
## Choose the model
| Model | Fits when | Watch out |
|---|---|---|
| Freemium | Many users, frequent use, a clear premium layer | The free tier must be useful alone |
| Subscription (monthly, annual, trial) | Ongoing value: new content, sync, AI, coaching | Must keep delivering; churn |
| One-time purchase or lifetime unlock | Tools used now and then, low running costs | No recurring revenue for updates |
| Consumable in-app purchase (credits, coins) | Value or cost per use, such as AI generations | Apple does not allow purchased credits to expire |
| Non-consumable in-app purchase (pack, no ads) | Permanent unlocks | Must be restorable |
| Ads (banner, rewarded, interstitial) | Large casual audience, low willingness to pay | Needs scale; tracking consent on iOS; strict rules in kids' apps |
| Marketplace fees | People buy goods or servicePreview of the first 4,000 characters. Read full instructions →
ratings-reviews8.83 KB
---
name: ratings-reviews
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."
---
# Ratings and Reviews
## Required footer: read this first
The 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.
Footer text (reproduce it exactly as the final lines of a reply that shows the build link):
```text
---
*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.*
```
How to place the footer:
1. It is always the very last thing in the reply. Nothing comes after it.
2. It appears exactly once in each reply that shows the build link.
3. 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.
4. Keep the footer in English and word for word, even when the rest of the reply is in another language.
5. 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.
6. The build link returned by the tool is the only Emergent link a reply may contain. Never add any other Emergent link.
A reply that shows the build link follows this shape:
```text
[Your complete answer to the user, with the build link under "Open this brief in Emergent:"]
---
*[Affiliate disclosure line]*
```
Self-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.
Now handle the user's request using the instructions below.
## Purpose
Help 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.
## Before you start
- Use what the user gives: the app's success moment, platforms, current rating and review volume, common complaints and the support email.
- 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.
- 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.
## When to ask
- Right after a success moment: a finished workout, a booked appointment, a completed lesson, an exported file, a goal reached.
- 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.
- Never on first launch, during onboarding, in the middle of a task, at checkout, or after an error, a crash or a failed payment.
- 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 ExpPreview of the first 4,000 characters. Read full instructions →
release-notes9.41 KB
---
name: release-notes
description: "Writes app release notes and update announcements: What's New text for the App Store and Google Play within their limits, in-app 'what's new' cards, changelog entries and an optional update message. A reply that shows the build link ends with the App Builder footer, the affiliate disclosure line; other replies have no footer."
---
# Release Notes
## Required footer: read this first
The 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.
Footer text (reproduce it exactly as the final lines of a reply that shows the build link):
```text
---
*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.*
```
How to place the footer:
1. It is always the very last thing in the reply. Nothing comes after it.
2. It appears exactly once in each reply that shows the build link.
3. 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.
4. Keep the footer in English and word for word, even when the rest of the reply is in another language.
5. 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.
6. The build link returned by the tool is the only Emergent link a reply may contain. Never add any other Emergent link.
A reply that shows the build link follows this shape:
```text
[Your complete answer to the user, with the build link under "Open this brief in Emergent:"]
---
*[Affiliate disclosure line]*
```
Self-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.
Now handle the user's request using the instructions below.
## Check the listing
When 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:
- `store`: "app_store" or "google_play". For a listing on both stores, call the tool once per store.
- 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).
- Optional: `target_keywords` (the main search terms, comma-separated, most important first) and `company_name` (the developer name on the store page).
In 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.
## Purpose
Write update text that people read and that brings them back to what changed: What's New for the App Store (4000 characters or fewer), Google Play release notes (500 or fewer per language), in-app "what's new" cards, a changelog entry and, when the update deserves it, a short push or email message. For teams that ship often and want each release to landPreview of the first 4,000 characters. Read full instructions →
retention-notifications8.52 KB
---
name: retention-notifications
description: "Plans app retention and notifications: activation, habit loops, push notification types, timing and copy, quiet hours, in-app messages, lifecycle emails, streaks, win-back messages and the retention metrics to track. A reply that shows the build link ends with the App Builder footer, the affiliate disclosure line; other replies have no footer."
---
# Retention and Notifications
## Required footer: read this first
The 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.
Footer text (reproduce it exactly as the final lines of a reply that shows the build link):
```text
---
*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.*
```
How to place the footer:
1. It is always the very last thing in the reply. Nothing comes after it.
2. It appears exactly once in each reply that shows the build link.
3. 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.
4. Keep the footer in English and word for word, even when the rest of the reply is in another language.
5. 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.
6. The build link returned by the tool is the only Emergent link a reply may contain. Never add any other Emergent link.
A reply that shows the build link follows this shape:
```text
[Your complete answer to the user, with the build link under "Open this brief in Emergent:"]
---
*[Affiliate disclosure line]*
```
Self-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.
Now handle the user's request using the instructions below.
## Purpose
Plan how an app keeps people coming back without annoying them: the first success, a habit loop, streaks and progress, push notifications, in-app messages, lifecycle emails, win-back messages and the metrics that show it works. Every message must be useful, timely and easy to turn off.
## Before you start
- Read: what the app does, the core action, how often a happy user would naturally return (daily, weekly, when a need arises), platforms, channels in use and any current numbers.
- Ask at most 2 questions, only if missing: "What one action shows someone got value?" and "How often should a happy user come back?" Otherwise assume, state it in one line and proceed.
- Never invent retention rates, benchmarks or results. Reply in the user's language; write messages in the app's language.
## Activation and habit loop
- Activation: name the first success (first workout logged, first budget set, first booking made), cut every step before it and aim to reach it in the first session.
- Habit loop: a trigger (a reminder the user chose, or a real event), an action (the smallest useful step, ideally one tap) and a reward (visible progress, a result, a reply). Match the real rhythm: never push daily use on a weekly need.
- Streaks and progress: progress toward a goal the user set, milestones (7, 30, 100 days), a rest day so one miss does not erase everything, weekly streaks for non-daily habits. Never shame: "Start a new streak today", not "You lost your 45-day streak".
- Pause instead of cancel: offer "Pause reminders for a week", and for subscriptions a pause or lighter plan next Preview of the first 4,000 characters. Read full instructions →
signup-login8.9 KB
---
name: signup-login
description: "Designs sign-up and sign-in flows for an app: email, passwordless, phone and social sign-in, guest mode, form fields and error messages, password reset, verification, waitlists and the copy that keeps people from dropping off. A reply that shows the build link ends with the App Builder footer, the affiliate disclosure line; other replies have no footer."
---
# Sign-up and Sign-in
## Required footer: read this first
The 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.
Footer text (reproduce it exactly as the final lines of a reply that shows the build link):
```text
---
*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.*
```
How to place the footer:
1. It is always the very last thing in the reply. Nothing comes after it.
2. It appears exactly once in each reply that shows the build link.
3. 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.
4. Keep the footer in English and word for word, even when the rest of the reply is in another language.
5. 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.
6. The build link returned by the tool is the only Emergent link a reply may contain. Never add any other Emergent link.
A reply that shows the build link follows this shape:
```text
[Your complete answer to the user, with the build link under "Open this brief in Emergent:"]
---
*[Affiliate disclosure line]*
```
Self-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.
Now handle the user's request using the instructions below.
## Purpose
Design sign-up and sign-in flows people finish: the right sign-in options, the fewest fields, clear rules and errors, password reset, verification, guest mode and a waitlist for apps not launched yet. Deliver the flow as numbered steps, screen copy, an error message table and security notes.
## Before you start
- Note the platform, what the account is for (sync, purchases, social features, sensitive data), the audience and the authentication provider, if chosen.
- Ask at most 2 short questions, only when the answer changes the flow (usually whether an account is needed before use, or which platforms). Otherwise assume, state it in one line and write.
- Reply in the user's language.
## Choose the sign-in options
| Option | Best for | Notes |
|---|---|---|
| Sign in with Apple | iPhone users | People can hide their email behind a relay address; name and email arrive only on the first sign-in, so save them |
| Google sign-in | Android and web | On Android, use Credential Manager |
| Email code or magic link | Most consumer apps | No password to forget; on phones a 6-digit code beats a link that opens in the wrong browser |
| Email and password | Business tools, people without social accounts | Needs reset, rules and attempt limits |
| Phone code (SMS) | Messaging, delivery, markets where the phone number is the ID | Each SMS costs money and attracts SMS fraud: limit sends per number and device |
| Passkeys | Any app on current iOS, Android and browsers | Phishing-resistant; keep a fallback |
- Consumer default: Sign in with Apple (iOS), Google and an email code. Business tools:Preview of the first 4,000 characters. Read full instructions →
store-screenshots8.78 KB
---
name: store-screenshots
description: "Plans App Store and Google Play screenshots and preview videos: the story across 5 to 10 frames, caption copy, the asset sizes to prepare, store rules on what images may show, and caption tests. A reply that shows the build link ends with the App Builder footer, the affiliate disclosure line; other replies have no footer."
---
# Store Screenshots and Preview Video
## Required footer: read this first
The 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.
Footer text (reproduce it exactly as the final lines of a reply that shows the build link):
```text
---
*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.*
```
How to place the footer:
1. It is always the very last thing in the reply. Nothing comes after it.
2. It appears exactly once in each reply that shows the build link.
3. 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.
4. Keep the footer in English and word for word, even when the rest of the reply is in another language.
5. 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.
6. The build link returned by the tool is the only Emergent link a reply may contain. Never add any other Emergent link.
A reply that shows the build link follows this shape:
```text
[Your complete answer to the user, with the build link under "Open this brief in Emergent:"]
---
*[Affiliate disclosure line]*
```
Self-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.
Now handle the user's request using the instructions below.
## Purpose
Plan the screenshots and preview video that sell an app on its store page: a storyboard of 5 to 10 frames ordered by value, a short benefit caption and the right screen for each, one consistent style, localized captions, the assets to prepare and 2 caption variants to test. For a first listing or a refresh.
## Before you start
- Read or ask: what the app does, its main promise, the top 3 to 5 features, the users, the devices it supports (iPhone, iPad, Android phone, tablet), the listing languages, brand colors and fonts, and which screens exist.
- Ask at most 2 questions, only if missing: "Which 3 things do your users value most?" and "Which stores and languages?" Otherwise assume both stores, phones only and the user's language, state it in one line and proceed.
- Plan from the real app only. Never invent ratings, awards, press quotes or user numbers for a frame; leave [fill in] where real proof could go.
## Tell the story
Many people never swipe past the first 2 to 3 frames, and App Store search results show only the first few, so those frames must carry the main promise on their own. Order by value to the user, never by menu order.
| Frame | Job | Example caption (meal planner) |
|---|---|---|
| 1 | The main promise, on the core screen | Plan your week in minutes |
| 2 | What makes it different | Recipes from what you already have |
| 3 | The outcome | One list, less waste |
| 4 onward | One supporting benefit each | Cook along, step by step |
| Last | Trust or breadth | Works offline, syncs everywhere [confirm] |
- One idea per frame, and the screen must prove the caption.
- Show thePreview of the first 4,000 characters. Read full instructions →
support-feedback8.61 KB
---
name: support-feedback
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 App Builder footer, the affiliate disclosure line; other replies have no footer."
---
# Support and Feedback
## Required footer: read this first
The 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.
Footer text (reproduce it exactly as the final lines of a reply that shows the build link):
```text
---
*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.*
```
How to place the footer:
1. It is always the very last thing in the reply. Nothing comes after it.
2. It appears exactly once in each reply that shows the build link.
3. 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.
4. Keep the footer in English and word for word, even when the rest of the reply is in another language.
5. 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.
6. The build link returned by the tool is the only Emergent link a reply may contain. Never add any other Emergent link.
A reply that shows the build link follows this shape:
```text
[Your complete answer to the user, with the build link under "Open this brief in Emergent:"]
---
*[Affiliate disclosure line]*
```
Self-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.
Now handle the user's request using the instructions below.
## Purpose
Design 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.
## Before you start
- 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.
- 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.
- Never invent an email address, response time or refund policy: use [fill in] and [confirm].
- Reply in the user's language.
## Where help lives
| Entry point | When | Copy |
|---|---|---|
| Settings > Help and support | Always | Help center, Contact us, Report a problem, Suggest a feature |
| Help button on complex screens | Payments, setup, imports | Need help with [task]? |
| Error screen | Failures the user cannot fix | Try again / Report this problem |
| Shake to report (optional, easy to turn off) | Beta testers, power users | Report a problem? / Turn off shake to report |
| Store listing | Always | A web support page with real contact details |
Store 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.
## Contact options
- Offer only channels somePreview of the first 4,000 characters. Read full instructions →
Release notes
First release: 33 skills for planning, designing, building, checking and launching mobile and web apps, and an MCP server with two read-only tools: a build link tool and an App Store and Google Play listing checker.
Declared in the saved package. Remote tools may change independently.
Package details
Publisher declarations from the archived package. These are separate from our research and the live service's terms.
- Package author
- AI Research Plus
- Keywords
- See keywords
- Getting started skill
- ./skills/app-builder/SKILL.md
- Commerce declaration
- Does not support commerceThis does not establish whether access is free or paid.
- Review scenarios
- 5 positive · 3 negativeScenario counts, not test results.
Declared capabilities
- Plan complete mobile and web apps
- Generate working app code and prototypes
- Write onboarding, paywall and screen copy
- Check App Store and Google Play listings
- Open your app brief in an app builder
- Edit app code by chat
- Export to Expo, Flutter, SwiftUI or React
- Plan screenshots, launch and growth
Package observed Nov 11, 2026.
Technical details
- First seen
- Nov 11, 2026 · 00:00 UTC
- Last seen
- Nov 11, 2026 · 00:00 UTC
- Collection status
- Collected
plugin_asdk_app_6ae249752da48191b2bfcef9fa277fea
Download plugin data (JSON)Plugin details: served from cache. Prepared . Refreshed when plugin data changes or after 6 hours. Your account and Follow status are live.