The Itch That Started It All

Every morning, I was doing the same sequence of tasks: pulling the latest changes from several Git repositories, checking which tasks were due today in my task manager, and opening the set of files I'd been working on the day before. It took maybe five minutes — but five minutes, repeated daily, across months, is hours of friction. So I decided to build a small command-line tool to handle all of it with a single command.

This post is a behind-the-scenes look at the project: what I built, the decisions I made, and what I'd do differently.

The Stack: Keeping It Simple

I chose Node.js with the Commander.js library for argument parsing. I considered Python (with Click), and honestly either would work well. I went with Node because it's already in my daily workflow and the ecosystem for file system operations is familiar to me.

Key dependencies:

  • commander — Clean argument and subcommand parsing.
  • chalk — Colored terminal output (makes errors and success messages scannable).
  • execa — Better child process handling than the built-in exec.
  • conf — Persistent configuration stored in the user's home directory.

Core Features I Built

1. Morning Sync

Running dev morning iterates over a configured list of project directories and runs git pull in each. It reports success/failure with clear output and skips directories that don't exist or aren't Git repos. Simple, but surprisingly satisfying.

2. Quick File Launcher

I built a "bookmark" system into the CLI — dev open [alias] opens a file or directory in my editor of choice. Aliases are stored in the config file. No more navigating to deeply nested project folders manually.

3. Task Snapshot

Using the Todoist REST API, the tool fetches tasks due today and prints them in the terminal at startup. This keeps my to-do list visible without switching context to a browser.

What I Learned

  • Config files are a must. Hardcoding paths and preferences is an instant dead end. Using a proper config store from day one made the tool portable across machines.
  • Error handling is the real work. The happy path took an hour. Making the tool graceful when things go wrong took three times as long.
  • Ship ugly, then polish. The first version had no color, no help text, and barely any error messages. That's fine — it worked, and the polish came later.

The Result

The tool now lives in a private GitHub repo, synced across my machines. What took me 5 minutes of manual steps each morning now takes about 4 seconds. More importantly, it's entirely mine — I can extend it however I want, without waiting for any app or service to add a feature.

If you're on the fence about building your own tooling: start with one repetitive task. Keep the scope tiny. You'll be surprised how much momentum a small win creates.