Grok Bot skills and routines: test first, then automate

Start with a task you can evaluate

Our example is an internal weekly briefing from approved project documents. Before trying it, agree which files belong, the period covered and how outstanding issues are presented. Output should include references and uncertainty. It must not contact customers or change project dates. This creates a boundary you can evaluate.

Prepare a manual comparison too. Your team can then assess omissions and incorrect priorities. Record rework and unanswered questions. Repeat with different inputs rather than reusing the same successful example. Base the decision to proceed on those observations.

Document a successful method as a skill

Write the skill as instructions for a colleague covering your work: purpose, inputs, sequence, checks, output and stop conditions. Separate stable rules from changing details. The reporting period belongs in the task, while reporting missing sources remains a permanent process rule. For general principles of clear instructions, see our guide to building good skills and prompts.

Documented learning by demonstration is rolling out gradually and can capture a demonstrated browser task where available. Review the resulting instructions completely: recording a successful path does not automatically explain empty tables or conflicting information. Add these cases before reuse.

• Inputs: approved files, reporting period and authoritative versions.
• Output: outstanding issues with evidence, owner and unresolved question.
• Stop: missing source, denied access or required external action.

Distinguish schedules from events

The routine help lists schedules and triggers from Slack, GitHub, Linear, Sentry, PagerDuty, email and webhooks. Choose a trigger to match the need. A weekly briefing does not need frequent runs when the relevant information becomes available weekly.

Record timezone, owner, input source and destination. Keep event filters narrow enough that your team can explain why a particular input starts work. Account for holidays, missing data and previously processed inputs. A trigger defines the start; it does not define completion.

In the Bot’s own mailbox, incoming mail starts work through a configured routine. Independently generated replies remain drafts until sending is confirmed. Give email triggers a clear processing task and review the sender selection.

Test effects and failures too

A routine test can perform real actions. Use suitable sources and a controlled environment. Include a run that must stop at the intended approval point, checking that no message, invitation or unexpected file change occurred.

The approval help describes automated review and custom rules. Also establish which person evaluates the business impact. For our briefing, they review evidence and outstanding issues. Accepting a draft does not provide permanent permission for later changes in recipients or scope.

• Normal case: complete sources produce the agreed report.
• Failure case: a prohibited or missing source is reported.
• Boundary case: conflicting information remains an explicit open question.
• Repeat case: the same input creates no unnoticed duplicate effect.

Limit usage and retries deliberately

According to the documentation, one bot can own up to 50 routines; schedules must be at least five minutes apart, and the 20 most recent run records are kept per routine (checked October 25, 2026). Documented rate limits can reject runs, and some failed runs are not retried automatically. Define how the team distinguishes no input, a failed run and completed output. A quiet chat is insufficient operating status.

Usage depends on actual work. During the pilot, review the effects of source volume, run frequency and corrections. Agree when to pause the routine and who may approve extra cost. The plan help distinguishes shared pools on new plans from legacy rules. Having a subscription does not establish unlimited routine execution.

Operate routines with ownership and change review

Keep a small acceptance pack containing inputs and expected results: an ordinary input, an empty one and conflicting information. After a change, the team can apply the same standard again. Record which checks passed and which remain open; revised instructions alone do not establish that a revised workflow has been accepted.

Assign an owner and backup. Both should know how to pause the workflow, where results are stored and which sources are approved. Review a routine again when the data format, permissions or intended effect changes. A changed website may require new acceptance even when the task text stays the same.

For several roles, see the Bot teams guide. If you want help with access, instructions and training, our independent Grok Bot implementation service explains the scope. The aim is a reviewable workflow whose ownership remains clear without its original implementer. Implementation and support are provided independently by lol.marketing LLC. We are not affiliated with, authorised by or endorsed by xAI or SpaceXSI.