Throwaway scripts
Some work is mechanical and scales with N: rename 200 files, pull a field out of
50 JSON blobs, rewrite every import path, generate a table from a list. Doing that
through one tool call per item is slow and burns a lot of tokens for something a
five-line script would finish in one run. When the task is a loop, write the loop.
The rule: if a job is repetitive, deterministic, and scales with N, prefer a short
script over N manual steps. Write it just in time, run it, and remove it when done.
When to script
- The same operation repeats over many files, rows, or items.
- The work is mechanical: no per-item judgment, just a transform or a count.
- A script expresses it more cheaply than the equivalent pile of tool calls.
- You need a deterministic, repeatable result (a sweep you can rerun and trust).
When not to
- A one-off small edit. Just make the edit.
- A task that needs human judgment on each item.
- Something a dedicated tool already does cleanly (a search, a single
find-and-replace). Do not script what the right tool handles in one call. This
is
use-your-skills and the right-tool judgment applied to scripting.
Pick a runtime that exists
Do not assume. Check what the system actually has, then choose, just in time:
- JavaScript or TypeScript:
bun if present (fast, no install), otherwise node.
python for data wrangling and text.powershell on Windows, bash on Unix, for filesystem and glue work.
Match the language to the task and to what is installed. A two-line shell loop
beats a Python project for a rename; Python beats shell for parsing structured
data.
Write small, run, verify
- Write the smallest script that does the job. No scaffolding, no project, no
dependencies you do not need.
- For anything that mutates files or data, look before you leap: print what it
would do first, or operate on a copy, then run for real. Destructive sweeps
deserve a dry run.
- Run it and check the result actually matches what you intended.
Clean up
The script is scaffolding, not a deliverable. When it has done its job, delete it
so it does not litter the repo or get committed by accident. Keep it only if the
user wants it as a reusable tool, in which case put it somewhere sensible and say
so. Never commit a throwaway script as a side effect.
Before you proceed
Before grinding through a repetitive task by hand, ask: would a short script do
this in one run for fewer tokens and less time? If yes, check the available
runtimes, write the minimal script, run it, verify the output, and remove it. If
the task is small or needs judgment per item, do it directly instead.
1---2name: throwaway-scripts3description: For repetitive or bulk work that a short script can do in one shot, write the script, run it, and delete it, instead of grinding through many manual tool calls. Use this WHENEVER a task scales with N: renaming or transforming many files, extracting or reshaping data, bulk edits across a pattern, generating boilerplate, or any mechanical loop. Doing it by hand burns tokens and turns; a script does it deterministically and cheaply. Check which runtimes the system actually has (bun or node, python, powershell, bash), pick one that is present, write the smallest script that works, run it, verify, then clean it up.4---56# Throwaway scripts78Some work is mechanical and scales with N: rename 200 files, pull a field out of950 JSON blobs, rewrite every import path, generate a table from a list. Doing that10through one tool call per item is slow and burns a lot of tokens for something a11five-line script would finish in one run. When the task is a loop, write the loop.1213The rule: if a job is repetitive, deterministic, and scales with N, prefer a short14script over N manual steps. Write it just in time, run it, and remove it when done.1516## When to script1718- The same operation repeats over many files, rows, or items.19- The work is mechanical: no per-item judgment, just a transform or a count.20- A script expresses it more cheaply than the equivalent pile of tool calls.21- You need a deterministic, repeatable result (a sweep you can rerun and trust).2223## When not to2425- A one-off small edit. Just make the edit.26- A task that needs human judgment on each item.27- Something a dedicated tool already does cleanly (a search, a single28 find-and-replace). Do not script what the right tool handles in one call. This29 is `use-your-skills` and the right-tool judgment applied to scripting.3031## Pick a runtime that exists3233Do not assume. Check what the system actually has, then choose, just in time:3435- JavaScript or TypeScript: `bun` if present (fast, no install), otherwise `node`.36- `python` for data wrangling and text.37- `powershell` on Windows, `bash` on Unix, for filesystem and glue work.3839Match the language to the task and to what is installed. A two-line shell loop40beats a Python project for a rename; Python beats shell for parsing structured41data.4243## Write small, run, verify4445- Write the smallest script that does the job. No scaffolding, no project, no46 dependencies you do not need.47- For anything that mutates files or data, look before you leap: print what it48 would do first, or operate on a copy, then run for real. Destructive sweeps49 deserve a dry run.50- Run it and check the result actually matches what you intended.5152## Clean up5354The script is scaffolding, not a deliverable. When it has done its job, delete it55so it does not litter the repo or get committed by accident. Keep it only if the56user wants it as a reusable tool, in which case put it somewhere sensible and say57so. Never commit a throwaway script as a side effect.5859## Before you proceed6061Before grinding through a repetitive task by hand, ask: would a short script do62this in one run for fewer tokens and less time? If yes, check the available63runtimes, write the minimal script, run it, verify the output, and remove it. If64the task is small or needs judgment per item, do it directly instead.
TheArmagan