Me too - but never thought about this good tip with the "find" command. The article's caveat about storing "just the commands" (run log) applies though..

Something I used to do (many years ago, in my Uni days) was to have a script called wtf in directories with code (and some without). Most of them were no more than a text document wrapped by a #! line and cat <<here-doc so it could be read as a text file too.

The file contained what project or uni module it was for, and any significant commands (build & run one-liners), and links to documentation. Some of them had a couple of extra commands to run those one-liners if given a relevant parameter (such as “./wtf make”), like tokamak-teapot's run command but with a little extra typing. Basically a README that could potentially do a few actiony things.

Not something that I kept up in later life though. It was helpful for just me when I had a significant bunch of things actively going on or being referred back to, and particularly useful when the work was part of a group project or otherwise shared to others.

In order to deal with that in my personal projects and my personal space of my public projects, I keep a central Makefile, separate from any eventual build Makefile that the project may already have, which stores all the commands that I typically use in that directory.

This is not necessarily the best solution, as you have to name even very simple commands, but it's not so hard. What I wished was for bash to have two histories, a global history and a per directory history, so I can look at what commands are typically run in a directory. I hear it is easier to do in zsh, but I have no working solution.