How to Create a Grok Bot That Owns a Real Job

To create a useful Grok Bot, give one named Bot ownership of one durable job. Define its result, allowed sources, and approval boundaries.

Test that job on a real task before adding a schedule.

1. Start with a job, not a personality

A name and avatar make a Bot recognizable, but the job makes it useful. A focused description should answer four questions:

• What outcome does this Bot own?
• Which tools or sources may it use?
• What should the finished result look like?
• Where must it stop and ask for approval?

“Help me with work” is too broad. A more operational starting point is:

Own the weekday pull-request review. Check the repositories I approve, separate merge-ready work from blocked work, and leave a linked decision list. Never merge or close a pull request without approval.

That role has a result, a scope, and a visible safety boundary. Compare it with the source-backed LGTM pull-request Bot in the directory.

2. Install Grok Bot and create the teammate

Before setup, use the Grok Bot access page to confirm that your current plan and device are eligible.

In the desktop app:

1. Choose New or press Cmd/Ctrl+N.
2. Select Create new agent.
3. Open the new Bot’s actions and choose Edit Profile.
4. Set a short name, job title, and operational description.
5. Start the conversation with one concrete task.

Do not create a roster of specialists yet. One Bot should first complete one end-to-end outcome. Split the role only when another job needs different tools, context, working style, approval rules, or cadence.

3. Give it a task you can verify

Your first task should finish with evidence you can inspect. Ask for links, screenshots, source names, or a short action log when they matter.

For example:

Review the open pull requests in these repositories. Group them into merge-ready, blocked, and needs-a-decision. Link every pull request and explain the blocking evidence. Do not merge, close, or comment.

This is a better first test than “run this every morning.” A schedule repeats both good and bad workflows. First learn whether the Bot can access the right source, apply the intended rules, and produce the expected result.

4. Connect only what the job needs

When a website requires a password, passkey, two-factor code, or CAPTCHA, take control of the Bot’s computer and complete that sensitive step yourself. Do not paste credentials into ordinary chat.

Bots on one account share a cloud-computer environment, including browser sessions and files. A separate Bot is an organizational boundary, not a security boundary.

Connect the minimum sources required for the job. Sign out or revoke access when a source should no longer be available.

5. Put the approval boundary in plain language

State what the Bot may prepare and what it may change. Keep these actions behind approval while the workflow earns trust:

• sending messages or invitations;
• publishing content;
• purchases or financial transfers;
• deletion or overwriting;
• permission changes;
• production changes;
• acceptance of legal terms.

A useful approval request should show the current value, the proposed value, and the expected effect. “Make it better” is not a reviewable change.

6. Correct the result, then save the method

Run the task, review the output, and make lasting corrections explicit. Once the result is repeatable, ask the Bot to save the process as a skill.

The skill should include its inputs, steps, decision rules, output format, validation method, and failure behavior.

Only then create a routine that tells the Bot when to run it. Prove the one-time task before automating it.

A complete starter instruction

Adapt this structure to the job:

You own [specific outcome] for [scope].

Use [approved sources] and return [reviewable result] with links to the evidence.
If a source is missing or stale, report that instead of guessing.

You may [safe actions]. You must ask before [sending, publishing, deleting,
purchasing, changing permissions, or changing production].

Run this once now. After I review the result, help me turn the proven process
into a skill and only then propose a routine.

Choose a source-backed starting point

You do not have to design the role from a blank page. Browse the Grok Bot directory for public examples, then check whether a listing is an installable Template or a documented Use Case.

A Template must have a creator-published x.ai/bot/... link. Otherwise, the directory provides a clearly reconstructed prompt without claiming access to the creator’s hidden setup.

Sources and verification

Checked on August 30, 2026 against xAI’s documentation:

• Get started
• Create and manage Bots
• Skills and routines
• Approvals, security, and privacy

Grok Bot is in beta, so access and controls may change. The job-design framework and starter instruction are Grokbotlist editorial guidance.