Write a Grok Bot Skill Twice

Aug 11, 2026 · Write a Grok Bot skill two ways and compare what each one catches

Introduction

30 Second Summary

Every week, you sort through a pile of articles or updates and decide which ones are worth keeping. The judgment calls are invisible until something bad slips through.

In this project, you will write the same curation skill for a Grok Bot twice and run both versions against a test batch with two planted failures. The question is whether two missing fields change what the Bot lets through.

What You'll Build

You will look at two numbers side by side and know exactly whether writing two extra fields into a skill changed what a Bot caught.

By the end of this project, you'll have:

A planted test batch of 10 candidate items that lets you prove whether a skill's filter catches bad items or waves them through.
Two saved skills you can compare side by side: one that tells the Bot what to do, and one that also tells it what "wrong" looks like and where to stop.
A scorecard with a pair of numbers and a one-paragraph decision about whether the two extra fields belong in every skill you write.
Secret Mission: Add two borderline items to the batch and re-run Version B to test whether the validation criteria handle ambiguity or over-filter.

Do I need anything before starting?

You need a qualifying Grok Bot subscription (SuperGrok Plus, SuperGrok Heavy, Cursor Pro+, Cursor Ultra, or Cursor Teams), a macOS or Windows computer, and a weekly task with a curation or filtering step. There is no Linux desktop build of Grok Bot.

Before We Start

Before We Start...

Before any hands-on work, you need to commit to the specific weekly task and newsletter topic you'll test against. The skill text and the planted failures you'll build later both depend on these choices, so getting clear now saves you from rewriting later.

Install Grok Bot and Create a Curation Bot

To test whether two missing fields change what a Bot catches, you first need a Bot to test with. That means installing the Grok Bot desktop app and creating a dedicated curation Bot inside it.

By the end of this step, you will have Grok Bot running on your machine and a named Bot ready to receive skills.

In this step, get ready to:

Download and install the Grok Bot desktop app.
Sign in with your Cursor account.
Create a curation Bot with a name and a primary job.

Download and install Grok Bot

Grok Bot is a desktop app, not a browser tool. You need to download the installer for your operating system before you can create a Bot.

Open cursor.com/bot/onboarding in your browser.
Before you download, check which architecture your machine uses.

macOS

Click the Apple menu in the top-left corner of your screen.
Click About This Mac.
If you see a Chip field (e.g. Apple M1, M2, M3), choose the Apple silicon download. If you see a Processor field, choose the Intel download.
Open the downloaded disk image.
Drag Grok Bot to Applications.
Open Grok Bot from your Applications folder.

Windows

Open Settings.
Select System, then About.
Check the System type field. If it says x64, choose the x64 download. If it says ARM, choose the Arm64 download.
Run the installer.
Open Grok Bot from the Start menu.

What happens on first launch?

On first use, Grok Bot introduces Bots, the shared computer, and routines, then asks which tools you use. Follow the prompts to complete the onboarding.

Click Sign In with Cursor and sign in with your Cursor account.

Seeing a Legacy Privacy Mode error?

Grok Bot requires cloud data storage. If your Cursor account uses Legacy Privacy Mode, you need to update your data setting before Grok Bot can start.

Open cursor.com/dashboard/settings?openPrivacy=true in your browser and switch to a supported data setting.

Help me fix the Legacy Privacy Mode error in Grok Bot.

You should now see the Grok Bot interface with the onboarding prompts or the main sidebar.

Create your curation Bot

A Bot is a single persistent, named AI teammate. Focused Bots build more useful context than one catch-all Bot, so you will create one dedicated to newsletter curation.

Click New, then Create new agent.
Enter a short name for your Bot (for example, Scout or Curator).
For the primary job, enter something like: "Curate a weekly newsletter by filtering candidate articles for quality and relevance."
For the description of how it should work, enter: "Read each candidate item, check whether it meets the newsletter criteria, and return a shortlist with reasons."
Click Create.

Why a dedicated Bot instead of a general conversation?

All your Bots share the same persistent cloud computer, but each Bot builds its own context over time. A curation Bot remembers your newsletter topic and filtering preferences across conversations, so its skills improve with use.

Your new Bot should appear in the Grok Bot sidebar with the name you chose. Click on it to open a conversation.

Bot not appearing in the sidebar?

Make sure you clicked Create after filling in the fields. If the Bot still does not appear, try closing and reopening Grok Bot.

Help me create a new Bot in Grok Bot.

Grok Bot is installed and your curation Bot is ready for work. Next up, you will build a test batch of 10 items with two planted failures hidden inside.

Build the Test Batch

Your curation Bot is in the sidebar and ready for work. Before you hand it a skill, you need something to test that skill against.

A batch where every item is good tells you nothing. You cannot tell a working filter from one that just waves everything through. In this step, you will build a batch of 10 candidate items with two deliberate failures planted inside.

In this step, get ready to:

Find 8 genuine candidate items for your newsletter topic.
Plant 2 items with specific, checkable flaws.
Shuffle the list and privately record which items are planted.

Choose your topic and find 8 genuine items

Every item in your batch needs three properties to count as a genuine candidate. It must have a primary source, fall within your time window, and be relevant to your newsletter topic.

What counts as a primary source?

A primary source is original reporting, first-party data, or an official announcement. It comes directly from the person, organisation, or team behind the work.

A secondary article that summarises or comments on someone else's reporting does not count. If the article's main contribution is "Company X announced Y" with a link to the real announcement, the primary source is that announcement, not the article.

Confirm the newsletter topic you defined for your Bot. For example, "cloud infrastructure" or "frontend tooling" or whatever subject you chose.
Define the time window your newsletter covers. For example, "articles published in the last 7 days."
Open your usual news sources, search engines, or aggregators in a browser and find 8 genuine candidate items that match all three criteria: primary source, within the time window, and relevant to the topic.
For each item, write down a title, a link, and a one-line summary. Use any text editor or notes app you like.

You should now have 8 items written down, each with a title, a link, and a one-line summary.

Having trouble finding 8 items?

If your topic is too narrow to find 8 recent primary-source articles, widen the time window slightly (10 days instead of 7) or broaden the topic by one level ("developer tools" instead of "Rust build tools").

The important thing is that all 8 genuinely pass every criterion. Do not include a borderline item in the genuine set.

Help me find 8 genuine items for my newsletter test batch.

Plant two items with deliberate flaws

The two planted items are what make this batch a test instead of a regular list. Each one has a single, specific flaw that a good filter should catch.

Find or write Item A: an article with no primary source. This is a secondary article that summarises or comments on someone else's reporting, with no link to original research, data, or a first-party announcement.
Find or write Item B: an article that is stale. It was published outside your time window. For a weekly newsletter, this might be an article from three weeks ago. It should be relevant and well-written, just old.
Give each planted item the same format as your genuine items: a title, a link, and a one-line summary.

Why planted items need to blend in

Both planted items should look relevant and well-written at first glance. If a planted item is obviously bad, catching it proves nothing about the skill's filtering ability.

The flaws should only be detectable by checking: does the article link to a primary source, and is it dated within the time window? A human scanning titles and summaries should not spot them immediately.

You now have 10 items total: 8 genuine and 2 planted.

Assemble the shuffled list and record your key

The final step is combining all 10 items into a single numbered list that hides the planted items in plain sight. You also need a private record so you can score the results later without relying on memory.

Write all 10 items into a single numbered list (1 through 10). Each item should have a number, a title, a link, and a one-line summary.
Shuffle the order so the two planted items are not grouped together. Spread them apart in the list.
In a separate note that you will not send to the Bot, record which two item numbers are planted and what makes each one bad. For example: "Item 3: PLANTED. No primary source. Item 8: PLANTED. Published outside time window."

Why keep the record private?

If you tell the Bot which items are planted, it already knows what to exclude. The whole point is to see whether the skill's instructions alone are enough for the Bot to catch the flaws on its own.

Before you continue, scan your finished list. Can you spot the two planted items just by reading the titles and summaries?

If you can, the planted items are too obvious. Revise them until they blend in with the genuine items. If you cannot spot them without checking your private record, the batch is ready.

Not sure if your planted items are hidden well enough?

Check that both planted items have a professional-sounding title and a summary that matches the tone of the genuine ones. The flaw should only surface when you verify the source or check the publication date.

Help me check whether my planted items blend in with the genuine ones.

Your test batch is built and your private key is recorded. Next up, you will write your first skill and run it against these 10 items to see what gets through.

Write and Run Version A (Four Fields)

Your test batch is ready. Ten candidate items sit in a numbered list, with two planted failures hidden among eight genuine ones.

Now you will write the first version of the curation skill in Grok Bot. Version A has four fields: when to use it, what inputs it needs, the sequence of work, and what to return. These four fields describe the work. They say nothing about what a bad item looks like, and nothing about when the Bot should stop and ask.

In this step, get ready to:

Save a 4-field skill called Weekly Curation A to your curation Bot.
Run the skill on the 10-item test batch and receive a curated shortlist.
Record which items the Bot selected and count how many planted items got through.

Send the 4-field skill to the Bot

A skill is a reusable set of instructions for how to do a task. You will save it by sending your Bot a message that lays out the four fields. The Bot stores the skill and can reference it in future conversations.

Switch to your curation Bot's conversation in the Grok Bot sidebar.
Send the Bot this message to save the 4-field skill:

Save a skill called Weekly Curation A with these fields.

When to use it: every week when I send you a batch of candidate items for the newsletter.

Required inputs and access: a numbered list of candidate items, each with a title, link, and summary.

The sequence of work: read each item, evaluate whether it fits the newsletter topic, and select the ones that belong.

What to return: a numbered shortlist of selected items with a one-sentence reason for each.

What do these four fields describe?

"When to use it" tells the Bot the trigger. The skill activates when you send a batch, not at random.
"Required inputs and access" sets expectations for what the Bot needs before it can start.
"The sequence of work" gives the order: read, evaluate, select. Notice that "evaluate" is left open. There is no definition of what makes an item pass or fail.
"What to return" defines the output format. The Bot knows to produce a numbered shortlist with a reason per item.

Wait for the Bot to confirm that the skill has been saved.

The Bot should respond with a confirmation that it has saved the skill called Weekly Curation A.

Skill didn't save?

Make sure you are chatting with your curation Bot, not a different Bot or a general conversation. Check the name in the conversation header.
Try sending the message again with a clearer opening: "Please save the following as a skill called Weekly Curation A."
My Bot didn't save the skill when I asked it to. What should I try?

💡 Reference skills with /

Type / in the Grok Bot composer to see your saved skills listed. You can reference a saved skill directly instead of typing its full name every time.

Run the skill on the test batch

The skill is saved. Now you will feed it the 10-item batch and see what the Bot returns.

Send the Bot a new message with your 10-item batch and an instruction to run the skill. Paste something like this, followed by your numbered list:

Run the Weekly Curation A skill on this batch of candidate items:

[[TEST_BATCH="paste your 10 numbered items here, each with title, link, and summary"]]

What happens when the Bot runs the skill?

The Bot reads each of your 10 items, evaluates whether it fits the newsletter topic, and selects the ones it thinks belong. It returns a numbered shortlist with a one-sentence reason for each selected item.

The Bot might take a moment to process all 10 items. Wait for the full response before moving on.

Wait for the Bot to return a curated shortlist.

The Bot should return a numbered list of selected items, each with a one-sentence reason for inclusion. Some items will be excluded.

Bot didn't return a shortlist?

Make sure you pasted all 10 items in the message. A partial list may confuse the Bot.
Try asking explicitly: "Run the Weekly Curation A skill on the batch I just sent you."
The Bot didn't return a curated list after I asked it to run the skill. What should I check?

Record the results

Before you check the results against your private record, make a prediction. The skill you just ran describes the work: what to read, how to evaluate, what format to return. It says nothing about what counts as a bad item. It has no validation criteria and no approval boundary.

How many of your two planted items do you think made it into the shortlist?

Open your private record of which two items are planted and what makes each one bad.
Compare the Bot's shortlist to your private record. Check each item number in the shortlist against the two planted item numbers.
Count how many of the two planted items appear in the curated shortlist. Write down the number: 0, 1, or 2.
Do not correct the Bot or point out the planted items. Leave the conversation exactly as it is.

What does this number mean?

If both planted items made the shortlist (2), the four fields gave the Bot no reason to reject them. The skill described the work but never defined what a bad item looks like. This is the estimated result.

If one or both planted items were excluded (1 or 0), the Bot caught something on its own without explicit validation criteria. That is a real answer too. Record it honestly, because it changes the comparison with Version B.

This number is the first half of your result. You now have Version A's planted-item count recorded alongside the full shortlist.

You have Version A's result locked in. Next, you will write the same skill with two additional fields and run it against the same batch to see what changes.

Write and Run Version B (Six Fields)

Version A's shortlist is recorded. You have a count of how many planted items the 4-field skill let through. Those four fields described the work: when to trigger it, what inputs to provide, the steps to follow, and what to hand back. They told the Bot what to do, but not what a wrong answer looks like.

Version B adds two fields that turn the description into a contract. "How to validate the result" defines what a bad item looks like so the Bot can check its own work. "What requires approval" draws a line where the Bot must stop and ask instead of deciding on its own.

In this step, get ready to:

Save a 6-field skill called Weekly Curation B that includes validation criteria and an approval boundary.
Run the skill on the same 10-item batch and see whether the Bot stops, flags, or passes the planted items.
Record the Version B planted-item count and compare it to Version A.

Save the six-field skill

The official Grok Bot documentation lists six fields a useful skill should cover. Version A used four of them. Version B uses all six, keeping the same first four fields and adding the two that were missing.

In your curation Bot's conversation, send the following message to save the six-field skill:

Save a skill called Weekly Curation B with these fields.

When to use it: every week when I send you a batch of candidate items for the newsletter.

Required inputs and access: a numbered list of candidate items, each with a title, link, and summary.

The sequence of work: read each item, evaluate whether it fits the newsletter topic, and select the ones that belong.

How to validate the result: every selected item must link to a primary source (original reporting, first-party data, or an official announcement, not a secondary article summarizing someone else's work). Every selected item must be dated within the time window specified in the batch instructions. Flag any item that fails either check and exclude it from the shortlist.

What to return: a numbered shortlist of selected items with a one-sentence reason for each.

What requires approval: if an item is borderline on either validation check, present it separately with the evidence and ask before including or excluding it. Any action that would publish, send, or share content externally requires approval before proceeding.

What do the two new fields add?

"How to validate the result" gives the Bot two checkable rules. Every selected item must have a primary source (not a secondary summary). Every selected item must fall within the time window. If either check fails, the item is flagged and excluded.

"What requires approval" draws the boundary where the Bot must stop. If an item is borderline on either check, the Bot presents it separately with the evidence and asks you before including or excluding it. Any external action (publishing, sending, sharing) also requires your approval first.

Wait for the Bot to confirm that the skill is saved.
To verify, open Settings, then Plugins, then Yours. You should see Weekly Curation B listed alongside Weekly Curation A.

Skill not showing up?

If the Bot responded but the skill does not appear under Settings, then Plugins, then Yours, send a follow-up message asking the Bot to confirm it saved the skill. If the Bot treated your message as a one-off task instead of saving a reusable skill, resend the message and make sure the opening line says "Save a skill called Weekly Curation B."

Still stuck?

Run Version B on the same batch

The batch of 10 items is already in this Bot's conversation from Step 2. You are about to run a different skill over the same items.

Before you send anything, pause and predict. You already know Version A's planted-item count. Version B now has explicit rules for checking primary sources and time windows. How many of the two planted items do you think will make the final shortlist this time: 0, 1, or 2?

Send the Bot this message to run the new skill on the same batch:

Run the Weekly Curation B skill on the 10-item batch I sent earlier.

Reference a saved skill quickly

You can type / in the message composer to see a list of your saved skills. Use @ to reference Bots, groups, routines, and connectors.

Let the Bot finish processing. This may take a moment as it evaluates each item against the validation criteria.

What if the Bot stops to ask for approval?

The "What requires approval" field told the Bot to present borderline items separately with evidence before including or excluding them. If the Bot pauses and asks about a specific item, review the evidence it shows and decide whether to include or exclude. This is the approval boundary working as intended.

If the Bot does not stop for approval, that means it found no items ambiguous enough to flag. Both outcomes are valid results.

Record the Version B result

The Bot has returned a curated list. Time to compare it against your private planted-item record.

Write down every item number that appears in the Version B shortlist.
Check your private record. Count how many of the two planted items made the final shortlist. Write down the number (0, 1, or 2).
If the Bot flagged or presented any items for approval, note those separately. A flagged item that you chose to exclude is not in the shortlist count.
Write both counts side by side: Version A's planted-item count and Version B's planted-item count.

What does the pair of numbers mean?

If Version A let both planted items through and Version B caught both, the validation and approval fields changed the outcome. That is the estimated result, but it is only an estimate.

If both versions returned the same count, the two extra fields did not help for this batch. That is still a valid result. Do not adjust the count to fit the expectation. The next step scores exactly what happened.

You now have two shortlists from the same batch, built by the same Bot, using skills that differ by exactly two fields. The pair of planted-item counts is the raw result. In the next step, you will score three specific checks against those numbers and write the interpretation.

Score the Three Checks

You've run both versions of the skill over the same 10 items and recorded two planted-item counts. Those counts are the raw result, but a pair of numbers does not answer the question on its own.

Three checks turn the raw numbers into a real answer. Each check tests a different part of the claim: did the 4-field version miss the planted items, did the 6-field version catch them, and did the 6-field version avoid dropping the good ones along the way?

In this step, get ready to:

Score three checks against your Version A and Version B results.
Write the pair of planted-item counts side by side.
Write a one-paragraph interpretation of what the two extra fields changed.

Mark each check as pass or fail

The scorecard has three checks. Each one tests a different aspect of the experiment: whether the 4-field skill missed the planted items, whether the 6-field skill caught them, and whether the 6-field skill kept everything it should have.

Open your private notes where you recorded which two items are planted and why.
Add a new section titled Scorecard.

Write the first check. Before you mark it, pause and predict: based on the Version A count you recorded, do you think Version A let both planted items through?

Write Check 1: Did Version A let both planted items through?
Compare your Version A shortlist against your private record of planted items.
If both planted items appear in the Version A shortlist, mark Check 1 as pass. The estimate held. The 4-field skill had no criteria to catch them.
If Version A caught one or both planted items, mark Check 1 as fail. The four fields were already enough, and the premise does not hold. Report that honestly.

Why is "pass" when Version A missed the bad items?

The checks are not grading the skill. They are grading the estimate. Check 1 asks whether Version A behaved the way you predicted: that a skill without validation criteria would let planted failures through. If it did, the estimate passed.

Now write the second and third checks, which test whether Version B's two extra fields actually did the job.

Write Check 2: Did Version B catch both planted items?
Compare your Version B shortlist against your private record.
If both planted items were excluded or flagged for approval and ultimately removed, mark Check 2 as pass.
If Version B missed one or both planted items, mark Check 2 as fail. The validation criteria were not specific enough.

Write Check 3: Did Version B keep all 8 good items?
Count how many of the 8 genuine items appear in Version B's final shortlist.
If all 8 are present, mark Check 3 as pass.
If Version B dropped any good items, mark Check 3 as fail. The validation rule is too tight and the skill has become the problem.

What if all three checks passed?

That is the estimated result: Version A let both planted items through, Version B caught both, and Version B kept all 8 good items. It means the two extra fields did exactly what they were supposed to do for this batch.

If a check failed unexpectedly, that is still a valid result. Do not change the number to match the estimate. Change the interpretation instead.

Write the pair of numbers side by side

The three checks are pass-or-fail judgments. The pair of numbers is the evidence they rest on.

Below your three checks, write the planted-item count from Version A and the planted-item count from Version B, side by side.
Use this format: Version A: [count] planted items in shortlist. Version B: [count] planted items in shortlist.

What do the different combinations mean?

2 and 0 is the estimated result. Any other combination is still a valid result.

2 and 2 means the validation field did not help.
0 and 0 means the Bot was already catching them and the extra fields were redundant for this batch.
1 and 0 means one planted item was ambiguous enough that even Version A excluded it.

Your scorecard now has three checks and the evidence. Confirm that each check references the correct count before moving on.

Write the interpretation

The scorecard shows what happened. The interpretation says what it means for every skill you write going forward.

Below the pair of numbers, write one paragraph answering three questions:

What did the two extra fields (how to validate the result, what requires approval) change in the Bot's behaviour?
Was the change correct? Did the Bot exclude the right items and keep the right items?
If a check failed unexpectedly, what would you change in the skill text to fix it?

The paragraph is the lasting takeaway

The numbers show a single run. The paragraph is your decision about whether to include validation and approval fields in every skill you write going forward. If the run does not support the claim that the two fields matter, change the claim, not the number.

💡 What are the limits of this comparison?

The candidate set is planted, so the result shows what the skill catches, not what a real week sends. A real week might contain no bad item, which would look like success and prove nothing.

The comparison is one run. Two runs of the same instructions can differ, so a single pair of numbers is a signal, not a measurement.

Review your completed scorecard. You should have three checks each marked pass or fail, the pair of planted-item counts written side by side, and one paragraph of interpretation. That is the full result of the experiment.

Secret mission

Calibrate the Filter

Your planted items were clearly bad. No primary source, outside the time window. But real editorial decisions are rarely that clean. Add two borderline items to the batch and re-run Version B to find out whether your validation criteria handle ambiguity or just reject everything that is not perfect.

Clean Up Your Resources

This project runs entirely on your existing Grok Bot subscription, so there are no additional ongoing costs. Decide whether to keep your Bot and skills, clean up the test versions, or delete everything.

Resources you used:

Curation Bot (your named Bot in Grok Bot, e.g. "Scout").
Weekly Curation A skill (4-field version).
Weekly Curation B skill (6-field version, potentially revised during the Secret Mission).

Keep everything running

No action needed. Choose this if you plan to keep using the Bot and both skills for real newsletter curation runs.

Your Bot and both saved skills remain available for future use.
There is no additional cost beyond the subscription you already have.
Your conversation history with the Bot persists, including the test batch messages and curated results.

Pause - I'll come back to this later

Delete the test skill you no longer need. Keep Version B as your working skill and the Bot for future runs.

In Grok Bot, open Settings.
Select Plugins, then Yours.
Find Weekly Curation A and delete it.
Your Bot and the Version B skill stay intact for future curation runs.

Delete - I don't want to use this again

Remove both skills and the Bot entirely. This cannot be undone.

In Grok Bot, open Settings.
Select Plugins, then Yours.
Delete Weekly Curation A and Weekly Curation B.
Return to the conversation list and delete the Bot.
Deleting a Bot also removes any routines it owns. This action is immediate and has no undo.

That's a Wrap!

Nice work! You just designed, tested, and scored two versions of a Grok Bot skill to find out whether two missing fields change what an AI teammate lets through.

You've learned how to:

Built a planted-failure test batch for a Grok Bot skill, mixing two items with known flaws among genuine candidates so the result shows what the skill catches, not what luck sends.
Written the same skill twice (a 4-field version and a 6-field version) and compared the curated lists side by side to measure whether validation criteria and an approval boundary change the outcome.
Scored a three-check scorecard and written an evidence-based interpretation of whether the two extra fields belong in every skill going forward.
Secret Mission: Added two borderline items to the batch and re-run Version B to test whether the validation criteria handle ambiguity or over-filter.

Ready to quiz yourself?