Automating a repetitive task and writing a throwaway script
Automating a repeated action starts with separating what stays fixed from what varies each time, is described by its input, its output and the environment it must run in, and is checked with a dry run before any step that deletes, moves or overwrites anything.
An action repeated three times in the same way, on different data, always hides the same structure: a part that never changes and a part that varies with each pass. Isolating this second part before writing anything turns a sequence of manual actions into a script that can be reused on the next case, without rewriting it.
Separating what is fixed from what varies
Renaming photo files, exporting a monthly report, cleaning up a downloads folder: each of these actions contains a constant piece of logic, the type of transformation applied, and parameters that change, the target folder, the naming pattern, the date. Naming these parameters before asking for the script, rather than letting Claude guess them from the generated text, avoids a script that only works on the specific case that served as an example.
Describing a throwaway script by input, output and environment
A throwaway script does not need a full specification: it can be described by what it reads, what it produces, and the environment it must run in, the available language, the operating system, the tools already installed. This short description is enough for Claude Code to write a first draft, to be adjusted afterwards on a real example.
mkdir -p demo-renommage && cd demo-renommage
for i in 1 2 3; do echo "contenu" > "PHOTO_VACANCES_$i.JPG"; done
ls
> write a script that lowercases the name and extension of each .JPG file
> in this folder, first do a dry run that shows the planned renamings
> without changing anything on diskAsking for a dry run before any destructive step
A dry run shows what would be done without actually doing it: the files that would be renamed, moved or deleted, without touching the disk. This step gets requested before the final script is written, not after it has already been run once against real conditions. The same caution applies to a script that touches several files at once, or to a command that modifies an entire repository. Turning a script validated this way into a reusable action from one session to the next is exactly what skills, teaching Claude a workflow describes.
A script kept on hand, with its parameters named and its dry run already tested, costs less to rerun the next time than a fresh explanation typed from scratch on every occasion.
Repeated manual action against a parameterised script
| Approach | By the third repetition | Possible typing error | Reusable on another folder |
|---|---|---|---|
| Repeated manual action | Retyped in full once again | On every keystroke on every file | No, everything is retyped from the start |
| Parameterised script | One command, only one parameter changes | Checked once by the dry run | Yes, same script, another folder as the argument |
An administrator writes a first version of a script that exports the current month's orders to a CSV file, with the month name hardcoded directly in the script's text. The following month, he copies the script, changes the month by hand in the text, then reruns the export.
Write, in one sentence, what this situation establishes, and in one sentence what it does not establish.
What this establishes: This script works when the month is written by hand into its own text before each export, since the second export succeeded after this manual change.
What this does not establish: It does not establish that the script can run on another month without a prior change to its text, since the month stays fixed as long as nobody changes it.
The three most common miscalibrations
- Too broad This script can now export any month automatically, without ever being modified again.
- Too narrow This result proves nothing, since an export on two consecutive months is too little to draw a conclusion from.
- Off target This situation shows that the CSV format is the best suited for this type of monthly data.
- Naming the parameters that vary, folder, pattern, date, before writing the script avoids a result that only works on the example that served as a model.
- A throwaway script is described by what it reads, what it produces and the environment it runs in, without needing a full specification.
- A dry run shows the planned renamings, moves or deletions without touching the disk, and gets requested before the final script is written.
- An action repeated more than twice for the same kind of task becomes a serious candidate for keeping as a script, rather than an explanation retyped every time.
Find an action you have been repeating identically for at least three times, describe its input, its output and the environment it must run in to Claude, then ask for a dry run before letting it execute anything that modifies a real file.