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