Three destinations for 44 projects: how I organize my code, files and notes

A developer described reorganizing 44 real projects — four times the 11 previously declared — into three destinations: GitHub for code, OneDrive for binaries and Obsidian for knowledge. The system, enforced through Claude Code's global instructions file, adds an intake airlock folder, three-way version bumping across package.json, pubspec.yaml, pyproject.toml and composer.json, a per-project pilotage/ folder with eight tracking documents, and written read-only limits on the coding agent with explicit exceptions for version bumps and tracking files.

My inventory counted 44 real projects against 11 declared. Today I sort everything into three destinations: GitHub for code, OneDrive for binaries, Obsidian for knowledge. On top of that sit a sorting airlock, a version kept in three places, one pilotage/ folder per project and written limits for my coding agent. My underlying problem fits in one sentence: I create more projects than I close. The inventory produced these numbers: Reality was four times what I had declared, and half of the projects had no backup. The rules below live in Claude Code's global instructions file. They apply whichever folder I launch the agent from. Every file has a single place, set by its nature: OneDrive holds about 300 GB in files-on-demand mode, and that mode is deliberate. I treat it as a destination, not as something to sort: I don't scan it and I don't pull it back in bulk. I also check that a file isn't already there before copying it, because I already have duplicates. Four prohibitions protect this split: .git during editing, and GitHub already covers that need. .gitignore keeps it out. I also back up branch by branch, never in one block. Turning on OneDrive sync for my entire workspace would pull the code and the vault in with a single setting, so that option stays forbidden. My development folder splits into three segments: On GitHub, each repository name starts with its segment's prefix. A topic gives its status: actif active , dormant or archive . All client repositories are private, without exception. Nothing enters the development folder or the vault directly. An incoming item, whether from OneDrive, a clone or a transfer, first goes through an airlock folder, where I sort it before filing it. A regenerable folder has no place in a repository or an archive. Here is my full exclusion list: node modules .next .nuxt dist build out .output target vendor .venv venv pycache .dart tool .gradle Pods DerivedData .terraform coverage .cache .turbo bin obj A versioned project carries its number in three places that must always agree: package.json , pubspec.yaml , pyproject.toml or composer.json . v . A Claude Code skill updates all three at once. Semver is strict, and conventional commits set the version level. I made this bump proactive on August 20, 2026, because forgetting it had become the norm. As soon as a committed batch contains at least one feat or fix , the agent bumps without waiting for me to ask. It then stops and displays the push command. A dependency upgrade, through Renovate or npm update , triggers no project version. Every dev project must keep a pilotage/ folder French for "steering" with eight documents: roadmap, todo, done, work-log, pending-decision, decisions, bugs and quality-checklist. The docs/CONTEXT.md file remains the short entry point and links to this folder. Before acting, the agent reads this state, then checks git status and git log . If the folder is missing, it offers to set it up. A new project gets one from the start. Three rules keep this tracking reliable: done.md without proof. TASK- , BUG- or DEC- are never used twice. This tracking gets committed with the batch of work, and it doesn't reach GitHub without my approval. On my projects and files, the agent works read-only by default. The bump and the pilotage folder are two deliberate write exceptions. The other limits are explicit: git push For the other side of my workstation, I wrote separately about how I set up my Mac https://dimitriaigle.fr/articles/configurer-mac-dev-en . My rules sort projects, they don't close them, and this article announces no drop in these numbers. I keep this finding as a finding, not as a condition for creating anything: a 45th project remains possible. It will get a prefix, a status topic and its pilotage/ folder.