DEV Community

Cover image for I Have a ~/bin Folder With 30 Scripts I Don't Remember Writing
Kairi
Kairi

Posted on

I Have a ~/bin Folder With 30 Scripts I Don't Remember Writing

I keep a folder at ~/bin/ full of shell scripts. There are 30-something of them. At least half were written by AI at my request. I don't remember most of them existing.

And that's fine. The folder isn't a catalog of tools I reference. It's a spill-cache for ad-hoc automation that turned out to be reusable.

Here's what's in there, how it got there, and why I stopped trying to organize it.

What's actually in the folder

I just ran ls ~/bin | wc -l. 34 files.

Sampling a few:

  • tasks — 80-line Python wrapper around a sqlite file that tracks what I'm mid-way through. I use it daily.
  • trim-silence — ffmpeg one-liner that cuts silence from audio files. I use it weekly.
  • rename-padded — rename numbered files to zero-padded form (post-1.mdpost-001.md). I used it once, haven't touched it since.
  • gitwip — shows me branches older than 7 days with uncommitted changes. I run it every couple weeks when paranoid.
  • fetch-latest-ogimage — hits an API, downloads a PNG, optimizes it, renames it to today's date. I built it for a specific project six months ago.
  • note-today — opens ~/notes/YYYY-MM-DD.md in my editor, creating it if it doesn't exist. Muscle-memory now.
  • bulk-resize — batch-resize images in a directory with imagemagick. Used twice, staying forever.

Most of them are 5-30 lines. None are well-documented. Half have terrible names.

How they got there

The pattern is always the same:

  1. I'm in the middle of something
  2. I hit a papercut: "I need to do X to 40 files"
  3. Instead of doing X 40 times or Googling for 10 minutes, I ask Claude Code for a one-liner
  4. I paste the output into ~/bin/<guess-a-name> and chmod +x it
  5. I use it, finish the task, close the terminal
  6. I forget it exists

Weeks or months later, I hit a similar papercut and either:

  • Rediscover the old script (bin/ + tab completion shows me forgotten options)
  • Write a new one because I didn't know about the old one

Both are fine. The old script cost 90 seconds to write. If I forget and write a second version, I've spent another 90 seconds. At no point was there a high-cost step.

Why disorganization is the feature

I've tried organizing scripts before. I've had folders with media/, git/, file-ops/, subfolders, README files listing what's in each.

They all decay. I'd add a script and forget to update the README. I'd miscategorize something. The README would get out of sync with reality within a week.

What works: flat folder, grep-friendly names, trust that you'll rediscover via tab completion.

When I think "I need something for audio...", I type bin/ + a + tab. The options narrow. I find audio-normalize, audio-trim-silence, or nothing — and then I make a new one in 90 seconds.

The cost of a duplicate is lower than the cost of maintaining organization. So I don't maintain organization.

Why this is AI-compatible

The key unlock is that writing a script is now 90 seconds. Before AI, writing a small utility was a 10-20 minute task — enough friction that I'd "just do it manually this one time" instead of automating.

Now the calculus is flipped. Writing the script is faster than doing the task manually when the task is >3 repetitions. So I automate almost everything, and the folder fills up with one-off utilities.

The folder isn't a carefully curated toolkit. It's a fossil record of every mildly-annoying task I've hit in the last year.

The practical setup

For anyone who wants to replicate:

  1. mkdir ~/bin if it doesn't exist
  2. Add to .bashrc / .zshrc:
   export PATH="$HOME/bin:$PATH"
Enter fullscreen mode Exit fullscreen mode
  1. When you hit a repetitive task, ask Claude Code / any AI for a shell one-liner or short script
  2. Save it to ~/bin/<some-name>, chmod +x
  3. Don't organize. Don't document. Just let it grow.

Check the folder once a quarter for scripts that broke due to API changes or dependency updates. Fix or delete.

What doesn't belong in ~/bin

Stuff that should go elsewhere:

  • Project-specific automation → lives in the project's scripts/ folder or package.json
  • Secret-dependent scripts → needs a proper ~/.config/X with chmod 600, not a bin/ script with hard-coded keys
  • Scripts other people on your team need → live in a shared repo
  • Anything that takes >1 minute to run → probably wants to be a proper CLI, not a one-off

My ~/bin/ is for single-user, self-contained, ad-hoc utilities. The rule is: if I had to explain it to someone else, it'd go somewhere else.

The meta-pattern

Every time I've tried to be disciplined about small automation, I've ended up doing less of it because the overhead of "doing it right" killed the flow.

The opposite works better: lower the bar, embrace chaos, trust rediscovery.

The folder is messy because the mess is cheaper than the organization. And the chaos is productive because each piece of chaos is 90 seconds of AI-assisted work that replaced 10 minutes of manual repetition.

34 scripts. I remember maybe 8 of them. The other 26 might never run again, or might run tomorrow when I type bin/ + tab and rediscover them.

Either way, the folder has paid for itself 100 times over.


Three cups of tea. Still tired. Shipping anyway.

Top comments (0)