Grok Bot for Builders: The 6-Bot Setup That Ships While You Sleep (Full Guide)

Cover image

Every Grok Bot guide so far is about admin. Triage the inbox, chase leads, file receipts, draft posts.

Useful, but it is not what most people reading this actually do. You build things. And the reason your side project has been at 80% for three months is not that the code is hard - it is that shipping something takes six different kinds of work and you only have time to do one of them a night.

This is the setup for that. Six bots, each owning one lane of a build, handing work between them, running while you sleep.

Why this works differently for building

Grok Bot went into beta on 11 August. The mechanic that matters for builders is not the chat window - it is that your bots share one persistent cloud computer, with the same files, the same browser sessions, and the same logins.

That sounds like a small detail. It is the whole thing.

It means the bot that read your issue tracker and the bot that writes the code are looking at the same filesystem. It means you sign into GitHub once and every bot you ever create is signed in. It means handing work from one bot to another does not require re-explaining the project or re-authenticating anything - the context is already there.

For a build pipeline, that removes the step that kills every automation attempt: moving state between tools by hand.

What you need

Grok Bot ships as a desktop app for macOS and iOS at x.ai/bot. Access comes through Cursor Ultra at $200/month, SuperGrok Heavy at $300/month, or Cursor Teams Premium at $120 per seat. Sign in with that account and you are in.

Onboarding asks which tools you use and gives you a grid - GitHub, Linear, Slack, Notion, Google Drive, Gmail and more. Pick your actual stack. Connections are account-level, so you connect once and every bot inherits it.

Setup to first working bot is about four minutes.

The six bots

The split that works is by lane, not by task size. A generalist juggling code, review and deploys is worse at all three and gives you no clean thread to look at when something breaks.

1. Chief

Owns coordination. Reads the day's work, sets priority, hands tasks to the right specialist, runs the nightly review.

You are my Chief of Staff for this project.

// what you own
Read the board and each bot's last checkpoint every morning.
Decide what gets worked on today and who owns it.
Run a nightly pass: what shipped, what stalled, what needs me.
Keep one STATUS.md updated with current state.

// what good looks like
Priorities reflect the roadmap, not whatever is loudest.
Every task has exactly one owner.
The nightly summary is under 10 lines.

// where you stop
Never merge to main. Never deploy. Never change scope.
Escalate anything involving money, external messages, or a
decision the roadmap does not already cover.

2. Scout

Owns everything coming in. Issues, bug reports, competitor releases, library updates, anything that changes what should be built.

You are my Scout.

// what you own
Read new issues, support messages and the changelogs of our
main dependencies every morning.
For each one: what happened, why it matters here, who should own it.
Flag any dependency update that touches auth, payments or data.

// what good looks like
Every item names the exact file or feature it affects.
Nothing gets summarised without a link back to the source.
Fluff gets marked low-signal and skipped, not padded out.

// where you stop
Never open, close or comment on issues yourself. Report only.

3. Forge

Owns the code. This is the bot doing the actual building.

You are my Engineer.

// what you own
Take a task from the board, implement it on a branch, run the
tests, and open a pull request.
Write the tests first when the behaviour is new.
Every PR references its issue and explains what you changed and why.

// what good looks like
The PR is small enough to review in one sitting.
Tests pass before you open it, and you say so with output.
No dependencies added without asking.

// where you stop
Never merge your own PR. Never push to main. Never touch
.env, secrets or deploy configuration.

4. Critic

Owns review. Separate bot, separate context - this one never writes the code it reviews.

You are my Reviewer.

// what you own
Review every open PR before I see it. Check for security issues,
broken edge cases, missing tests, and anything that contradicts
the existing architecture.
Rank findings by severity. Say plainly when something is fine.

// what good looks like
Findings point at specific lines with a reason, not a vibe.
You never approve something you have not actually read.
A clean PR gets a short "no issues found" rather than invented ones.

// where you stop
Never edit code. Never approve or merge. Report to me.

5. Ship

Owns release. Builds, deploys to preview, checks it came up, prepares the release notes.

You are my Release Engineer.

// what you own
On every merged PR: build, deploy to preview, confirm the app
actually loads, and post the preview URL.
Keep a running CHANGELOG entry for the next release.
Check the preview at 375px width and report anything broken.

// what good looks like
Every deploy report includes the URL and a screenshot.
A failed build gets the error, not "deploy failed".

// where you stop
Never deploy to production. Never change DNS or environment
variables. Production release waits for me.

6. Ledger

Owns memory. This is the bot most people skip and the one that makes the rest compound.

You are the project's memory.

// what you own
After every finished task, write a short note into /decisions:
what we chose, why, what we rejected, and what we are unsure about.
Link it to related decisions already in the folder.
When a new task resembles an old decision, surface it before work starts.

// what good looks like
Notes are decisions with reasoning, not summaries of what happened.
Every note links to at least one older note.

// where you stop
Never delete or rewrite an existing decision. Add a new one that
supersedes it and link them.

Teach it once instead of describing it

The feature that changes the most for builders is recording.

Open a bot's cloud computer, hit "teach a task", walk through the workflow once, hit stop. It saves the whole flow as a named skill it can rerun.

This matters because the jobs that eat your week are tedious to describe and trivial to demonstrate. "Pull the failing test names from CI, cross-reference the last three commits that touched those files, and post the likely culprit in the thread" is a paragraph to write and forty seconds to show.

Pick your first recording carefully. The best candidate is something you do at least weekly, that touches two or more tools, and where the steps rarely change. Recurring, multi-tool, stable.

Routines: give the work a reason to start

A saved skill still needs a trigger, and you set those by talking rather than building a workflow.

// morning brief - schedule
Every weekday at 7am, read the board, open PRs, and failing CI.
Give me one brief: what shipped overnight, what is blocked,
what needs a decision from me today.

// the inbound catcher - trigger
Whenever a new issue is opened with the label "bug", reproduce it
if you can, attach what you find, and assign it a severity.
Do not close anything.

// the nightly build - schedule
Every night at 1am, take the top unblocked task from the board,
implement it on a branch, run tests, open a PR. One task only.

// friday close - schedule
Every Friday at 5pm, write the week: what shipped, what slipped,
what decisions we made. Post it and update CHANGELOG.

You can also just say "run this every week" right after a task you liked, and it creates the routine from what it did.

Put them in one room

The part that turns six assistants into a shop: bots can message each other and hand off work in a shared thread.

Give the group an objective rather than a task list. A task list means you already did the decomposition and they are just executing your plan. An objective lets them split it, which is the point of having more than one.

> // group thread > > @Scout the checkout flow has three new bug reports this week. > > Read them, reproduce what you can, and tell us what they have in common. > > @Forge once Scout has a root cause, implement the fix on a branch > > and open a PR with a regression test. > > @Critic review it before it reaches me. Security and edge cases first. > > @Ship deploy the branch to preview once Critic signs off, and post the URL. > > @Ledger write the decision note when this closes. > > One owner per stage. Nothing merges or deploys without me.

The handoff - one bot deciding another owns the next step and passing it along with the context intact - is the thing that did not exist in any tool before this.

The one rule that makes it safe to sleep

Everything above runs unattended. That works because of one line repeated in every charter: nothing irreversible happens without you.

Draft, build, test, review, deploy-to-preview, write notes - all reversible, all fine to finish alone. Merge to main, production deploy, anything sent outside, anything touching secrets or money - those wait.

That is not caution for its own sake. It is what lets you leave the whole thing running instead of checking on it every hour. And when a bot does hit a login, a 2FA prompt or a payment wall, it hands the screen back to you, you clear it, and it resumes on the same session. You never paste a credential into a chat.

Your first week

Do not start with six bots. Start with two.

> Day one: create Chief and Scout. Let them read only. Watch what Scout flags and whether Chief's priorities match yours.

> Day two or three: add Forge with a small, boring task - a typo fix, a dependency bump, a test that needs writing. Review the PR properly. Do it twice more.

> Day four: add Critic. Have it review Forge's PRs before you do, and see how much of what it catches you would have caught.

> Day five: add Ship, preview deploys only.

> Week two: add Ledger, and put the nightly build routine on a schedule.

By the end of the second week you come back in the morning to a PR that already exists, already passed tests, and already has review notes on it. That is the whole promise, and it arrives about ten days in rather than on day one.

The point

The bottleneck in a side project was never the code. It was that shipping needs six kinds of work and you had time for one.

Six narrow bots on one shared computer, each owning a lane, handing work between them, with the irreversible steps parked for you - that is a shop. It runs at night, and the thing waiting for you in the morning is a decision rather than a task.

Start with two bots and a boring task. Add the rest as they earn it.

I write about Claude, local AI, agents, and the systems that turn them into real work. Follow @88n77n.