Grok BotGuide

Lesson 5

Grok Bot skills, routines, and Teach a task

Official docs split two building blocks cleanly: a skill is a reusable “how” instruction; a routine tells a specific Bot “when” — on a schedule, or by event when supported. The right order is: complete one successful task, harden the method, save it as a skill, then automate. Skip the middle and the routine inherits every unspoken assumption, then runs for days before you notice bad output — operators and official docs say the same thing.

If you already have a roster, read this page as step 3–4 of after week one. Johnny Nel: each Bot is a job; the mega-chat is the failure mode. Nate’s public CoS walkthrough: the coordinator delegates first and does not do specialist work. mrfundman: Teach a task on a real CMS instead of writing the script first.

Copy this skill, then edit the brackets

Official fields: when to use it, inputs and permissions, steps, how to verify, what to return, and what must be approved. This template is original to this site. It is not a reprint of a share link.

Skill draft

How — after one good run

When to use: [one job this Bot owns]
Inputs: [file, connector, or /workspace path]
Permissions: read unless I name a write
Steps:
1. [first checkable action]
2. [second]
Verify: [what “done” looks like, with a cite]
Return: [format I can review in one screen]
Must be approved before: send, delete, pay, create Bots, change production
If a source is missing: stop and report. Do not invent.
Do not: treat last week’s chat as the source of truth — read the file.

Saving a skill

A skill should state: when to use it, inputs and permissions, steps, how to verify, what to return, and what must be approved. Skills are available to your Bots, but a given Bot still needs the matching connector or login to execute. On desktop, type / to cite saved skills and @ to cite Bots, groups, routines, and connectors. Private skills are enabled per Bot; if the / menu is empty, open Settings → Plugins → Yours.

When Teach a task is available: open a 1:1 chat and computer view → Teach a task → describe the outcome you will demonstrate → do it once → stop recording → review the skill the Bot wrote → test with a safe example before scheduling. Teaching records at most about ten minutes of visible computer actions and does not record the microphone. Do not expose secrets while demonstrating. Learned skills are drafts — you still add decision rules, failure handling, and approval boundaries. If the control is missing, you can ask in chat: write a skill from the task we just finished.

Routines

Describe to the Bot that should own the repeating work: owner, timezone, input sources, expected outcome, approval boundaries, and what to do when a source is missing. Background routines can run with the laptop closed. Event triggers come from Cursor account integrations (for example a Slack or GitHub notification); that path is not the same as the Slack/GitHub plugin and may need separate authorization. Keep match rules narrow: “every new message” creates noise, burns usage, and acts on irrelevant input.

After create or edit, use Test run. Official warning: tests do real things — navigate sites, change files, call connected tools. Use safe inputs; put write actions behind approval. Cap: 50 routines per Bot; the app keeps the latest 20 runs per routine. Deletes take effect immediately with no undo; deleting a Bot takes its routines. After long absences the product may ask whether to keep routines running; no answer pauses them.

Routine brief

When — after two good runs

Owner Bot: [name]
Timezone: [tz]
Trigger: [weekdays 09:00 — not every Slack message]
Input: [the file or connector from the skill]
Expected outcome: [the same deliverable that already worked twice]
Approval: drafts only. Do not send, delete, or pay.
If the source is missing or stale: report the failure. Do not reuse old data.

Staff have added two practical details: routine webhook URL and sender key appear only on desktop, not iOS; “Next run: Run now” display can lag 10–37 minutes in queue, and some runs finish without posting to chat — do not rebuild the routine; ask the Bot for an immediate check.

Design for trust

  • Automate preparation, not execution.
  • Draft, reconcile, and recommend first; send, buy, delete, publish, or change production only with approval.
  • Say what happens with missing or stale data; retries should be idempotent; partial completion should report where it stopped.
  • Re-test when a site, connector, or source format changes.

Common misconceptions

  • Setting routines to run around the clock. Cost-focused tutorials almost always switch to working hours so idle browsing does not eat the weekly pool.
  • Using “stay quiet” between Bots as a hard constraint. Staff: every Bot-to-Bot message consumes weekly usage; quiet in chat is only a hint. Reliable pattern: one Command Agent plus sub-agents that stop when done, and delete unused specialist Bots.
  • Seeing skills in a template preview but getting an empty skills array after import. Until fixed: copy skill text from the preview and have the new Bot rebuild them.

Skills need real tools — next lesson: plugins first, browser as fallback. Already running: the six-step path.

Guides