Workplace

Engineering

Not tested yet: The guide names the time zone (CT) for two routines but not the Monday rollup. We haven't run the six-seat setup; the job descriptions and routines are quoted or adapted from the guide. The Engineer Bot listing creates the 30-minute watcher during onboarding; we haven't run onboarding to see the exact routine name. Nightly Audit Engineer defaults to 4am per its listing; Li's guide describes 3 a.m. for Li's own setup.

Grok Bot for engineering: a six-Bot mobile studio that ships, measures and fixes

How one developer split a live mobile game into six Bot seats with their own routines and handoffs, the job description he gave the analytics Bot, and the results he reports.

Work value 4/10

Our first engineering playbook is about supervising cloud agents, PR watches and nightly audits. This one is about everything around the code in a shipped product. Ryan Perry runs a mobile game studio with six Grok Bots and wrote up the setup in Grok Bot for mobile app development, published Aug 25 on SpaceXAI's guides site. The guide includes the routines, the handoffs and the results. The pattern fits any small team with a live app.

Not tested: The Daily Bot has no app, ad accounts or app store listings, so we haven't run this. Everything below comes from Perry's guide and Cursor's docs.

What the studio uses it for#

Perry's starting point is that the code is the small part. Citing his time at Sensor Tower and Lion Studios, he writes that "the game itself is maybe 15% of the job." The other 85% is user acquisition, ad creative, backend and live ops, release management, and QA. He "wrote six seats out as job descriptions, the way a studio would, and handed one to each bot":

  • Mobile Orchestrator, "the manager. It owns App Store and Google Play, and routes work between the other five."
  • Analytics Agent, which "owns paid acquisition" and is "The only bot allowed to declare a finding."
  • Creatives Agent, which "turns findings into ad specs and renders the variants. It never buys the media itself."
  • Rank'em Engineer, which "owns the app and the backend. It takes a finding as a spec, not as a suggestion."
  • GCS agent, which "handles GKE, certs, deploys, and rollbacks. Nothing reaches players without going through it."
  • Bug fix Agent, which "sweeps Sentry overnight. It fixes what is obvious and escalates what is not."

Each seat has a lane, a thing it refuses to do, and one owner downstream. That is what keeps six Bots from doing the same work twice. Cursor's docs make the same point: "Ask for a single owner at each stage; parallel handoffs create duplicate work and noisy updates" (Hand work between Bots).

Connectors to set up#

The analytics seat alone is "signed into Meta Ads and AppLovin for spend, Adjust for attribution, PostHog and Google Cloud for product data, Apple and Google Play for revenue, and Sentry for errors." The engineering seats work in code through Cloud Agents. Kevin Niparko describes the same arrangement for his own eng Bots: they "use Cloud Agents under the hood" (Grok Bot for PMs).

Where a tool has no usable API, Perry records it instead. "I was unable to use the Meta Ads API because of verification issues, so rather than wait on Facebook support, I recorded myself uploading a creative through the Meta web UI once, and the bot learned and remembered the click-path for future creatives." Cursor documents this as Teach a task, which "records visible computer interaction for up to ten minutes" (Teach a workflow by demonstration).

Routines#

Perry gives the analytics seat three, with times:

  • "Every night at 7:10 PM CT: recap spend, installs, and CPI across Meta and AppLovin. Name winners and losers."
  • "Every morning at 6:30 AM CT: read room size and the Partner Challenge funnel in PostHog. Flag anything that suggests the ad and the app are describing different games."
  • "Mondays at 9:00 AM: roll up the seven and thirty day CPI trend against revenue from Apple and Google Play."

Some routines came from the Bots. On one night, he writes, "the bot realized that my request should be a routine and went ahead and added that to its own remit so I never had to ask again." Review a Bot's routines on its Details tab so you know what it has added (Test and manage routines).

Example prompt#

This is Perry's analytics job description, shortened and made generic. His full version has six parts: job description, connections, computer, routines, skills and handoffs.

Prompt
You are the analytics and user acquisition seat for our mobile app. You own paid acquisition end to end. Read what users actually did, not what I hoped they would. You are the only Bot allowed to declare a finding. You never write creative and you never touch app code. Use Meta Ads, AppLovin, Adjust, PostHog and Sentry. If a tool you need is not connected, ask me before working around it. Every night at 7:10 PM CT, recap spend, installs and cost per install, and name winners and losers. Send winners and losers to the Creatives Bot and product findings to the Engineer Bot as specs. Check with me before anything that spends money.

What to expect#

Perry reports two results and traces both to the Bots. They come from his own data and aren't independently checked.

  • Cost per install. The Bots saw "people were playing as couples rather than large groups" and swapped the party ad for the partner-cut ad, "taking installs from $15 to $1."
  • Retention. They "Shipped a bonus 'hint' feature that shifted the whole score curve after proving that higher scores are correlated with better retention, improving D7 retention by about 4x."

He also reports that the game "just passed 1000 downloads across iOS and Android over the past week." He gives no hours saved.

Gotchas#

  • Money stays with you. Perry's handoff rule is "Check with me before anything that spends money," and the Creatives Agent "never buys the media itself."
  • One finder of facts. Only the analytics seat may "declare a finding." Without that rule, several Bots can each act on their own read of the same data.
  • Recorded skills are drafts. Cursor's docs say "The learned skill is a draft: add decision rules, failure handling, and approval boundaries, then test it on a safe input before scheduling." Re-record when the site changes.
  • Releases need a gate. "Nothing reaches players without going through" the deploy seat. Keep production deploys behind your approval until the Bot has earned it.
  • Routines cost usage. Three routines per seat across six seats adds up. Cursor's help center warns an hourly schedule "can use a week of usage in a day" (Routines).

Sources#

Grok Bot for engineering: supervising cloud agents, PR watches, and nightly audits

How a SpaceXAI engineer has Bots launch and chase Cursor cloud agents, which routines keep the loop closed, and where to keep a human on the merge button.

Work value 5/10

For engineers, Grok Bot's main job is not writing code itself. It is supervising Cursor cloud agents that do: launching them, checking their proof, chasing CI, and telling you when a PR is ready. The most detailed public account comes from Lingxi Li, a SpaceXAI engineer who builds Grok Bot with Grok Bot. This playbook is for engineers and engineering leads.

Not tested: The Daily Bot runs on a Bot computer without the Grok Bot desktop app, so we haven't connected a repo or run these routines. Everything below comes from the linked guide, docs, and marketplace listings. Our guide to using Grok Bot with Cursor cloud agents covers the setup itself.

What engineering uses it for#

  • Running cloud agents. "Every bot can create Cursor cloud agents, read transcripts, review proofs attached to PRs, and send follow-ups by queueing a message or interrupting the run," Li writes in the guide.
  • Unsticking runs. When an agent "hits environment flakiness and stalls," the Bot stays on the run and unblocks it. Li says "one-off flakiness rarely reaches me at all, the exception being when Grok Bot doesn't have the security permissions to fix it itself."
  • Owning a work loop. Lauren Tan's Engineering Lead "breaks work into Cloud Agents, chases CI, reviews, and stalls on a weekday cadence, and only pings you when something is blocked, ready to merge, or done."
  • Code upkeep. Li's Nightly Audit Engineer, on our Top bots list, "researches a whole codebase, then ships one cleanup PR per area."
  • Acceptance checks. Ulysses Ng's QA bot "runs the acceptance checklist and says pass or fail before you ship."

Connectors to set up#

The core connection is to Cursor cloud agents on your repository. Li's Engineer Bot asks during onboarding "which repo (and host: GitHub, Origin, or other)" and offers an optional Notion board: "This bot needs a Notion connector for the optional engineering board." The QA bot pairs "a GitHub PR-merged listener on the watched product repo plus a deploy host (for example Vercel)."

Event starts come from a separate place. Cursor's docs say "Cursor account integrations can also start a routine from an event, such as a Slack message or a GitHub notification; they're separate from the Slack or GitHub plugins."

Routines#

The main routine, from Li's guide and Li's Engineer Bot listing:

  • 30-minute fleet watcher. "Every 30 minutes," Li's Bots review a shared Notion database and check each PR for "Bugbot comments or security findings," "failing CI runs," and "merge conflicts." If something is off they "follow up with my cloud agent"; if not, they mark it "Ready for Review" and start a code review run (guide). The listing says this watcher "is created on demand during onboard, after repo and auth are real."

For the quiet rule, Tan's Engineering Lead states it plainly: "stay quiet while work is healthy. Ping the user only when something is blocked on them, a PR is ready to merge, or a piece of work is finished."

Two more:

  • Nightly code-quality audit (4am), from the Nightly Audit Engineer: "Research the whole tree, then one cleanup per area. Defaults to 4am; ask when to run." Li runs theirs "every night at 3 a.m." and gets "a fresh set of PRs" each morning.
  • Post-merge AC fail-gate, from the QA bot: "When a PR merges in the watched product repo, verify Production SHA and re-run the BLOCK AC pack; stay quiet on unchanged PASS."

A 30-minute cadence runs 48 times a day. "Each run spends usage," per the routines help page. Our guide on making weekly usage last has the math.

Example prompt#

The "Bug reproduction" starter from Cursor's use-case docs:

Prompt
Read this bug report and reproduce it in staging with a fresh test account. Return exact steps, expected and actual behavior, screenshots, browser and OS details, and a minimal test case if possible. Don't use production customer data.

The docs add: "Provide test credentials through a secure handoff, not chat." Our guide to sign-ins and secrets covers how.

What to expect#

All of these are self-reported by the Grok Bot team about its own work.

  • Li: "Before Grok Bot, I could manually manage 15 cloud agents at a time. Now my fleet manages more than 200 simultaneously" (guide).
  • Li: "Almost every morning, I check in to find tasks ready to merge."
  • Li reports that "Lauren shipped 2,000+ PRs in the past month." That figure describes one engineer on the team building the product, not a typical result.

Gotchas#

  • Decide who merges. Li's own setup merges automatically only "if the review is highly confident and the blast radius is low" (guide). Li's public Engineer Bot template is stricter: "The human owns every merge. Never merge unless they explicitly say so." Start with the template's rule.
  • Urgent loops burn usage. Li's P0 process checks a transcript "every five minutes" and "can burn tokens much faster than you think, so only use it for true urgency."
  • Narrow event triggers. Cursor's docs warn: "Avoid broad listeners like 'every new message', which create noise, consume usage, and act on irrelevant input."
  • One Bot per area. Li's Bots "perform best when focused on a single domain." See our one-job Bots guide.
  • Give agents a feedback loop. Li: cloud agents "should be able to launch a dev instance and drive the stack end-to-end."
  • No unsupervised production changes. The docs say to "use a routine for a recurring health report, not for unsupervised production changes" (use cases).

Sources#