Grok Bot skills vs routines: what each one is, and when to use it.

In Grok Bot's documentation, a skill is a reusable set of instructions for how to do a task, and a routine tells one Bot when to run a workflow: on a schedule or, where supported, after an event. A skill states when it should be used, but the documentation gives it no schedule or trigger of its own: timing comes from a routine, or from asking. A routine without a well-written skill behind it repeats whatever the Bot improvises each time.

The practical pattern is to make the procedure reliable first, save it as a skill, test it, and only then attach a routine. As a working pattern, this article's rather than the documentation's, a recurring job is one skill plus one routine: the skill defines the job and the routine starts it.

The documentation describes a skill as capturing steps, decision rules, expected output and safety boundaries. It lists six things a useful skill states: when to use it, the inputs and access it needs, the sequence of steps, how to validate the result, what to return, and what needs approval. That is close to the definition of a good standard operating procedure, which is the most useful way to think about a skill in a small business.

Private skills form one library shared by all of a user's Bots. A skill is enabled for a particular Bot under Private skills, and can be referenced in the desktop composer by typing a slash. Packaged skills can be found in Connect apps, alongside apps. On a Team Bot, only the owner or a manager saves a team skill.

The documented route is to do the job in conversation first and then ask the Bot to save the process you just used as a skill. Where the feature is available on the account, Teach a task lets you demonstrate a browser workflow once instead: teaching records visible computer interaction for up to ten minutes, does not record microphone audio, and produces a draft skill to review. The documentation says it may be enabled gradually and is not available on mobile; without it, the Bot can create a skill from written instructions and the completed task.

The documentation does not describe how a personal skill is edited after it is saved, or any limit on the number or size of skills. A sensible practice, ours rather than the product's, is to keep the written procedure in a document the business owns, change it there first, and re-test the skill against the changed procedure before relying on it again. The procedure then survives a change of tools, and a person can read it without opening the app.

A routine is created by asking the Bot that should own the recurring job. The documentation asks you to confirm the owner, the schedule and time zone, the input, the result, the approval boundary, and what should happen when a source is missing; the Bot then creates the routine and shows its next run. Schedules use the Bot's time zone setting and must be at least five minutes apart. A Bot can own up to 50 routines, and the app keeps the 20 most recent run records for each.

Events are the other way to start a routine. docs.x.ai gives a Slack message or a GitHub notification as examples. Cursor's help pages list more: a GitHub, Linear, Sentry or PagerDuty event, an email to the Bot's own agent address, or a webhook call from another system. They also state rate limits of 300 runs an hour across all routines and 200 an hour for any one routine, and note that a busy trigger can use a week of usage in a day. The documentation's own advice is to avoid broad listeners such as every new message.

Background routines can run while the laptop is closed, which is much of their point, and after a long absence Grok Bot may ask whether to keep them running and pause them if nobody answers.

The comparison below is limited to what the documentation and Cursor's help pages state. Where they are silent, the table says so, and the two rows marked as practice are this article's suggestion.

The choice follows from how the work arrives. Work that arrives at irregular times, or needs a person present to supply context, is best as a skill you invoke when needed. Work that recurs at a fixed time is a skill plus a scheduled routine. Work that should follow a specific signal can use an event-triggered routine, but only if the signal is one of the documented triggers.

• SKILL ONLY

  Preparing an estimate pack when a request comes in, cleaning up a job file after a visit, drafting a reply to a complaint you have just read.

• SKILL + SCHEDULE

  A Monday summary of last week's inquiries, a daily list of open quotes, a monthly review of supplier prices.

• SKILL + EVENT

  Work that starts from a documented event: a Slack message; a GitHub, Linear, Sentry or PagerDuty event; an email to the Bot's agent address; or a webhook another system calls. Work that starts any other way needs a schedule or a person.

• NEITHER YET

  A process nobody has written down, or one that changes every time it is done. Fix the process first; a routine repeats its gaps.

The examples below are illustrations written for this article, not documented features and not descriptions of any client's setup. Each shows which part belongs in the skill and which in the routine.

A skill is a procedure, and procedures drift. Give each one an owner, keep its source document dated, and review it when the business changes how the job is done: new prices, a new service area, a new policy. A routine needs a different kind of attention. Its run history shows whether each run succeeded or failed and why, but the documentation describes no automatic retry and no automatic failure alert beyond a per-Bot notification when a Bot finishes or needs input. Someone has to look.

The documentation's design guidance for routines is worth adopting as written: include a no-data and stale-data policy, make retries idempotent where possible, and tell the Bot where to report partial completion. Two more facts belong in the design. Approvals raised by unattended work expire if nobody answers, and the action does not run; docs.x.ai says after about ten minutes, while Cursor's help pages now say thirty minutes, so plan as if the window is short. And email prepared by a routine always waits for a person to press Send. A routine that prepares drafts for a scheduled review works with both facts; a routine that depends on someone approving in real time does not.

A test run of a routine performs real work: the documentation warns it can navigate websites, change files and call connected tools. Test against a sandbox, a copy of the data or a prepare-only version of the job, never against the live record on the first try.

1. 1

   Run it by hand

   Decides

   Does the process work with a person watching every step?

   Output

   One completed job and a written procedure

2. 2

   Save the skill

   Decides

   Does the skill state when to use it, inputs, steps, validation, output and approvals?

   Output

   A skill in the shared library, enabled for the owning Bot

3. 3

   Test the skill

   Decides

   Does it produce the expected result on five to ten sample inputs, including awkward ones?

   Output

   A short test record with expected and actual results

4. 4

   Create the routine

   Decides

   Who owns it, when does it run, and what happens when a source is missing?

   Output

   A routine with a visible next run

5. 5

   Test the routine safely

   Decides

   Does a real test run behave correctly against sandbox or copied data?

   Output

   A clean run in the run history

6. 6

   Watch the first live runs

   Decides

   Do the first week's runs succeed, and are the drafts right?

   Output

   A routine someone has checked, with an owner and a review date

Most disappointment with recurring AI work comes from assuming a feature does more than its documentation says. These are the common ones, checked against the documentation.

• A SKILL HAS A SCHEDULE

  It does not. Timing comes from a routine or from asking.

• EACH BOT HAS ITS OWN SKILLS

  There is one shared library; skills are enabled per Bot.

• ROUTINES ARE INSTANT

  Schedules are at least five minutes apart, and event-triggered runs have hourly limits. No latency is documented, so nothing here is real-time.

• TESTING IS HARMLESS

  A test run performs real work.

• FAILED RUNS RETRY

  No automatic retry is documented; a run that hits a rate limit is not retried.

• ROUTINES SEND EMAIL ALONE

  Email from routines and background work waits for a person to press Send.

Based on the Grok Bot documentation at docs.x.ai as checked on 26 October 2026. Details attributed to Cursor's help pages come from cursor.com/help/grok-bot, checked the same day. The product changes often; check the linked pages before relying on a specific limit. Aevrion Ops is an independent consultancy. It is not affiliated with, endorsed by or a partner of xAI, SpaceXSI or Cursor. Grok Bot is named here only to describe it.

1. A skill is a reusable set of instructions for how a task is done; a routine tells one Bot when to run a workflow.
2. Skills form one library for all of a user's Bots and are enabled per Bot; routines belong to one Bot, up to 50 each.
3. Routine schedules must be at least five minutes apart; events include Slack and GitHub on docs.x.ai, and email, webhooks and others on Cursor's help pages.
4. A routine test performs real work, and no automatic retry or failure alert is documented, so give every routine an owner who reads its run history.
5. Design routines to prepare drafts for scheduled review: unattended approvals expire, and routine email waits for Send.
6. Make the process reliable by hand, save it as a skill, test it, and only then schedule it.