Guide

Skills before routines: prove it, save it, then schedule it

A routine that wakes every weekday is only useful if the work it runs is already reliable. Official Grok Bot guidance is blunt: start with a one-time task, make it reliable, save the method as a skill, and only then automate it.

1. Skill vs routine (they are not the same)

Skill — reusable instructions for how to do a task: steps, inputs, validation, and what needs approval.
Routine — tells one bot when to run that workflow (a schedule or a supported event).

Automating first freezes whatever bugs you still have into a recurring bill. Saving the method first means every wake reuses a checked procedure instead of reinventing the prompt.

2. Prove the task once

Run the job by hand in the bot that will own it. Use real sources, a clear finish line, and the same approval boundary you want later. Correct the output until you would trust it without babysitting. If it fails half the time in an interactive chat, it will fail on a schedule too — only louder, because you are not watching.

3. Save a useful skill

Ask the bot to capture the process you just used. Grok Bot’s own checklist for a skill is worth copying into every save:

When to use it
Required inputs and access
The sequence of work
How to validate the result
What to return
What requires approval

On the coding-agent side, the same idea ships as the open Agent Skills format: a folder with a SKILL.md (name + description in frontmatter, then the recipe). Cursor discovers skills from project and user skill directories and can invoke them with /. Keep the description specific — agents decide relevance from that line.

If the path is a browser workflow, Grok Bot’s Teach a task flow can record a demonstration (up to about ten minutes of visible computer interaction, no microphone) and draft a skill. Treat that draft as unfinished: add decision rules, failure handling, and approval boundaries before you schedule anything.

4. Then create the routine

Only after the skill works on a safe example do you ask the owning bot to schedule it. Confirm the bot, the schedule and timezone (or the event match), the input source, the expected result, the approval boundary, and what to do when a source is missing. Prefer a narrow event listener over a broad “every new message” wake — broad listeners burn usage and act on noise.

Use a test run after you create or edit the routine. A test run does real work (sites, files, connectors), so keep write actions behind approval and check: current inputs, required format, source trail, stop at the approval point, and explicit failure states.

5. Design for trust, not just for speed

Automate preparation before execution — draft, reconcile, or recommend first.
Require approval for sending, purchasing, deleting, publishing, or production changes.
Include a no-data / stale-data policy instead of improvising on empty sources.
Make retries safe to repeat when possible.
Re-test after a website, connector, or source format changes.

Useful public resources

xAI docs — Skills and routines

Official Grok Bot path: one-time task → skill → routine, teach-by-demo, test runs, and trust design.

Cursor docs — Work with Grok Bot

Day-to-day bot work, including skills, Teach a task, routines, and approval boundaries.

Cursor docs — Agent Skills

SKILL.md layout, discovery paths, progressive loading, and built-in skills.

Agent Skills (open standard)

Portable skill folders across agents: discovery → activation → execution.

xAI docs — Create and manage Bots

Give each bot a clear job before you pile skills and routines onto it.