Command Catalog: A Practical Golang CLI

March 12, 2026

Summary

Why I Built This CLI

This project started with a very boring problem.

Almost every day, I had to run the same long commands: clean Docker builder cache, kill a process stuck on a port, grab logs from a specific namespace. None of these commands are hard, but they are long enough to break your flow.

At first, I relied on shell history. Then aliases. Then random notes. It worked... until it did not. I kept forgetting exact flags, retyping commands, and losing minutes on tiny context switches.

One day, after rewriting a big command for the third time in the same session, I thought: why am I still doing this manually?

That is when I built command-catalog-cli (cs). The idea was simple: give every bloated command a short key, then execute that key whenever I need it.

In practice, it feels like creating a personal dictionary for terminal workflows.

Instead of this every time:

kill -9 $(sudo lsof -t -i:$port)

I do this once:

cs create 'kp $port' 'kill -9 $(sudo lsof -t -i:$port)'

Later, I just run:

cs kp 3050

That small change removed a lot of friction from my day: fewer mistakes, less typing, and more focus on the real task.

Install in One Minute

If you want to use cs globally on your Linux machine:

make build
make install

This installs the binary to ~/.local/bin/cs.

Then make sure ~/.local/bin is in your PATH:

export PATH="$HOME/.local/bin:$PATH"

After that, you can call it directly:

cs list

The Core Idea: Command Keys for Long Commands

Under the hood, the CLI stores command templates in a local catalog file. Each entry has:

  • a key (short name you call)
  • a value (the real shell command executed behind the scenes)
  • an optional dangerous flag for confirmation before risky execution

At a high level:

  1. You register the command once.
  2. You execute by key many times.
  3. You keep your workflow consistent and predictable.

It is especially useful when commands are:

  • long
  • repetitive
  • easy to mistype
  • used across multiple projects

Quick Start and Real Examples

Build and run:

make build
./cs list

Create commands:

./cs create 'docker cc' 'docker builder prune -a'
./cs create 'kp $port' 'sudo kill -9 $(sudo lsof -t -i:$port)'
./cs create 'logs $ns $lines' 'kubectl logs deployment/api -n $ns --tail=$lines'

List saved commands:

./cs list

Execute by key:

./cs docker cc
./cs kp 3040
./cs logs prod 200

Delete by id:

./cs delete <id>

Check which catalog file is in use:

./cs path

Applying It in Daily Workflow

In practice, the value of this tool appears in daily repetition.

1) Personal productivity

You stop wasting mental energy remembering command syntax and focus on the task itself.

2) Project-specific catalogs

You can point to a custom catalog with CS_CATALOG_PATH:

export CS_CATALOG_PATH="$HOME/my-project/.cs/catalog.json"
./cs list

This is useful when each repository has its own operational commands.

3) Safer execution for risky commands

For commands that can be destructive, enable confirmation:

./cs create 'wipe docker' 'docker system prune -a --volumes' dangerous=yes

Now execution asks for confirmation ([y/N]) before running.

In short, If your goal is quick access to long terminal commands with minimal friction, a command catalog is a strong middle ground.

  • Faster execution of repetitive commands
  • Less context switching and less syntax memory load
  • Reduced copy/paste errors
  • Supports parameterized templates (for ports, namespaces, lines, etc.)
  • Local catalog keeps your command set portable and organized

Conclusion

I built this CLI to remove terminal friction from my daily workflow, and it has done exactly that.

When you map long commands to short, meaningful keys, you move faster, make fewer mistakes, and keep your command line habits clean.

If you constantly type the same long Linux commands, this approach is worth adopting today.

References