Issue 2026-11-03: Turning your work into reusable GrokBot skills

#What this issue covers

In the first two issues we split one do-everything assistant into a team of Bots with clear roles, then gave them routines so they clock in on their own. Today we fill in the piece in between: skills.

You've probably been here. You spend half an hour correcting a Bot until it finally gets a task right, and next week you have to explain it all over again. Skills fix that. According to the official docs, a skill is a reusable set of instructions for how to do a task. It captures steps, decision rules, expected output, and safety boundaries, and all your Bots can use it. Save the run that went right, and one sentence brings it back next time.

#Five tips you can use today

Each tip comes with an example prompt. Replace the parts in brackets with your own and send it to your Bot.

#Tip 1: Save the skill right after it works

The official order is to make a one-time task reliable, save the method as a skill, and only then automate it. The best moment to save a skill is right after you and the Bot got a task right, while every correction is still in the conversation. That's when the Bot knows best which steps mattered and where you changed its approach.

Good candidates are things you do again and again, roughly the same way each time: a weekly research roundup, a report in a fixed format, a process for a certain kind of email. A one-off job isn't worth saving.

Creating one is simple. Just say it in chat:

That [task name] went well. Please save the process we just used as a skill called "[skill name]".
Include:
1. The data sources and any apps or logins it needs;
2. The decision rules (for example, what's worth including and what counts as a risk);
3. The output format;
4. The places I corrected you just now, as fixed rules;
5. What you must ask me about first, such as sending anything to anyone.
When it's saved, show me the full skill.

#Tip 2: Make a good skill spell out six things

The official docs list six things a useful skill states. After saving one, check it against this list and ask the Bot to fill in anything missing:

When to use it

The situations it fits, and the ones it doesn't

Inputs and access

What data it needs, and which connected apps or logins

Sequence of work

The steps it follows

How to validate

How to check that the result is right

What to return

The output, its format, and where it goes

Approval boundary

Which actions need your OK first

Two more points from the official advice on automation belong in a skill too: what to do when data is missing or stale, and where to report partial completion. Without them, a skill works fine on a good day and quietly reaches for old data the first time something goes wrong.

Please open the skill "[skill name]" and check it against these six points: when to use it, the inputs and access it needs, the sequence of work, how to validate the result, what to return, and what requires approval.
Add two more: what to do when data is missing or stale, and how to report partial completion.
List anything missing or vague and suggest changes. Update the skill only after I confirm.

#Tip 3: If it's hard to describe, demonstrate it

Some jobs you could do in your sleep but find hard to put into words, like exporting data from an admin page. Where it's available, use Teach a task:

1. Open the computer view
   Go to a one-to-one conversation with a Bot and open its computer view.
2. Start teaching
   Choose Teach a task, then describe the result you're about to demonstrate.
3. Do it once
   Perform the whole workflow yourself.
4. Review the draft
   Stop the recording and review the skill the Bot creates.
5. Test it safely
   Try it on a safe example before you think about a routine.

A few things to keep in mind. Teaching records visible computer interaction for up to ten minutes and doesn't record microphone audio. Keep secrets off the screen during the demonstration, and use the secure handoff flow for credentials. The learned skill is a draft, so add the decision rules, failure handling, and approval boundaries that one example can't show.

Teach a task may be enabled gradually. If you don't see the control, ask the Bot to create a skill from your written instructions and the completed task.

I just demonstrated [workflow name]. Please show me the full draft skill, then add what the demonstration couldn't show:
1. What to do when a page fails to load, a button is missing, or the data is empty;
2. Which actions need my OK first;
3. How to confirm the result is right.
Then run it once on [a safe test example] and tell me the result and the basis for each step.

#Tip 4: Call skills by name and use the shared library

Using a skill is simple: name it in chat and ask the Bot to follow it. That's why a clear, distinct name matters. "Weekly research roundup" works far better than "roundup".

The official docs say private skills are one library shared by all your Bots, so a skill you saved with Research Bot is available to Writer Bot too. Two things to watch:

1. Apps and logins
   A Bot may still need the relevant app or login before it can actually run the skill.
2. Enable it for this Bot
   If a Bot can't find a private skill, open Connect apps in the sidebar, select the connected count next to the title, and enable it for the current Bot under Private skills.

Connect apps in the sidebar is also where you discover and install supported apps and packaged skills, so you don't have to write everything from scratch.

Please handle [this input] using the skill "[skill name]".
Before you start, tell me which apps or logins the skill needs and whether you have all of them. If anything is missing, stop and tell me instead of working around it.

#Tip 5: Publish to your team, and Sync after edits

If you belong to a team, you can publish a private skill so teammates can use it. Per the official docs, on desktop open Connect apps, select the connected count next to the title, open the skill, and choose Publish in its header. If you belong to more than one team, choose the team under Publish to.

The details:

Write a description first

A skill needs a description before you can publish it, because teammates and their Bots use it to decide when the skill applies

Later edits

After publishing, the button reads Published. Its menu offers Sync, which pushes your later edits to the team's copy

Other options

The same menu has Copy link and Unpublish

If publishing is refused

The message says why. Usually you need to join a team first, or your team admin has turned off publishing for members, in which case ask an admin to publish it

What can't be published

Skills that came with the app or with a Bot's template

Before you publish, clean anything personal out of the skill. The description is worth real effort too: the clearer it is, the better your teammates' Bots can pick the skill up at the right moment.

I'm about to publish the skill "[skill name]" to my team. Please run a pre-publish check first:
1. Does it contain my personal details, private accounts, internal addresses, keys, or settings that only fit me? List them and suggest generic wording;
2. Write a description that says what it's for, which apps it needs, what it returns, and what needs approval;
3. List what a teammate should set up before using it for the first time.
Show me the proposed changes first; don't edit anything yet.

#Limits you should know

1. A skill is a method, not access
   A skill records how to do something, but it doesn't connect apps or log in for the Bot. Without the right access, the skill won't run.
2. Review the draft
   Whether it came from a demonstration or from chat, read it and test it on a safe example before giving it to a routine.
3. Tests do real work
   A test can navigate websites, change files, and call connected tools. Use safe inputs and keep write actions behind approval.
4. Re-test when sources change
   When a website, app, or source format changes, re-test the skills that depend on it.
5. Keep secrets out
   Don't write passwords or keys into a skill or show them in a demonstration. Use the secure handoff for credentials.

#Case study: a newsletter team that passes on what it knows

Continuing the fictional lineup from the last two issues (not anyone's real setup): a small team publishes a weekly newsletter and maintains a side-project app. This time they save each Bot's best work as a skill and let the other Bots use it too:

#Highlight: one skill, two Bots

The line-by-line source check started with Reviewer Bot and you, working it out together: every claim needs a primary source, anything without one gets flagged, and nothing changes its meaning. Once it was a skill, Writer Bot started running it on its own drafts before handing them over, and the drafts Reviewer Bot received got noticeably cleaner.

Publishing is still your call.

You're this team's Planner Bot. Please look at what Research Bot, Writer Bot, and Reviewer Bot keep doing over and over, and which of those are worth saving as skills.
Give me a table: skill name, who saves it, who calls it, the apps or logins it needs, and whether it should also get a routine.
Show me the plan first. I'll confirm before you create anything in each Bot.

#Community picks: common ways to use skills

Here are a few common, easy-to-start ways to use skills. They're general ideas, so swap in your own details.

#A weekly report in a fixed format

Save the report's structure, tone, sources, and "conclusion first, details after" as a skill. Each week, just say "write this week's report with the report skill", and the format stops drifting.

#Reply drafts with one consistent voice

Put the reply principles for common questions, what must never be promised, and when to hand off to a person into a skill. The Bot only drafts, and you confirm before anything goes out.

#A demonstrated admin export

A fixed "filter, export, tidy into a spreadsheet" routine in some admin page is much faster to record with Teach a task than to describe. Log in first so no password shows up in the recording.

#One shared checklist

Save your pre-publish checks (do the links open, does every number have a source, is anything sensitive included) as a skill, so every Bot self-checks against the same list before delivering.

#A skill plus a routine, run the same way on time

This is the official example: a routine runs a skill every weekday morning and says to report a failure instead of using old data when a source is unavailable. The skill keeps the method consistent; the routine keeps it on time.

#Further reading

Share your own ways to use skills on X (remove anything private first) with #StudyGrokBot. The best ones will be featured in future issues.

#Exercise for this issue

Spend 15 minutes saving your Bot's first skill.

1. Pick one job
   Choose something you ask a Bot to do every week, roughly the same way, and get it right once in chat.
2. Save it
   Use the prompt from Tip 1 to save the process as a clearly named skill.
3. Check the six points
   Use the prompt from Tip 2, and add how to handle missing data and partial completion.
4. Try another Bot
   Call it by name from a different Bot. If it can't find it, enable it as in Tip 4.
5. Test once
   Run it on a safe input, and only then think about a routine.

#Past issues and what's next

Past issues

Issue 2026-11-02: Getting started with GrokBot Routines

Tomorrow

Stay tuned for the next issue

Repository

https://github.com/Licoy/study-grokbot

Study GrokBot: GrokBot teaches you how to use GrokBot, updating daily with various GrokBot tips and tricks, as well as creations and gameplay shared by experts.