Isolated machines
Each agent runs in its own cloud VM with a full development environment. It clones your repository, works on a separate branch and pushes the result back for review.
Why store prep is a good job for parallel agents
A store-readiness pass is a checklist of mostly independent fixes: legal pages, account deletion, mobile layout, error states, hiding web-only elements, review notes. In one long local session, these changes pile up into a single diff that is hard to review. Split across cloud agents, each task touches its own files, lands as its own pull request, and can be accepted, sent back or re-run alone.
The target is the same as in the end-to-end Cursor workflow: a web app that behaves like an app when WebViewGold loads it in a native WebView. This page covers only the parallel part, and what you still have to do yourself. Everything else about publishing Cursor projects is collected on the Cursor hub page.
What Cloud Agents are, in six facts
Many ways to start one
Choose Cloud under the agent input in Cursor, use cursor.com/agents on any device, mention @cursor in Slack or Linear, or comment @cursor on a GitHub issue or pull request.
Source control first
A Cursor account admin connects source control (GitHub, GitLab, Bitbucket Cloud or Azure DevOps), and the agent needs read-write access to the repository.
Secrets in the dashboard
Add API keys and test credentials as secrets in the Cursor dashboard instead of committing an .env file. They are injected when an agent starts, so agents already running do not see new ones.
They read AGENTS.md
Cursor's cloud agent docs state it plainly, so put the native-app context and store invariants into AGENTS.md, not only into .cursor/rules.
Usage-based cost
Runs are billed at the selected model's rate, and not every plan includes them. You set a spend limit on first use; keep it sensible before launching six at once.
Give every agent a working environment
Agents can set up the environment themselves (and save it as a snapshot), or you commit .cursor/environment.json. For a typical Node web app this is enough: install dependencies, run the dev server in a terminal the agent can see, expose the port. The field names come from Cursor's published schema; the terminal description is shown to the agent.
json
{
"install": "npm ci",
"terminals": [
{
"name": "web",
"command": "npm run dev -- --port 3000",
"description": "Dev server. Check changed routes here at 390 px and 320 px width."
}
],
"ports": [
{ "name": "web app", "port": 3000 }
]
}
With a good optimized version of your web app you can have a stunning mobile app within a couple of minutes. Additionally to that the customer service is very nice and very helpful! I can just recommend WebViewGold :-)
Add a cloud-agent section to AGENTS.md
Commit this to the default branch before you launch anything. The first block is the shared native-app context; the second block tells each agent how to behave as one of several workers.
markdown
## Native app (WebViewGold)
This web app also ships as iOS and Android apps. WebViewGold loads
https://app.example.com in a native WebView; every deploy is live in both apps.
- Detect the app only with isNativeApp() (user agent contains "MyAppNative").
- Native features are URL schemes from https://www.webviewgold.com/llms-full.txt.
Never invent one; always keep a web fallback.
- Store invariants: real /privacy and /terms; in-app account deletion (server-side);
Sign in with Apple next to any social login; no external checkout for digital
goods in the iOS app; loading, empty and error states; layout works at 320 px.
## Cloud agents
- One task per agent. Touch only the files the task needs. If you must edit a
shared layout file, say so at the top of the PR description.
- Run npm run lint, npm test and npm run build before you push.
- Check every route you changed in the browser at 390 px and 320 px and describe
what you saw in the PR.
- PR description: what changed, how you verified it, open questions, and what
needs a test on a real iPhone and Android phone.
- You cannot run the native app. Never claim you tested on iOS or Android.Split the pass into parallel tasks
| Agent | Task | Typical files | Done when |
|---|---|---|---|
| 1. Legal pages | Real /privacy and /terms based on what the code collects, linked from footer and settings | Routes, footer, settings screen | Both URLs load directly and name every SDK that collects data |
| 2. Account deletion | Delete account in settings plus a public /delete-account page; server deletes data, files and the auth user | Settings, API route, auth helpers | A test user is gone from the database and the auth provider (deletion requirements) |
| 3. States and dead ends | Loading, empty and error-with-retry states; a 404 page; remove "coming soon" buttons | Data components, router | Offline clicks show an error state, never a blank screen |
| 4. App mode | isNativeApp() helper; hide store badges, install prompts and builder badges inside the app | Platform helper, banners | Spoofing the user agent hides every web-only element |
| 5. Store drafts | docs/store/: review notes, description, keywords, a data inventory for App Privacy and Data safety | Docs only | Every data type in the inventory points to code in the repo |
| 6. Mobile layout (last) | Overflow, tap targets, safe-area padding, 16 px inputs, no hover-only controls | CSS, layout components | No horizontal scroll at 320 px on any main route |
One prompt template for all six agents
Keep the shared part identical so every pull request looks the same; only the task block changes. The example shows agent 2.
Paste into each Cloud Agent, swapping the TASK block
Context: this web app also ships as native iOS and Android apps through WebViewGold, which loads our production URL in a WKWebView and an Android WebView. Read AGENTS.md first and follow its "Native app" and "Cloud agents" sections. Rules for this run: - Work only on the task below. Do not refactor unrelated code or add dependencies unless the task needs them. - Run lint, tests and the production build before pushing. - Open a pull request titled "store-readiness: <task name>". In the description, list what changed, how you verified it (routes and widths), open questions, and what I must test on a real iPhone and Android phone. - If something is ambiguous, for example which tables hold user data, stop and ask in the pull request instead of guessing. TASK: Account deletion - Add a "Delete account" action in settings with a confirmation step. - On confirm, call a server-side endpoint that deletes the user's rows in every table that references the user, deletes the user's stored files and deletes the auth user. Then sign out and show a confirmation screen. - Add a public /delete-account page that explains the in-app steps and offers a way to request deletion without the app (form or email address). - Add a test that creates a user, deletes it, and asserts that no rows or files remain.
Run the pass
About an hour of setup, then mostly review time.
Connect source control and prepare the environment
An admin connects the repository provider in Cursor. Commit environment.json, or let the first agent set up the environment and save it as a snapshot so later agents start faster.
Commit AGENTS.md and .cursor/BUGBOT.md
Agents read AGENTS.md; Bugbot reads .cursor/BUGBOT.md (example below). Both must be on the default branch before the first launch.
Add secrets and a test account
Store the staging database URL, test credentials and API keys as dashboard secrets. Without a test login, agents cannot check signed-in screens and will tell you they "should work".
Launch agents 1 to 5 together
Start them from the agent input (Cloud), from cursor.com/agents, or create one GitHub issue per task and comment @cursor with the prompt. Start agent 6 after the others merge, because layout work touches the same components.
Review each pull request
Read the diff and the description, let Bugbot comment, and open the preview deployment on your phone browser. To ask for changes, comment @cursor on the pull request with what to fix.
Merge, deploy, test in the real app
Merge in a sensible order, deploy production, then test the WebViewGold build on real devices. Cloud agents cannot run the native app, so this step stays yours.
.cursor/BUGBOT.md: a store-review checklist for every pull request
Bugbot does not use your .cursor/rules files; it reads .cursor/BUGBOT.md (the root file always, nested ones near the changed files). It runs on every pull request update, and commenting cursor review or bugbot run triggers it by hand.
markdown
# Store review rules
This app ships as iOS and Android apps via WebViewGold (native WebView around our URL).
Flag as a bug:
- New fixed or sticky UI without env(safe-area-inset-*) padding.
- Tap targets smaller than 44 x 44 px, or hover-only interactions.
- OAuth opened via window.open, target="_blank" or a popup.
- A native URL scheme (registerpush://, shareapp://, bioauth:// ...) called without
an isNativeApp() check or without a web fallback.
- Purchase or upgrade buttons for digital goods that link to an external checkout
inside the native app.
- Removing or breaking /privacy, /terms, /delete-account or the Delete account action.
- Data fetching without loading, empty and error states.
- Secrets or service-role keys in client-side code.
Ignore: styling preferences, naming, and refactors that do not change behavior.What to check in every pull request
- The diff touches only files that match the task; unrelated changes are a reason to send it back.
- Lint, tests and build ran, and the description says so.
- Signed-in screens were really checked: the description names the test account, not "should work".
- No new SDK or tracker slipped in that you would have to declare in App Privacy and Data safety.
- Copy is real: no Lorem ipsum, no "Your Company Inc." in the privacy policy.
- Anything native (push, share, biometrics) sits behind isNativeApp() with a web fallback.
Pitfalls
- Several agents on the same files: merge conflicts eat the time you saved. Split by file area, not by idea.
- Agents that report "tested on iOS". They run in cloud VMs without your native app; real-device testing stays with you.
- A preview deployment URL copied into the WebViewGold config. Only the production domain goes into Config.swift and Config.java.
- Secrets committed because an agent "needed" them. Use dashboard secrets and rotate anything that reached the repository.
- Six agents on a large model add up. Start with two or three, check the quality of the pull requests, then scale.
- AGENTS.md and .cursor/rules disagreeing. Agents follow whichever they read; keep the invariants identical (how to keep one source).
Frequently asked questions
Are background agents and Cloud Agents the same thing?
Yes. Cursor renamed Background Agents to Cloud Agents. Older tutorials still use the old name; the idea is the same: an agent in an isolated cloud VM that works on its own branch and hands back the result.
Do Cloud Agents follow my .cursor/rules?
Cursor's cloud agent documentation explicitly says they read AGENTS.md, so that is the safe place for anything every agent must follow. Keep your project rules for local work, with the same invariants.
Can a Cloud Agent build the iOS app?
No. Building and signing an iOS app needs Xcode on macOS, and the agents work in cloud development environments. Build with Xcode on a Mac or with the WebViewGold Cloud Builder, which builds and uploads both apps from the browser.
Can I start an agent from a GitHub issue?
Yes. Once source control is connected, comment @cursor on an issue or a pull request with your instructions. One issue per readiness task also gives you a tidy record of what was done.
Will an agent merge into main by itself?
Cloud agents work on a separate branch and push it back for you to review. Protect your default branch anyway, so nothing reaches production without a human review.
How many agents should I run at once?
As many as you have independent tasks. Six fit this pass, but start with two or three until you trust the output, and run layout work last.
Three ways to get your app into the stores
Same result, different amount of work on your side. All three come with the approval guarantee and 24/7 human support.
Do it yourself
$109 per platform, one-time
The WebViewGold license: a finished Xcode or Android Studio project. Paste your URL, set name and icon, switch on features, build and submit. Free updates forever.
See plans on the main pageCloud Builder
$349 per license, one-time add-on
No Mac, no Xcode, no Android Studio: configure in the browser, we build both apps in the cloud and hand them to App Store Connect and the Play Console.
How the Cloud Builder works Try the free demoFull Service
$698 per platform $798
Send us your URL and icon. Our team configures, builds and delivers your app within 72 hours, white-label, with source projects. Both platforms for $1,158.
Full Service details Powered by
Winter Sale prices valid until December 31, 2026.