Don't Prompt Grok Bot. Record 10 Minutes and Let It Watch.

For two years the transferable AI skill was writing the prompt. Role framing, context blocks, few-shot examples, the 500-word system prompt you kept in a note and pasted into every new tool. It was a real skill and it compounded.

It is not the skill that matters here. Matt Van Horn swept X, Reddit and YouTube two days after Grok Bot launched, looking for setups that were producing work rather than screenshots. The first of the three properties he found in every one of them is the one nobody expected:

Forty-eight hours is a short window for a community to agree on anything. It agreed because the product removed the surface prompt engineering lived on. Matt Berman's read on why Grok Bot lands with people who bounced off agent CLIs: it brings coding agents to a mainstream audience without being intimidating, and his evidence is that there is no model selector. Take away the knobs and the only input left is showing it what you do.

Ten minutes of your screen, no narration

The mechanic is smaller than the reaction to it suggests.

Teach mode captures up to ten minutes of visible browser workflow. Both words are doing work. Ten minutes is the budget, so a forty-minute process gets cut into pieces before you press record. Visible is the harder constraint: no microphone audio, so nothing you would have said out loud gets in. If the reason you skip the third row of that report lives in your head, the recording does not have it. That goes in the correction pass, in text, on run two.

xAI's docs describe it as learning workflows from live demonstration: walk a multi-step process once and it is captured as a reusable routine, executable on demand or on a schedule. The weakness is structural. It is a single-pass recording with no defense against UI changes. A moved button, a renamed field, a connector that re-authenticates differently, and the recording is describing a page that no longer exists. Re-test after any site or connector change, not when the output finally looks wrong.

A skill is the how. A routine is the when.

This is the sentence from the docs that stops beginners stalling. A skill is the capability: the recorded demonstration plus the corrections layered on top. A routine is the trigger: every weekday at 8am, a calendar event, a Slack message landing. Teach the skill first. Attach the schedule afterwards, once the skill is boring.

People stall because they try to build both at once, which turns a ten-minute recording into an architecture decision. It is not one. A teacher gave a bot access to a syllabus, a digital textbook and Google Classroom, walked it through posting homework, then told it to do that every week. Teacher's assistant trained in one hour. Skill, then routine.

Two things from Nate Herk fit the same gap. Screen recording beats describing a visual task in text, so stop writing paragraphs about where the export button is. And before any new automation, run a "Grill Me" skill that makes the bot interview you until you both agree on what the task is. It catches the assumptions you did not know you were carrying.

The loop that separates working bots from abandoned ones

Peter Yang described the working loop more clearly than anyone:

The concrete version is more instructive than the principle. His YouTube researcher bot's first output was verbose and hard to follow, which is what first outputs are. He did not re-prompt in general terms. He prescribed an exact report shape: top 3 content ideas, top 5 outliers from other channels, top performer overall, common themes, nothing older than 14 days. Then he scheduled it daily. His Digital Marie Kondo bot came back overwhelming, and the fix was a number: max 10 items in each list.

Two of his tips pay for themselves immediately. Ask for output as a numbered list, because then you approve by number instead of retyping what you want kept. And review before any delete, every time, no exception for the bot that has been good so far.

Budget two to three correction rounds per bot. First-pass output is reliably verbose and unusable, and that is not a sign the bot is bad. Avi Chawla's version of the rule is the one to put on the wall: validate before automating. Run the task several times, correct the outputs, save it as a skill, and only then create the routine.

How this breaks

The failure mode has a shape. You test a task once, it works, you schedule it. The routine inherits every unstated assumption from that single run: the folder was empty, the report had data, the connector was already signed in. On day four one of those is false and the bot does the wrong thing eleven times before anyone looks. Premature scheduling does not produce an error, it produces a cascade, because the whole point of a routine is that nobody is watching.

No reproducible agentic task-success benchmark shipped with this launch, which means nobody can quote you a failure rate, including xAI. The rigorous response is the one grok-bot.org lands on: treat every first workflow as an evaluation. You are not deploying, you are measuring. Its companion line is the better rule for picking what to teach first. A reversible, low-impact workflow reveals more about reliability than an impressive demo. Take the weekly report, not the invoice run.

The people getting value in week one did not write the best prompt. They recorded a small thing, hated the first output, fixed the format twice, ran it manually four more times, and only then put a clock on it.

Record first. Schedule last.