Grok Bot Routines: Make It Reliable, Save a Skill, Then Schedule It

On Wednesday I covered the first step with Grok Bot: one Bot, one job, one five-part brief and a safe first task. This one covers the next step: making a task that works happen again without you starting it.

The skills and routines page of the official docs puts the order in one line: "Start with a one-time task. Make it reliable, save the method as a skill, and only then automate it." Below is that order step by step, plus what changes with approvals for work you didn't start, and when a second Bot joins.

As a running example I'll use a generic daily-article pipeline: a Bot that turns a research note into a blog draft every weekday and never publishes on its own. It illustrates the method; it's not a report of results.

Step 1: Get one reliable run by hand

Run the task in a normal chat and fix it until the output is what you want. A skill saved from a messy run just repeats the mess on a timer.

My own test for "reliable": would the same instructions work tomorrow, with tomorrow's input? If the result depended on corrections I typed halfway through, those belong in the method. The Bots page separates a lasting rule ("From now on, never send external messages without approval") from a task instruction, and says memory is not a source of truth: keep changing facts in the source system. For the pipeline, the research note lives in a file the Bot reads every time, not in what it remembers.

Step 2: Save the method as a skill

The docs define a skill as "a reusable set of instructions for how to do a task" that "captures steps, decision rules, expected output, and safety boundaries." According to the docs, a useful skill states:

• when to use it
• required inputs and access
• the sequence of work
• how to validate the result
• what to return
• what requires approval

You don't write it from scratch: right after the good run, ask the Bot to save the process, as in the docs' "Weekly account health" example. For the pipeline:

Save the process we just used as a skill called "Daily article draft."
Include the research file it reads, the outline and length rules, how to
check every claim against its source link, the files it returns, and the
rule that publishing anything always requires my approval.

Private skills are one library shared by all your Bots; to use one, ask for it by name. Where Teach a task is available (the docs say it may roll out gradually), you can instead record one browser workflow, up to ten minutes, and the Bot turns it into a draft skill. Treat it as a draft: add the decision rules, failure handling and approval boundaries one example can't show.

Step 3: Write the routine like a job description

A routine "tells one Bot when to run a workflow": on a schedule, or on an event such as a Slack message, an email or a webhook call. You create it by asking the Bot that should own the job, and the docs list six things to confirm:

What to confirm	Pipeline example
The owning Bot	The writing Bot, not a general helper
The schedule and time zone	Every weekday at 9:00, Europe/Rome
The input source	Today's row on the work board
The expected result	Draft files in the day's folder, plus a short note in chat
The approval boundary	Never publish or post; stop and wait for my "ok"
What happens when a source is missing	Report the failure; don't write from old notes

Put together, the request reads like this:

Every weekday at 9:00 AM, run the "Daily article draft" skill using today's
row on the work board. Save the draft files in today's folder and post a
short summary with links in this conversation. Do not publish or post
anything. If today's row or its research file is missing, report that
instead of writing from older notes.

The last sentence is the one people skip. The docs' own example ends with "If the source data is unavailable, report the failure instead of using old data," and their trust checklist asks for a no-data and stale-data policy.

Two schedule details are easy to miss. Schedules use the time zone in Settings → Bot → Timezone, where Auto-detect follows the computer. And a new routine doesn't run when you create it; it waits for its next scheduled time. After saving, open the routine and read When to run, which shows the schedule in words. Routines run in the cloud, so they continue while your laptop is closed.

Step 4: Test it, knowing the test is real

Use Test after creating or editing a routine. The docs are clear that "a test run performs real work": it can navigate websites, change files and call connected tools, so use safe inputs. If there's no Test button, do the same work once in chat with a safe input, then check the first scheduled run. Then review:

1. whether it selected current inputs
2. whether the output meets the required format
3. whether every action has a source or audit trail
4. whether it stopped at the intended approval point
5. whether failure states are explicit

Every run spends usage, and the docs warn that an hourly schedule or a busy Slack trigger "can use a week of usage in a day." Start with the slowest schedule that does the job.

Step 5: Approvals change when you're not in the chat

In a chat, an approval card waits for you. The approvals and security page says a card raised by a routine or other background work expires after 30 minutes, and the action doesn't run. The troubleshooting page suggests turning on notifications for Bots that run routines. Other points from the approvals page:

• Email from a routine, sent from the Bot's own address, waits as a draft until you press Send.
• Auto Review takes into account what you asked for in your own messages. Text from an email or a web page doesn't count as your request.
• Ask first rules always stop matching actions; if an Ask first and an Allow automatically rule both match, Ask first wins.
• Write narrow rules ("Ask first before sending any external email"), not broad ones ("allow everything in the browser").
• Auto Review is model-based and "should complement, not replace, least privilege and explicit approval boundaries."

So put the boundary inside the routine, not only in your settings. The docs' design advice: automate preparation before execution, and require approval for sending, purchasing, deleting, publishing or production changes.

Step 6: Add a second Bot only when the work earns it

The Bots page recommends starting "with the smallest useful roster": give one Bot ownership of an end-to-end outcome, and add another only when the work has a stable specialist role. In the pipeline, a second Bot might own the research that feeds the board.

Bots can hand work to each other with asynchronous messages. The chat and collaboration page suggests a group chat (two to six Bots) when the handoff should be visible, and a single owner per stage, because parallel handoffs create duplicate work. Its kickoff example:

@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.

Bots share one cloud computer and can pass context through shared files, so a plain work board (one file listing each item, its owner and status) lets both see the same state. Two cautions from the docs: files, browser sessions and credentials on that computer are available to every Bot, so separate Bots are not a security boundary; and every Bot reply, including Bot-to-Bot messages, counts toward usage.

If a routine doesn't run, the troubleshooting page says to check that it isn't paused, that When to run shows the right schedule and time zone, that the owning Bot still exists and its plugins are authenticated, then read the run history.

Routine checklist

1. Run the task by hand until the output is right.
2. Save the method as a skill, including validation and approval rules.
3. Write all six routine fields, especially the missing-source rule.
4. Check When to run and the time zone, then Test with safe inputs.
5. Keep publishing, sending, purchases and deletion behind approval inside the routine.
6. Turn on notifications so background approvals don't expire unseen.
7. Add a second Bot only for a stable specialist role, with one owner per stage.

Where to go next

If you want the whole path in one place, Grok Bot in Practice: Build an AI Team That Works While You Sleep is a 53-page guide covering skills, routines and the six things every routine must state, approvals and Auto Review, a coordinated team with a shared work board, the weekly usage allowance and common failures. It includes seven case studies (among them The Scribe, a daily article pipeline), 10 copy-and-paste Bot briefs, 5 routine recipes and a 30-day plan.

If you haven't set up your first Bot yet, start with the free Grok Bot QuickStart: Your First AI Teammate in 30 Minutes, a 7-page PDF with a brief template, the trust ladder, your first routine and 3 starter briefs.

Both are independent guides, not affiliated with or endorsed by xAI, SpaceX or Cursor.

This article was written with the assistance of AI and reviewed by the author.