Module 2: Engineering Workflows
This module shows how engineers at SpaceXAI run Grok Bot. Each lesson solves one problem, from the first outer-loop Bot around your coding agents to a team of Bots that runs while you sleep.
Set Up An Outer-Loop Bot That Manages Your Coding Agents
You already run coding agents. Each run still needs you to gather context, write the prompt, watch the run, review the result, and merge.
Matt Palmer, who works on Cursor and Grok Bot at SpaceXAI, moved that whole loop into one Bot he calls Loops. “I talk to Loops, and Loops talks to a coding agent.”
The loop you are handing over
Matt published Loops as a template. It describes itself as a generalized engineering outer loop that sits above coding agents and runs five stages.
The template adds one rule about scope. “You name the repo; it never guesses.”
Gather: the Bot builds context before anyone codes
Matt’s example is an update to the Cursor website. He asks Loops to look at contributions from three named teammates to learn their patterns.
He asks it to read competitors’ documentation for how they handle the same problems. He asks how the team can verify the solution. Once the Bot has that context, it drafts the prompt.
Prompt: a draft you edit, not a prompt you write
Loops provides a draft prompt and kicks off cloud agents. At that point Matt’s workflow shifts from Grok Bot to Cursor.
He writes prompts in a style he calls pstack, with heavy use of /goal and loops. The template describes it through three reference points, how, why, and unslop, and says the prompts carry testable proof. None of the sources define the format further.
Lingxi Li, an engineer at SpaceXAI, describes the same stage from his own Bots. When a Bot receives a task, from him or from Slack, it kicks off a cloud agent with his skills invoked.
His Bots also pick extra skills from his personal guidance:
- A design skill for visual work
- A React Native skill for code quality audits
- A review skill for architecture
- A product skill for opinionated product decisions
The prompt the Bot writes has the same shape as the five-part request you learned to write yourself.
Launch and watch: the Bot stays on the run so you don’t
Lingxi’s Bots create Cursor cloud agents, read transcripts, and review proofs attached to PRs.
Grok Bot monitors the transcript and artifacts such as screenshots. It notifies you when the run finishes, queues messages, or interrupts if anything goes wrong.
You describe what you need in plain words. Lingxi’s example:
You must verify the screenshot includes the changes I asked for, with
proof showing before vs. after.
Grok Bot continues until it meets that goal. “Everything is now just a message away. Want them to keep pushing 10 times before handing off to you? Just say so.”
Review and merge: what comes back to you
Lingxi’s Bots check each PR’s proof against the request. If the review is highly confident and the blast radius is low, the Bot merges automatically. Otherwise the PR waits for him.
The review rules, the 30-minute check, and the shared task board are in the lesson on the PR pipeline.
Start with one repo and one loop
The fastest start is to install the loops template. Templates copy a Bot’s skills, memories, and plugins without any private data. Matt compares them to a recipe: the same dish, in your kitchen, with your ingredients.
The template needs the GitHub and Cursor plugins, and a named repo.
If you build the Bot yourself, create one narrow Bot and give it one job. Run one task end to end before you add routines.
Goal: Run one outer loop end to end on one repo.
- Install the loops template, or create a Bot with the GitHub and Cursor plugins.
- Name one repo in its description. The Bot never guesses one.
- Send one task that states the proof you expect, such as before-and-after screenshots.
- When the Bot reports back, check the returned proof against your request.
Expected result: A PR with proof attached, and a Bot that waited for you at the review point you named.
Write A Bot’s Job Description
The Bot from the last lesson works, but its instructions live in one long chat. A written job description keeps the Bot on its lane, survives new conversations, and gives you a template for the next Bot.
Four parts of a working description
SpaceXAI publishes an x.ai guide by an engineer who runs a mobile game studio, Rank’em, with six Bots.
The studio builds a game, not a code tool. Its four-part format fits a code Bot without change.
Here is the full configuration of the studio’s Analytics Bot from the guide:
1. Job description
You are the analytics and user acquisition seat for Rank'em, a mobile
game studio run by six bots. You own paid acquisition end to end. Read
what players 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.
2. Connections
You are 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. If a tool you need is
not connected, ask me before working around it.
3. A computer in the cloud
Do this work on your own computer. Sign into Meta Ads Manager and click
through campaign setup yourself. Run on schedule whether or not my
laptop is on.
4. Routines
Every night at 7:10 PM CT: recap spend, installs, and CPI across Meta
and AppLovin. Name winners and losers.
The job line says what the Bot owns and what it refuses
The guide defines a job description as a system prompt that reads like a role, “the lane it owns, and the work it refuses.”
Each of the studio’s Bots carries a refusal.
| Bot | Owns | Refuses |
|---|---|---|
| Analytics | The only Bot allowed to declare a finding | Never writes creative, never touches app code |
| Creatives | Turns findings into ad specs | Never buys the media itself |
| Engineer | Takes a finding as a spec | Not as a suggestion |
| Deploy | Certs, deploys, and rollbacks | Nothing reaches players without it |
| Bug Fix | Fixes what is obvious | Escalates what is not |
Rules go in the description, tasks go in the conversation
According to SpaceXAI, the description holds rules that should remain true. The conversation holds task-specific instructions. Their pair of examples:
- Description: “Never send external messages without approval.”
- Message: “Draft follow-ups for these twelve accounts.”
Update the description when you discover a durable preference, boundary, or responsibility. Put explicit safety boundaries there too.
Name the connections, and say what to do when one is missing
The Rank’em connections block names each tool with its purpose. Then it ends with one rule. “If a tool you need is not connected, ask me before working around it.”
The author hit that case when the Meta Ads API failed verification. Rather than wait on support, they recorded one upload through the Meta web UI. The Bot kept the click-path for every creative after that.
One specialist per code area beats one general helper
Lingxi Li at SpaceXAI runs five engineer Bots, each with its own area.
They can work across each other’s areas. But each has a different memory and limited context, so they perform best inside one domain.
Grow the roster one stable role at a time
- Give one Bot ownership of an end-to-end outcome.
- Add another Bot only when the work has a stable specialist role.
- Put Bots in a group chat when the handoff itself needs to be visible.
- Keep external actions behind a clear approval boundary.
That is SpaceXAI’s advice. Your existing Bots can propose a focused Bot when a job needs a long-lived owner. Ask them to check with you first if you want the roster small.
To reuse a role for a new scope, duplicate the Bot. The copy carries the profile, settings, skills, routines, and avatar, but not the conversation history or learned memory.
Goal: Give your outer-loop Bot a written job description.
- Start from the four-part format: job, connections, computer, routines.
- Add the refusal line and the ask-first line.
- Move every rule that stays true from the chat into the description. Leave task instructions in the conversation.
Expected result: A Bot that holds its lane in a fresh conversation, and a description you can duplicate for the next role.
Give Agents A Complete Feedback Loop
A coding agent that cannot see the result of its own change stalls, guesses, or reports a success it never checked.
Lingxi Li at SpaceXAI names the fix as one key to a Bot engineering team that does not stop. Give the cloud agents a complete feedback loop, so they get signals about what to do next without you.
Launch a dev instance and drive the stack end to end
Lingxi’s rule is that agents should be able to launch a dev instance and drive the stack end to end. He names three surfaces.
- Chrome DevTools for the web
- The CLI for the terminal
- Apple Accessibility for native apps
If the agents cannot do that yet, ask them to work out how to run the flow themselves.
Ask for proof in the prompt
Cloud agents can take screenshots. Grok Bot uses its multimodality to confirm the agent applied the change, and pushes back when the result does not match the request.
Matt Palmer does the same for a Bot that tries out new technologies each morning. He gave it explicit verification parameters, screenshots and videos, and he inspects them from inside Grok Bot.
Those screenshots come from inside the Cursor agent that writes the code. Grok Bot can use the agent’s computer as well as its own.
Matt keeps his demos in one repo on Cloudflare, so each project gets a preview deployment the Bot can see. That gives him three ways to check a result.
- See a quick preview live in Grok Bot
- Open the app and play with it in his browser
- Drill into the code or continue to iterate in Cursor
Test what you cannot screenshot
Lingxi’s team hooked SpaceXAI’s voice API into the cloud agent’s system audio. The agent has both the spoken word and the transcript, so it can test speech-to-speech features across the product lineup.
Unblock aggressively
An agent that hits environment flakiness stalls until someone sends a follow-up. Grok Bot stays on the run and unblocks it as aggressively as it can.
One-off flakiness rarely reaches Lingxi any more. The exception is when Grok Bot lacks the security permission to fix it. Put the same rule in your prompt.
Package what the agent learns as a repo skill
Once an agent works out how to run the flow, Lingxi has it package what it learned into a reusable repo skill. The next agent starts from that skill. It does not repeat the discovery.
Goal: Close the loop so an agent can verify its own work.
- Confirm the agent can launch a dev instance and drive it end to end through DevTools, the CLI, or Accessibility.
- In your next task, ask for proof: before-and-after screenshots or a short video.
- Tell the agent to unblock itself as aggressively as it can.
- Tell it to save what it learns as a repo skill.
Expected result: A run that reaches proof without a follow-up prompt from you, and a repo skill the next agent starts from.
Automate The PR Pipeline And Nightly Audits
Your outer-loop Bot handles one task at a time in one chat. Once it runs twenty PRs, it loses track past the context limit, and you scroll long threads to find status. Routines and a shared board fix both.
Track work outside the chat
Lingxi Li at SpaceXAI has each engineer Bot manage a shared Notion database.
Each task is a row. The Bot moves it between states such as Working and Ready for Review, so he scans progress without a scroll through long chats.
The 30-minute PR check
Every 30 minutes, Lingxi’s Bots review the database and check each PR for three things.
- Bugbot comments or security findings, with a check on whether each one is legitimate
- Failing CI runs
- Merge conflicts
If they find anything off, they follow up with the cloud agent at once. The row moves back to Working.
If everything looks good, the Bot marks the task Ready for Review and starts a code review run. If the review is highly confident and the blast radius is low, it merges automatically.
Otherwise Lingxi reviews the code and the proof when he is back. Almost every morning he finds tasks ready to merge, with proofs that show what the agents tested.
Nightly audits keep the codebase clean
Every night at 3 a.m., Lingxi’s engineer Bots are awake. They clean up the codebase, sweep out dead logic, speed up app load time, and reduce bundle size.
Every morning he gets a fresh set of PRs. His list of more nightly audit ideas:
- Security audits to catch issues the team may have overlooked
- CI/CD build-time audits to keep build times short
- Internationalization audits to close gaps when features ship in only one language
- Parity audits to avoid drift when features land on only one of several clients, such as iOS versus desktop
- Catch-up audits that monitor PRs merged in the past 24 hours for one area, then hand back a summary and a curated list of PRs to review
And his favourite prompt of all:
“You have six hours tonight. Build whatever you want. Have fun!”
The P0 urgency routine
Cloud agents can be slow. When Lingxi says a task is P0, his Bots start a temporary routine. It checks the transcript every five minutes and steers the cloud agent when it starts to burn unnecessary time.
It works for codebase research and critical bug fixes alike. His warning: it burns tokens much faster than you think, so use it only for true urgency.
Write the routine so the Bot can run it unattended
To create a routine, SpaceXAI says to ask the Bot that should own the recurring job:
Every weekday at 8:00 AM, run the Daily customer-risk skill against the
current account list. Post a linked watch list in this conversation. Do
not contact customers. If the source data is unavailable, report the
failure instead of using old data.
- The owning Bot
- The schedule and time zone
- The input source
- The expected result
- The approval boundary
- What should happen when a source is missing
Background routines run while your laptop stays shut. A Bot can own up to 50 routines, and the app keeps the 20 most recent run records for each.
Start a routine from a Slack message or a GitHub notification
Account integrations can start a routine from an event. The docs note these are separate from the Slack and GitHub plugins and may need their own connection flow.
Define a narrow matching rule and a clear response:
When a message in #customer-escalations contains a support ticket link
and the phrase "needs repro," open the ticket, reproduce the issue in
staging, and post a repro pack in this conversation. Never post back to
Slack without approval.
Avoid broad listeners such as every new message. They create noise, consume usage, and raise the chance of action on irrelevant input.
This is the mechanism behind Lingxi’s Bots, which take tasks from Slack as well as from him.
Test before you enable
Use Test run after you create or edit a routine. A test run performs real work, so use safe inputs and keep write actions behind approval.
Review the run against the list below, then hold the routine to SpaceXAI’s rules before you enable it.
Tick each item against your routine. This browser remembers your ticks.
After a long period away, Grok Bot may ask whether to keep routines active. If there is no response, it pauses them. Review paused routines when you return.
Goal: Put the PR pipeline on a routine you can trust.
- Create a shared board with Working and Ready for Review columns, and tell the Bot to keep it current.
- Ask the Bot to create the 30-minute PR check routine. Confirm the six things above before you send.
- Run Test run with safe inputs. Confirm it stops at the approval point.
- Schedule one nightly audit.
Expected result: You wake up to a PR marked Ready for Review, with proof attached and the board already updated.
The Code: Your daily unfair advantage in software engineering.
Join 350,000+ software engineers, tech leads, and CTOs who start their morning with The Code.
Run A Team Of Bots
You have several specialist Bots and one outer-loop Bot, and every task still routes through you.
The practitioners in this lesson add three layers that take you out of the middle. A manager that delegates, an ops Bot that keeps the team aligned, and a channel per project.
A manager that delegates but never codes
Kevin Niparko, product lead at SpaceXAI and former product lead at Cursor, runs an engineering manager Bot named Emily. The EM “is NOT supposed code...just manage.”
Emily breaks down technical work, delegates to five IC engineering agents, and validates outputs against the goal. To onboard, she read all of one senior engineer’s Slack messages to learn what great looks like.
The IC agents use Cursor cloud agents under the hood. They manage many at once and coordinate with each other. “It’s agents all the way down!”
An ops Bot that runs 1:1s and postmortems
Lingxi Li at SpaceXAI has operational chores across his Bot org. New engineer Bots need onboarding, knowledge needs to reach the right Bot, incidents need postmortems, and the team needs daily meetings.
That is all Jenny’s job. She is his head of operations and the only Bot on the team that does not write code.
Every morning at 5 a.m., Jenny meets 1:1 with every Bot. They review the playbook, surface blockers, and reinforce the working style Lingxi wants.
The context limit cannot fit everything. A daily repeat of the key points is the nudge that keeps complex workflows in his Bots’ memory, even after many weeks.
One project, one channel, one roster
A second x.ai guide, by a SpaceXAI engineer, describes what happens when separate chats no longer scale. Several projects at once make it hard to separate signal from noise and keep the Bots in sync.
The author copied how human teams coordinate. Each project gets a Grok Bot channel and a row in a Notion Projects database, with a Tasks database beside it.
A Manager Bot with a Project Ops skill creates the project, opens the channel, and staffs it. The author calls it an experimental pattern.
The guide’s three staffing rules:
- Reuse existing Bots first, such as a Coder, Researcher, or Writer already defined.
- Propose at most five Bots besides the PM. Each channel holds at most six Bots.
- Create a new Bot only when nothing on the bench fits, and only after the author says yes.
Once the channel exists, the author scopes the project’s tasks with the roster. The PM watches progress and keeps the databases current.
When a Bot gets stuck, it marks its task Blocked and pings the author in the channel. Often the Bots accomplish a lot on their own, and the author just watches the cards move.
It is the same board idea as Lingxi’s PR database, one level up.
Kick off a group and hand work between Bots
According to SpaceXAI, use a group when several Bots need one shared outcome and visible handoffs. Describe the outcome and who owns the next step:
@Researcher gather the source material and link every claim. @Writer
turn the findings into a launch draft. @Reviewer check the draft
against the sources and list only blocking issues. Do not publish
anything.
Mention one Bot when it owns the request. Mention several only when the request needs each of them, and use @everyone sparingly.
A Bot can also message another Bot directly. The receiver wakes, does the work, and replies later. Handoff messages are text-only, so a Bot should send an image directly to the teammate that must inspect it.
One owner per stage
The docs list four cases where a handoff helps.
- One Bot owns a source system and another owns the deliverable
- A specialist should review a draft
- A blocker belongs to another role
- A long-running job should continue without you as the coordinator
Ask for a single owner at each stage. You keep control from outside the group. A direct message from you takes priority and can redirect the current turn, and “Stop now” ends work at once.
Goal: Take yourself out of the middle of the roster.
- Give one Bot the manager job, with a rule in its description that it never codes.
- Open one channel for one project with at most six Bots, and name a single owner for each stage.
- Send the kickoff message above, adapted to your project.
Expected result: Handoffs you can see in the channel, and a Blocked card that pings you only when a Bot needs input.
Cut Token Spend And Speed Things Up
Your Bots now run routines every 30 minutes and audits every night. Every browser click in those runs costs tokens, and the browser is the slowest way to do anything.
Four tactics cut the bill and the wait.
Turn one browser run into a script
Sam Sokolin, who builds Grok Bot at SpaceXAI, asks the Bot to reverse engineer expensive browser tasks into scripts.
The Bot captures the network requests from one computer-use run. Next time, it skips the UI and hits the APIs directly with the same auth. A script is also far faster than a Bot that clicks around in a GUI.
Sam later shared a Bot that does this conversion for you. Not My Tempo audits your other Bots’ inefficient routines and converts expensive computer-use tasks into scripts and connectors.
The Bot directory lists ready-made Bots like it.
Prefer a connector, fall back to the browser
According to SpaceXAI, a connector is often more reliable than clicks through a website. Use the browser only for services without a connector, or for visual workflows a connector does not expose.
To add one:
- Open Settings, then Plugins.
- Browse the available connectors and choose Add.
- Complete authentication in your browser if requested.
- In chat, type
@to attach the connector to the task.
Installed connectors are account-wide. Every Bot on your account can use them.
Teach by demonstration when the API is blocked
Some services block both paths. In the x.ai Rank’em guide, the Meta Ads API failed verification, so the author recorded one upload through the Meta web UI.
The Bot remembered the click-path. From then on it uploaded and tested at least one new creative per day.
This is the case the ask-first line in the job description lesson covers.
Run several Bots in parallel, and use a private worker for special setups
Each Bot gets its own screen on the shared computer, so several Bots can use browser and desktop tools at the same time. Cloud work continues when you close the app or the laptop.
Some workflows need VPN access or a special machine. For those, Lingxi Li makes a spare Mac mini a Cursor Cloud private worker and asks Grok Bot to run cloud agents there.
That unlocks the iOS Simulator, with screenshots back from the agents. You no longer need a dedicated machine at home that runs around the clock.
The five-minute P0 check is the fastest way to move one task. Lingxi’s warning stands. It burns tokens much faster than you think, so keep it for true urgency.
Goal: Cut the cost of one repeated browser task.
- Pick the routine that clicks through a web app most often.
- Ask the Bot to capture the network requests from one computer-use run.
- Ask it to turn those requests into a script that hits the API with the same auth.
- If a connector exists for that service, add it from Settings, then Plugins, and prefer it.
Expected result: The next run of that routine finishes faster and shows a smaller token cost.
Your Engineering Checklist
Here is the whole system as fifteen actions, in the order the module taught them. Each group maps to one lesson, so go back to that lesson if an item is unclear.
Tick each item when you complete it. Item 12 is the sign that the system runs without you. This browser remembers your ticks.
Tick the items above as you complete them.
By this point you should have:
- One outer-loop Bot on one repo that gathers context, drafts the prompt, launches the agent, and checks the proof
- A written job description with a refusal line and an ask-first line
- Agents that run the stack themselves, unblock themselves, and save what they learn as repo skills
- A 30-minute PR check and a nightly audit that run while you sleep
- A manager Bot and one channel per project, once the roster grows
- One browser task converted to a script
Module 3: Build With Grok Bot
Ready-made Grok Bots for each item on this list, installable from x.ai with one click.