refs-mcp

# refs You have a `~/dev/refs/` folder too, don't you? The one where every time you want to read someone's codebase — study `drizzle-orm`'s query builder, skim `next.js` internals, grep through `playwright` — you run ```bash git clone https://github.com/foo/bar.git ~/dev/refs/bar ``` and then months later you've got a hundred loose checkouts at the top level, half of them stale, two of them accidentally the same repo under different names, and no idea which ones are your work vs. someone else's code. You keep meaning to organize it. You never do. Nobody wants to write a housekeeping tool for their own scratch directory. This is that tool. ## What it does Run `./reorg.sh --apply` and your pile becomes this: ``` refs/ ├── facebook/ │ └── react/ ├── vuejs/ │ └── vue/ ├── microsoft/ │ ├── playwright/ │ └── ... └── ... (one directory per GitHub owner) ``` No matter where a clone was before — flat at top, nested in a mis-named folder, duplicated under two names — it ends up at `<owner>/<repo>/` based on its actual `git remote`. Duplicate clones of the same upstream get parked aside for review instead of clobbering. Random non-repo content (your notes, binaries, scratch dirs) gets evicted out of the tree entirely. Empty pseudo-owner folders get pruned. Every move is journaled. `./reorg.sh undo --apply` reverses the most recent run. Nothing magical — plain `mv`, `rmdir`, `git`. ## The daily loop ```bash ./reorg.sh --apply # you cloned some more stuff; put it where it belongs ./status.sh # quick look at what's dirty and what has updates ./update.sh # git pull every clean repo with remote changes ``` ## About the git repo you're looking at This directory is itself a git repo, but it doesn't track the hundreds of cloned reference repos — those are checkouts you can always re-clone. It only tracks the tooling (`reorg.sh`, `status.sh`, `update.sh`) plus the two generated indexes (`index.md`, `index.html`). A whitelist-mode [`.giti…