Build a Personal Developer Command Center with tmux, ripgrep, and Make

Build a Personal Developer Command Center with tmux, ripgrep, and Make

A lightweight command center can cut context switching dramatically by turning your terminal into a fast, repeatable workflow hub. This guide shows how to build one with shell aliases, tmux, rg, and make, using patterns that align with modern automation and fast pre-checks before review or CI.

Why this workflow helps

Most developer slowdown comes from jumping between tools, rerunning the same checks, and forgetting the exact commands for each project. A command center fixes that by making the terminal the place where you search, run, inspect, and package work. GitHub’s workflow guidance emphasizes breaking work into smaller agent-ready tasks and keeping automation safe and repeatable, which is the same principle behind a good terminal workflow.

A well-designed setup should be fast, discoverable, and boring in the best way. If a command takes too long or is hard to remember, you will avoid it and the workflow will collapse. Pre-commit guidance follows the same rule: keep checks quick, consistent, and documented.

Core tools

Use these four building blocks:

• tmux for persistent sessions and panes.
• rg for very fast searching across code.
• make for project tasks with memorable names.
• Shell aliases or functions for tiny recurring actions.

These tools work well together because each one handles a different layer of flow: session management, code discovery, task execution, and shortcuts. GitHub’s issue automation and triage docs also reflect the value of structured, repeatable steps over ad hoc manual work.

Step 1: Make tmux the home base

Start with a named session per project so your work survives terminal restarts and you can split tasks into panes. A simple pattern is one pane for editing, one for tests, one for logs, and one for command output.

tmux new -s shop-api

Inside the session, create panes for common tasks:

### Split vertically
tmux split-window -h

### Split horizontally
tmux split-window -v

### Move between panes
tmux select-pane -L
tmux select-pane -R
tmux select-pane -U
tmux select-pane -D

A practical setup is to keep the editor in one pane and use the others for npm test, docker compose logs -f, or a local server. That reduces the loop from “switch app, rerun command, switch back” to “look right, press key, continue.”

Step 2: Add project-specific make tasks

make gives you a stable command layer over messy project internals. Instead of remembering a long test or build command, expose a short task name.

.PHONY: setup test lint format dev clean

setup:
    python -m venv .venv && . .venv/bin/activate && pip install -r requirements.txt

test:
    pytest -q

lint:
    ruff check .

format:
    ruff format .

dev:
    python -m app

clean:
    rm -rf .venv .pytest_cache .ruff_cache

Now your workflow becomes:

make setup
make lint
make test
make dev

This is useful because the command names stay stable even if the internals change. That is the same idea behind good workflow automation: hide complexity behind a simple interface.

Step 3: Use rg for instant code discovery

rg is ideal for finding the answer to “where is this thing defined?” without opening a full IDE search UI. Use it for symbols, config keys, endpoint names, and string references.

rg "checkout" src tests
rg "DATABASE_URL" .
rg "TODO|FIXME" glob '!node_modules'

For structured navigation, combine rg with less or your editor:

rg -n "authMiddleware" src | less

A strong pattern is to search before opening files. That sounds minor, but it prevents many of the tiny interruptions that drain focus during debugging and feature work.

Step 4: Create shell shortcuts

Add a few functions to your shell profile for the actions you repeat daily.

croot() {
  cd "$(git rev-parse show-toplevel)"
}

branch() {
  git branch show-current
}

serve() {
  make dev
}

A few more useful helpers:

gclean() {
  git status short
  git branch merged | grep -vE '^\*|main|master'
}

Keep these small and obvious. If a helper is too clever, you will forget what it does and stop trusting it.

Step 5: Add a fast pre-check loop

Before you ask CI to validate your work, run the smallest useful local checks. Pre-commit guidance emphasizes fast hooks because slow checks get skipped. That same logic applies here: make the local loop quick enough that you actually use it.

A good local sequence is:

make format
make lint
make test

If your project is larger, split checks into tiers:

quick-test:
    pytest tests/unit -q

full-test:
    pytest -q

ci-check:
    make lint
    make quick-test

This gives you a fast confidence pass for ordinary edits and a heavier pass only when needed. That mirrors modern automation guidance that encourages small, structured checks before bigger pipeline work.

Step 6: Make debugging repeatable

When debugging starts, create a standard pane layout and stick to it. One effective arrangement is:

• Pane 1: editor.
• Pane 2: test runner.
• Pane 3: app logs.
• Pane 4: shell for quick searches and experiments.

Example command sequence:

tmux new -s debug-app
tmux split-window -h
tmux split-window -v
tmux select-pane -t 0
tmux send-keys "make dev" Enter
tmux select-pane -t 1
tmux send-keys "make test" Enter

This gives you a stable “debug cockpit” instead of an improvised mess. Once you use the same layout a few times, switching between tasks becomes automatic.

Step 7: Store the workflow in the repo

The best workflow is one your teammates can adopt without a private knowledge transfer session. Put the important commands in the repository, usually in README.md, Makefile, or a short docs/workflow.md. GitHub’s docs for issue triage and agentic workflows both show how much smoother processes become when the rules and actions are explicit.

A simple docs/workflow.md might include:

### Local workflow

1. Start a tmux session.
2. Run `make dev`.
3. Run `make lint` before committing.
4. Run `make test` before opening a PR.
5. Use `rg` to find existing implementations before adding new code.

That makes the workflow shareable, not personal. It also reduces onboarding time for new contributors.

A full example

Suppose you are fixing a bug in an API endpoint. Your routine could look like this:

tmux new -s orders-api
### Pane 1
make dev

### Pane 2
make test

### Pane 3
rg -n "orders" src

### Pane 4
git status short

Then you make the change, run the targeted test, and finish with the broader local checks:

make lint
make test

If everything passes, you open the PR with confidence and let CI do the final gatekeeping. That sequencing keeps local feedback fast while preserving the safety net of automated checks.

Common mistakes

• Making make tasks too broad, so one command does everything and nothing is understandable.
• Creating too many shell aliases, which turns shortcuts into a second language.
• Using tmux without a standard pane layout, which defeats the point of repeatability.
• Running slow checks on every tiny edit, which encourages people to stop using them.
• Burying the workflow only in memory instead of the repository docs.

The goal is not terminal wizardry. The goal is reducing friction so that the right action becomes the easy action.

Suggested starter setup

If you want the smallest useful version, start with this:

### ~/.bashrc or ~/.zshrc
alias croot='cd "$(git rev-parse show-toplevel)"'
alias gs='git status short'
alias rgx='rg -n'

### In your project Makefile
lint:
    ruff check .

test:
    pytest -q

dev:
    python -m app

Then create a tmux session whenever you begin focused work. That gives you a simple, repeatable workflow that you can refine over time without overengineering it.

-

Rizwan Saleem | https://rizwansaleem.co