Does showing Grok Bot the steps once replace writing a procedure?

No. Showing Grok Bot the steps once does not replace writing a procedure. When Teach a task is available, a demonstration records a browser workflow and saves a draft skill. The docs say to add the decision rules, the failure handling, and the approval boundaries that one example will not make obvious. A routine, which is the schedule, comes after the skill is reliable. The order on the skills page is explicit: do the task once, make the method reliable, save it, and only then automate it.

A skill is a reusable set of instructions for how to do a task. A routine tells one Bot when to run a workflow, on a schedule or, where supported, after an event. The demo is a way to fill in the steps. It is not the skill, and the skill is not the routine. People collapse those three because the launch story says you show a Bot the work and it remembers. The current docs keep them apart, and the draft label is the part to believe.

What does a demonstration actually record?

You open a one-to-one Bot conversation and its computer view, choose Teach a task, describe the result you are about to show, perform the workflow once, stop the recording, and review the skill the Bot creates. Then you test it on a safe example before you schedule anything. Teaching records visible computer interaction for up to ten minutes. It does not record microphone audio. If the control is not on your account yet, the docs say the feature may be enabled gradually, and the fallback is to ask the Bot to create a skill from written instructions and the completed task. Absence of the button is not a sign you should narrate secrets into the chat instead.

Do not type passwords, keys, or one-time codes during the recording. The page says to avoid exposing secrets in the demonstration and to use the secure handoff flow for credentials. A recording of you logging in is a recording of the login. The shared cloud computer will hold the session afterward anyway. The skill text should not also contain the secret. Review the draft for anything you would not want stored as instructions.

What still has to be written?

The skill page lists what a useful skill states: when to use it, the inputs and access it needs, the sequence, how to validate the result, what to return, and what requires approval. A mouse path gets you the sequence, and only the path you happened to take. It does not get you the rule for a missing file, a changed column, an empty export, or a customer you must not email. Those are sentences. The example the docs give, when you ask the Bot to save a process you just did, includes source systems, risk definitions, output format, and a rule that customer contact always requires approval. That last clause is the procedure. The clicks were the demo.

Add failure handling on purpose. The routine example says: if the source data is unavailable, report the failure instead of using old data. A demonstration on a day when the export existed cannot teach that. Stale data is the failure mode that looks like success. Write the no-data rule before you let a schedule run. The trust section of the same page says to include a no-data and stale-data policy, to make retries idempotent where you can, and to tell the Bot where to report partial completion. None of that is visible in a happy-path recording.

Re-test after a website, a connector, or a source format changes. A skill learned from one layout of a page is brittle in the exact way a written procedure is not, unless you wrote the checks. The draft is a starting point you edit. It is not a warranty that the tenth run matches the first.

Who can use the skill once it exists?

Skills are available across your Bots. A Bot may still need the connector or the login, and on this product those live on the one cloud computer the account shares. Private skills are one library for all your Bots. If a skill does not show in the / menu in the desktop composer, the docs send you to Marketplace, then Your plugins, then Manage plugins and skills, and tell you to look under Private skills. @ is how you refer to Bots, groups, routines, and connectors. / is the skill.

Packaged skills can be installed from Marketplace alongside connectors. Those are someone else’s procedure, not your demonstration. Read them the same way you would read a draft you recorded: when it runs, what it is allowed to change, and where it stops for you. Enabling a private skill for a Bot does not give that Bot a private disk. It offers the instructions. The logins are still the computer’s.

When does the schedule enter, and why is that a different write-up?

You ask the Bot that should own the recurring job. The confirmation list is the procedure for time: which Bot owns it, the schedule and time zone, the input source, the expected result, the approval boundary, and what happens when a source is missing. The Bot creates the routine and shows the next run. Background routines can run while the laptop is closed. That is why a sloppy draft becomes expensive. It will not wait for you to be watching.

Event triggers are narrower still. Cursor account integrations can start a routine from an event such as a Slack message or a GitHub notification. The docs say these are separate from Slack or GitHub plugins and may need their own connection. Define a narrow match. The sample is a specific channel, a ticket link, and a phrase, then a repro in staging, then a pack posted in the conversation, and never a post back to Slack without approval. A listener on every new message is called out as noise that burns usage and acts on irrelevant input. A demonstration cannot express “only when the message contains this phrase.” You write that sentence, or you do not have a trigger. You have a fire hose.

Test run is real work. The page says it can navigate websites, change files, and call connected tools. Use safe inputs and keep writes behind approval. Review whether it used current inputs, whether the output matches the format, whether each action has a source, whether it stopped at the approval you intended, and whether failure is explicit. A test that “looked fine” on production data is not a test. It is the job, done once, possibly wrong.

What should you leave human?

Sending, purchasing, deleting, publishing, and changing production systems. The design section says to automate preparation and to have the Bot draft, reconcile, or recommend first. Require approval for the actions that leave the building. Put that boundary in the skill text and in the routine confirmation, not only in your memory of the demo. Auto Review can still stop a matching action. A sentence in a skill does not turn ask-first off, and a demo that clicked Send does not mean Send is now allowed forever. If the recording included a send, edit that out of the skill before you schedule it.

A Bot can own up to 50 routines. The app keeps the 20 most recent run records for each. Open the Bot, choose View conversation details, then Routines, to enable, pause, test, edit the schedule or the instructions, inspect success and failure, or delete. Deleting a routine is immediate and has no undo. Deleting the Bot removes the routines it owned. Files on the shared computer can remain, which is a different cleanup. Grok Bot may also ask whether to keep routines running after a long time away, and it may pause them if you do not answer. When you come back, review what paused. A paused routine is not a deleted procedure, and a draft skill is not a paused routine. Check both.

Time zone is part of the written procedure, not a detail the mouse path captured. The routine confirmation asks for it because “8:00” without a zone is a different morning on a laptop that travels and on a cloud computer that does not. Settings and notifications are where the docs point you for time zone and usage controls. Usage on these plans resets weekly. A routine that fires five days a week is a standing draw on that allowance, including the weeks you are away, unless a pause prompt stopped it. Look at the next-run line the Bot shows when it creates the routine. If the clock is wrong, edit the routine before the first real morning, not after it has already posted a watch list built from yesterday’s file.

Showing the steps once is how you get a draft of the clicks, for up to ten minutes of what was on the computer view, without the microphone. Writing the procedure is how you add the rules, the missing-data case, and the approvals. Scheduling is a third step, owned by one Bot, and only after a safe test. The demo does not retire the write-up. It gives you something to correct before the schedule makes the draft boringly punctual.