Automate a repetitive job with a script Grok writes

Most people's first genuinely useful piece of code is not an app. It is fifteen lines that rename four hundred files, or pull one number out of a stack of spreadsheets, or turn a folder of photos into something that fits in an email.

You do not need to learn a language for this. You need to be precise about the job and careful about what you point it at.

1. Describe the job as if to a temp

Write it out before you ask for anything. A good description names:

Where the input is. The exact folder, the exact file.
What comes out, and where it goes. A new folder, ideally; not the one you started with.
The rule. "Every file that starts with a date, renamed to YYYY-MM-DD-title." "One row per spreadsheet, with the file name and the total from cell B12."
The exceptions. What to do with a file that does not fit the rule. Skip it and say so, usually.

If you cannot write the rule down, the script cannot either. Ambiguity here is the source of nearly every bad outcome later.

2. Ask for the script: with three constraints

Write me a script that does the following. [Your description.] Three requirements: use only what comes with a standard install, no packages I have to download; do not modify or delete anything in the input folder; write results to a new folder; and print what it is about to do for every file before doing it. I am on [macOS / Windows / Linux] and I have never run a script before, so tell me exactly how to run it.

Each constraint is there for a reason:

No extra packages. Installing things is where a first attempt stalls.
Never write to the input. This is the one that saves you. A script that only reads its input cannot destroy it, however wrong it is.
Print before doing. You get to read the plan before it happens.

3. Make a copy of the input first

Do this even though the script promises not to touch it. Copy the folder, work on the copy, keep the original untouched until you have seen the script behave twice.

This costs thirty seconds and it is the difference between a mistake and an accident.

4. Run it on three files

Not four hundred. Put three files in a test folder, including one you expect it to skip, and point the script at that.

Read the output. Does it name the right files? Does it do what you would have done by hand? Did the odd one out get skipped and reported, rather than mangled quietly?

Checkpoint: three files, right answer, nothing touched that should not have been.

5. When it errors: send the whole error back

Scripts fail loudly, which is a gift. Copy the entire message, including the parts that look like noise, and send it back with the script:

Running that gave me this: [paste the whole error]. Here is the script I ran: [paste it]. What is wrong and what should the script say instead?

Do not retype the error from memory or summarise it. The file names, the line numbers and the last line are the parts that identify the problem.

6. Then run it for real

Point it at the copy of the full folder. Read the printed plan before you let it proceed. Check a handful of results afterwards: the first, the last, and the strangest input you have.

Keep the script somewhere you will find it next week, with a note at the top in plain language: what it does, what it expects, and the date you last ran it. In two months that note will be the difference between using it again and writing it again.

The four rules that keep this safe

Read-only on the input, always. If the job really must change things in place, do it as two runs: one that produces the new versions, one that swaps them in after you have looked.
Never run a script you have not read the plan from. You do not need to understand every line. You do need to see what it says it will do.
Ask what happens if it stops halfway. For anything touching more than a few files, that is a real question with a real answer.
Nothing with a password in it. If the job needs to sign in somewhere, that is a different guide and a slower afternoon; do not paste a credential into a chat window to get there.

Where to go next

Code review and debugging prompts, including a prompt for "explain what this script does, line by line, before I run it".
Make a Grok Bot that runs a job for you, for when the job needs to sign in to your tools rather than work on your own files.
Checking Grok's answers without doubling your work, on how much to verify before you trust something.

Last checked against xAI’s own pages on 2026-08-20. Grok changes quickly; anything version-specific should be confirmed upstream before you rely on it.