Grok Bot Routines: Build Reliable Automations

A skill is reusable instructions for how to do work. A routine tells one Bot when to run a workflow, either on a schedule or, where supported, after an event. The skill owns the method. The routine owns timing, inputs, the Bot responsible, and what happens when the source is missing.

This order saves a surprising amount of cleanup. A schedule does not make an unclear process clearer. It repeats the ambiguity at a dependable time. Run the task while you are watching, decide what a correct result looks like, and write the exceptional cases into the skill before any routine can wake on its own.

Save the process from a completed task, not from an imagined workflow. Ask the Bot to capture the sources, sequence, decision rules, validation, output format, and every action that requires approval. A skill can then be referenced from the desktop composer with /.

• State when the skill applies and which inputs it requires.
• Name the connections, files, or browser sessions it depends on.
• Write the work in order, including branches for missing or conflicting data.
• Define how the Bot proves the result is current and complete.
• Specify the returned artifact and where evidence appears.
• List the actions that must stop for approval.

A compact request is enough: save the weekly account-health process as a skill, include its source systems and risk definitions, keep source links in the output, and require approval before customer contact. Then open the saved skill and read it. The useful edit is often a failure rule the successful run never needed.

Private installed skills can be enabled per Bot. If one does not appear in the / menu, open Settings, Plugins, Yours and enable it for the current Bot. Packaged skills and connectors also appear under Plugins, but installing one does not grant every Bot a source login by itself.

Teach a task records a browser workflow you demonstrate and turns the visible interaction into a draft skill. Open a one-to-one Bot conversation and its computer, choose Teach a task, describe the intended result, perform the workflow once, stop the recording, then review what the Bot created.

1. 1Choose a safe example that will not publish, purchase, delete, or change production.
2. 2Describe the result before recording so the Bot can connect clicks to the outcome.
3. 3Demonstrate the workflow for no more than ten minutes.
4. 4Use secure credential handoff instead of exposing passwords during the recording.
5. 5Add decision rules, failure handling, validation, and approvals to the draft skill.
6. 6Test the skill on a different safe input before scheduling it.

The recording captures visible computer interaction and does not record microphone audio. A demonstration can show where to click and what to copy, but it cannot teach what should happen when the table is empty or the account belongs to an excluded region unless that case occurs. That missing reasoning is why the saved result remains a draft.

Teach a task is rolling out gradually. If the control is absent, complete the workflow with the Bot and ask it to save the written process instead. The resulting skill can be just as useful once its validation and boundaries are explicit.

Ask the Bot that should own the recurring result. Include the schedule and time zone, exact input source, expected artifact, approval boundary, and what to do when the source is stale or unavailable. The Bot shows the routine and its next run so you can inspect both before leaving it active.

Run Test run after creating or editing the routine. A test is not a preview. It can navigate websites, change files, and call connected tools, so use a safe record and keep external write actions behind approval. Check the selected input, output format, source trail, intended stop, and every failure the run reports.

The first test proves only that one input worked. Try the smallest variation likely to break it, such as a missing column or a source with no new records. If the Bot silently fills the gap from memory, fix the no-data rule before enabling the routine.

Yes, supported Cursor account integrations can start routines from events such as a Slack message or GitHub notification. These event connections are separate from Slack or GitHub plugins, and they may need their own authorization flow.

Keep the matching rule narrow enough that a person can explain why the run began. A named Slack channel, ticket link, and exact phrase is better than every new message. Broad listeners create noise, consume usage, and make unrelated content part of the Bot's input.

An event can start preparation without granting the final action. For example, a support message can trigger a staging reproduction and an evidence pack in the Grok BotAn early AI teammate product from SpaceXAI and Cursor that works across apps on a persistent cloud computer and asks for approval on selected actions; launch materials describe it as beta, but Cursor says Beta Services terms do not apply. Press Enter for the full definition. conversation, while posting back to Slack still requires approval. That split keeps the trigger useful without letting the source conversation authorize its own response.

Open a Bot, choose View conversation details, then Routines. From desktop you can enable or pause a routine, run a test, edit its schedule and instructions, inspect recent success or failure, and delete it. The iPhone app can inspect, pause, and resume, while editing, testing, history, and deletion remain desktop tasks.

Pause after a website, connector, source schema, or policy changes. Re-run the safe test, confirm the approval point, and only then restore the schedule. Routines depend on current interfaces, which means last month's green run is weak evidence after the source has changed.

Reliable routines prepare before they act, identify their current source, and fail visibly. They use idempotent retries where possible, report partial completion, and keep sending, purchasing, deletion, publishing, and production changes behind approval.

• Define how old data can be before the Bot must stop.
• Give an empty result a named outcome rather than treating it as success.
• Make a retry safe to run twice without duplicating an external action.
• Return direct links, timestamps, and a short action log with the result.
• Route failures to the owning conversation instead of hiding them in a generated file.
• Re-test after any connected system or policy changes.

The security guide covers approvals and account cleanup. The computer and apps guide explains the shared login boundary that every routine inherits.