How to Create and Use Grok Bot Skills (With Examples)

Grok Bot skills turn a one-time task into something you can repeat reliably across your team. Once you've done something once and know the process works, you save it as a skill, enable it for the Bots that need it, and reference it every time that work comes up.

Most people build a skill by asking the Bot to save a successful workflow, or by teaching it through demonstration. Either way, you're capturing not just steps, but decision rules, approval boundaries, and what counts as done. A good skill is reliable enough to run unattended and safe enough that you'd trust it to do the same work the same way every time.

This post covers how to build, test, and reference skills in Grok Bot—with real patterns from the directory, examples of what makes a skill actually reusable, and when to turn a skill into an automated routine.

How to Create and Save a Grok Bot Skill

The simplest way to create a skill is to ask the Bot to save one after you've walked through a task together.

Run the task once. Make sure it works. Then tell the Bot:

Save the process we just used as a skill called "Weekly team standup summary." Include the source systems, the meeting notes format, any risk definitions, and the rule that drafting always requires approval before posting.

The Bot writes the skill. You review it. It lives in your skill library and becomes available to every Bot on your account that has the required connectors and logins.

A strong skill statement includes:

• When to use it — the trigger or the job description
• Required inputs and access — what systems the skill needs to talk to
• The sequence of work — step-by-step, not prose
• How to validate the result — what does success look like
• What to return — expected output format
• What requires approval — the boundaries between draft and live

For example, the CI Code Review Bot runs a skill that reviews PRs for bugs, security, and missing tests. The skill doesn't just "review code" — it specifies which checks it runs, what counts as a blocker, and that human approval is required before any comment posts back to GitHub.

Teaching a Workflow by Demonstration

Grok Bot also supports teaching a skill by demonstration. This is available when the feature is enabled for your workspace.

To teach a workflow:

1. Open a one-to-one Bot conversation and switch to its computer view
2. Click Teach a task
3. Describe the result you're about to demonstrate (e.g., "Extract new leads from the CRM and format them for outreach")
4. Perform the workflow once, exactly as you'd do it by hand
5. Stop the recording when you're done
6. Review the skill the Bot generated

The skill starts as a draft. You should add decision rules, failure handling, and approval boundaries that may not be obvious from watching one example.

Teaching records up to ten minutes of visible computer interaction. It doesn't record audio. Avoid exposing credentials during the demo; if you need to authenticate, use the Bot's secure handoff flow to handle logins.

A taught skill is a starting point. You'll refine it with:

• Explicit handling for edge cases (missing data, format errors, locked resources)
• Approval gates before any irreversible action
• Retry logic and stale-data policies
• Clear output that says what actually happened

How to Use a Skill in Grok Bot

Once a skill exists, reference it in any message to a Bot using /skillname.

For example:

• /daily customer risk — run the daily customer-risk skill against today's account list
• /github triage — run the GitHub triage skill on open PRs and issues
• /code review — run code review on a specified diff

Bots search your skill library by name. Type / in the composer and the autocomplete shows available skills for that Bot. If a skill doesn't appear even though it's in your library, it may need to be enabled per Bot in Settings → Plugins → Yours. Some skills also require specific connectors (Slack, GitHub, Zapier, etc.) to be installed and authenticated.

You can also include a skill inside a routine, so it runs on a schedule without you triggering it manually.

Building Skills That Actually Get Reused

Skills often fail to get used because they're either too vague, too rigid, or they don't clearly state what approval they need.

| Problem | How to Fix It | |---------|______________| | "Review the documents" | Specify which systems to pull from, what counts as a risk, and that sending a recommendation is enough (no need to draft the email) | | "Process the data" | State the input format, transformation rules, and the exact output structure | | "Check this and let me know" | Clarify whether "let me know" means post to a channel, save to a file, or wait for approval | | Skill is tied to one Bot | A reusable skill works for any Bot that has the connectors it needs; test it with a second Bot before shipping | | Approval is unclear | Bots need to know where the boundary is: draft, approve, or do it now. Leave nothing to inference |

A good test: could a Bot that's never seen this skill before run it without asking questions? If the answer is no, add documentation.

Skills vs. Routines: What's the Difference?

A skill is a reusable set of instructions. You own it, and you invoke it when you need it (typing /skillname in a message).

A routine uses a skill on a schedule or in response to an event. Routines run unattended, so you need to be certain the skill is safe to run without your supervision.

| Aspect | Skill | Routine | |--------|-------|_______| | Trigger | You invoke it manually | Schedule or event | | Runs when you're away | No | Yes | | Approval boundary | Skill defines it | You set it in the routine | | Reusable across Bots | Yes | Each Bot owns its own routines | | Rollback / Undo | You decide immediately | Only if designed to be idempotent |

Example workflow: You create a skill called "Daily standup" that pulls meeting notes and formats them. Then you create a routine that runs that skill every weekday at 8 AM and posts the result to a Slack channel. The skill is the method; the routine is the schedule.

Real Examples: Skills in the Directory

The directory has dozens of bots that rely heavily on skills. Here's what works:

Grimoire ships with 50+ skills bundled in a Tome (GitHub repo). Each skill is a file under skills/, with a name, description, and body. Skills cover everything from code generation to decision-logging. The bot references them via / and the user's workspace gets a copy of the whole Tome.

GitHub Issue and PR Triage has a single skill that runs daily: pull open issues and PRs, apply labels, draft replies queued for your approval. The skill's approval boundary is explicit: the Bot doesn't post without confirmation.

Alchemist uses skills to run experiments on undocumented APIs and systems. Each skill is narrow: "try this auth method," "log the error," "suggest a workaround." Narrow skills are easier to test, debug, and reuse safely.

The common thread: every reusable skill has a single clear job, states its approval boundary, and fails visibly if something's wrong.

Testing a Skill Before You Use It

Always test a new skill on safe data before running it in production or on a schedule.

1. Choose a skill you've just created or refined
2. Call /skillname with test inputs (old data, small samples, safe operations)
3. Review the output: Does it match the format you expected? Does it stop at approval gates? Does it fail clearly if something's missing?
4. Run it a second time on different inputs
5. If it's going into a routine, use the routine's Test run button before enabling the schedule

A test run performs real work—it navigates sites, writes files, and calls connected tools. Use safe inputs and keep write actions behind approval. This is how you catch edge cases before they happen in production.

Setting Up Connectors for Skills

Many skills need access to external systems: GitHub, Slack, Zapier, Google Calendar, etc.

To enable a connector for a skill:

1. Go to Settings → Plugins
2. Find the connector (e.g., "GitHub", "Slack", "Stripe")
3. Click Install and authenticate
4. Return to the Bot that needs to use skills requiring that connector
5. Verify the skill appears in the / menu

Some skills ship as "packaged skills"—pre-built templates you can install directly. Others are just part of a Bot template and auto-enable if the connector is available.

If a skill doesn't appear even after the connector is installed, check Settings → Plugins → Yours and toggle it on for the current Bot.

Key Takeaways

• A skill is a reusable set of instructions for a task. Create one by describing it to a Bot after a successful run, or by teaching it through demonstration.
• Skills state their approval boundaries. The Bot needs to know: draft, approve first, or execute now.
• Every skill needs a clear job and expected output. "Process the data" fails; "Extract leads from the CRM, validate email addresses, return a CSV" works.
• Test skills on safe data before enabling them in routines. A test run performs real work and helps you catch edge cases.
• Skills are available across your Bots if each Bot has the required connectors. Make skills work for any Bot that might use them.
• Use the / menu to reference a skill in any message. Type / and autocomplete shows the skills available to that Bot.
• Routines automate skills on a schedule or event trigger. A routine runs the skill unattended, so the skill's approval boundary has to be trustworthy.

FAQ

What happens if a skill doesn't have enough information to finish? The Bot stops and asks you. It doesn't invent data or make assumptions about sensitive actions. Before you enable the skill in a routine, test it on partial data to see where it asks.

Can I edit a skill after I've created it? Yes. Open the skill, request changes, and save the new version. Any routine using that skill will use the updated version next time it runs. Test the change before the next scheduled run.

Do I need a separate skill for each Bot? No. Skills are shared across your Bots. If two Bots need to do the same task differently, create two skills. If they need to do the same task the same way, one skill works for both.

What's the maximum length for a skill? There's no hard limit, but skills over a few hundred lines become harder to test and debug. If a skill is complex, break it into smaller skills that chain together.

Can skills call other skills? Yes. Within a skill's instructions, you can reference another skill using /skillname. This is a way to compose larger workflows from reusable pieces. Test the chain end-to-end before enabling in a routine.

If I share a Bot template, do the skills come with it? No. The template carries the Bot's identity, description, and routines—but not your private skills library. If you want someone else to use a skill, you either describe it to them, publish it as a packaged skill (if your workspace supports it), or include it as part of the template's instructions.

Next Steps

1. Pick a task you do regularly. Walk through it once, then ask the Bot to save it as a skill.
2. Add explicit approval gates. Tell the Bot which actions require your sign-off before they happen.
3. Test the skill on safe data. Use the / menu to invoke it, review the output, and refine if needed.
4. Enable it for other Bots if they need it. Skills are meant to be reused.
5. Turn it into a routine when you're confident. Schedule it to run on a cadence or event, and let it work unattended.

The most successful skills start narrow—one job, one output format, one approval boundary—and grow only when you need them to. You can always refine a skill; what you can't do is run an ambiguous skill unattended and trust the result.

For more, see the Grok Bot skills documentation, browse real bots in the Coding & Dev Tools category, or submit your own Bot.