Introducing dev: a CLI for navigating your projects

Context

I don't have that many personal repos.

My last two employers had a huge amount of them though, and here I'm just talking about the ones my team owned. So it's hard to juggle between them.

And also sometimes you also want to have that open source project codebase cloned locally, since it's what we're using in the company, and sometimes you need to look up the code.

And you might have a fork of that. And a company fork. And then a repo for building the Docker image. And then another for deploying it. And then the codebase itself.

But how do you remember where you put it? Was it under the home directory or did I create a dedicated dev/ folder? Is the kafka repository the one from Apache or is it our fork?

Wouldn't it be cool if you could navigate through them easily? And that you didn't need to think where to put it?

I've re-implemented this a few times for my own use, first in bash, then in Python. But never really put much care into it, it just "sort-of-worked".

But I've now changed computers. Where did I have that implemented? Was it just a quick script on my ~/.zshrc? Or where did I put it?

So I've decided to give it a proper place. So now I can just brew install dev and be done with it. This also gives me the incentive to iterate and improve it.

An opinionated approach to organize repositories in your file system

So instead of even thinking where to put the repo, create the proper folder structure for it, let's just always use the same structure.

Let's pick a path on your home, say ~/src/. Then the source from which you cloned that, which could be typically github.com/ (or gitlab.com/) then the org/user within that, and finally the repo name.

So e.g. for https://github.com/dsaiztc/dev it'll be just ~/src/github.com/dsaiztc/dev. Simple, right?

And whenever I want to clone a repo I'd just copy the SSH URL and run:

dev clone git@github.com:dsaiztc/dev.git

And voilà. That repo now lives on ~/src/github.com/dsaiztc/dev. Just by running that I'm actually already cd'd into that folder.

Wanna switch to another repo? Just type dev cd and search for the repo name, hit enter, and you're there.

Too lazy to search, just type dev cd something-resembling-the-repo-name and it'll search and pick the best match, and cd into that repo folder.

It's so simple, I know. Still, it's the command I use most throughout my day. And it's all just based on following the same convention on how to organize the repos in your filesystem.

How do I use this

The most obvious use case is when cloning a new repo. Just copy the *.git URL and run dev clone. That's it, I now directly open my editor (e.g. code . for VS Code).

The second use case is, well, navigating to a directory. I don't always remember the exact name of a repo. Or even if I did, I don't want to type the whole path. So I just hit dev cd and search for it. Voilà! I'm in the repo folder.

The third, most recent, and the one that feels more powerful, is leveraging this convention when working with an AI-assisted environment (say Claude Code, Codex, Cursor and the like).

Imagine you're working on a repo, you spin up a new Claude Code session and start planning for a new feature. But there is some missing context. This repo isn't the whole picture. The Docker image is defined elsewhere. Also it's using an open source Kubernetes Helm chart defined elsewhere. All these pieces are, most likely, important context to pass to your LLM friend.

Let's say I have this folder structure:

~/src/
  github.com/
    dsaiztc/
      my-service/
      my-service-image/
    apache/
      helm-chart-my-service-uses/

I start a new Claude Code session on ~/src/github.com/dsaiztc/my-service and now reference the other two repositories writing something like:

This service's image is defined on ~/src/github.com/dsaiztc/my-service-image, and the chart it's using is defined on ~/src/github.com/apache/helm-chart-my-service-uses

(If you keep adding the above to every session, then it might make sense to add it to your CLAUDE.md or AGENTS.md file)

This way it's straightforward for any LLM to extract the necessary context. If you're lucky that your documentation also lives on Markdown files in a repository, you can also dev clone that and have that path handy for your LLM to read.

You can go to dsaiztc.com/dev and learn more about it, including how to install it.

Let me know if you liked it!