mn CLI

Why I built it

Every developer has a graveyard of commands they've solved before — that one ffmpeg incantation, the exact docker compose flags for a project, the deploy command with the right env vars. They live in shell history until they don't, or in a notes app you never open while working. mn keeps them where you actually are: the terminal.

What it does

$ mn save deploy "vercel --prod"     # save it once
$ mn find deploy                     # fuzzy-find it months later
$ mn run deploy                      # re-run it without retyping

• Notes and commands, folder-scoped — work/, infra/, home/ keep contexts separate, so deploy can mean different things in different scopes.
• Keyword search across everything — an interactive picker (Inquirer) lists matches with previews; pick one to run or edit.
• Instant re-execution — saved commands run in your current shell context, so the loop is search → enter → done.
• Git-backed sync — the store is a plain folder of files under git; mn sync pushes it, so every machine has the same brain.

Build notes

TypeScript with Commander for the command surface and Inquirer for the interactive picker. Storing notes as plain files (not a database) was deliberate: it makes git the sync engine for free, keeps everything greppable outside the tool, and means losing the tool never means losing the data.

What I learned

CLI UX is real UX — flag naming, output brevity, and interactive-vs-scriptable modes are product decisions. And distribution via npm (npm i -g) taught me the practical side of packaging: bin entries, shebangs, and making a Node CLI start fast enough to not feel like a Node CLI.