Before Your Side Projects Multiply Into Chaos: An 8-Category Ledger and a Symlink Tree A developer built an 8-category project ledger and symlink tree to manage over 40 side projects, including web apps, Chrome extensions, iOS apps, and AI tooling. The system uses a single `~/PROJECTS.md` file and symlinks under `~/Desktop/All-Projects/` to avoid moving real directories, preventing breakage of absolute path dependencies in tools like Vercel, launchd, and git worktrees. The developer also created a Claude Code skill to query the ledger for project state, monetization, and URLs. This is part of my "Claude Code environment" series. Last time I wrote about an autopilot that lets Claude Code improve itself autonomously and unattended https://zenn.dev/bokuwalily/articles/claude-autopilot . But if the "pile of automation scripts" that showed up there isn't organized, you can't even decide what to hand the autopilot. So this time the topic is the system I use to classify projects and manage where they live. Counting the entries in my current ledger ~/PROJECTS.md , there are over 40 projects lined up — web apps, Chrome extensions, iOS apps, digital products, client work, AI tooling, PC automation, and OSS evaluations. Before things grew this far, I built a structure of "8 categories + a ledger + a symlink tree." This article is about that design. Claude Code kept hunting for directories scattered across ~/dev/ , ~/Projects/ , ~/digital-products/ , and ~/oss-trial/ with find ~ every single time. It wasn't just the search time — the state live/stalled/retired , the production URL, and whether it was monetized were all scattered too, so every time I asked "whatever happened to that app?" I had to reconstruct the context from scratch. The goal is to consolidate the ledger into a single file so I reach a state where "ask, and the answer comes out immediately." Here's the definition table straight from ~/PROJECTS.md . | Code | Definition | |---|---| 01-webapp | Web apps / web games that are deployed and used | 02-chrome-ext | Chrome extensions MV3 + their dedicated backend API | 03-ios-app | iOS native / delivery wrappers | 04-digital-product | note monetization, digital products, content for sale | 05-client-work | Contract / commissioned work / company repos third-party owner remote = push with care | 06-claude-tooling | Infrastructure, skills, and integrations that act on Claude / the AI agent itself | 07-pc-automation | PC automation, scrapers, CLI scripts | 08-oss-eval | Evaluation, experimentation, and sandboxing of external OSS | Adding categories dilutes their meaning, so I only create a new one "when something genuinely fits none of the eight." The decision is made by how it's delivered, not by its name. For example, autolike-license-server sounds like an API name, but it's a backend dedicated to license verification for a Chrome extension, so it goes under 02-chrome-ext . Judging by name would misclassify it as "API → server → 01-webapp ." It's tempting to think "organizing = moving folders," but in side-project development, dependencies on absolute paths hide in three places. .vercel/project.json vercel deploy points at a different project. ProgramArguments is registered as the real path. Move it, and the cron job dies. git worktree add holds the real path in .git/worktrees/