TL;DR

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.

The finding: 44 projects, 11 declared

My underlying problem fits in one sentence: I create more projects than I close. The inventory produced these numbers:

  • 44 real projects
  • 11 declared projects
  • 16 dormant projects
  • 22 projects with no backup

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.

Three destinations, one type of content for each

Every file has a single place, set by its nature:

  • GitHub: source code, text documentation, sanitized configurations, cleaned n8n workflows. Versioning makes it the backup of my code, restorable anywhere.
  • OneDrive: binaries, media, client deliverables, archives of closed projects, PDFs, exports. Everything git handles badly.
  • Obsidian: notes, decisions, method, technical sheets, client context. Knowledge, not files.

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.

What never crosses the line

Four prohibitions protect this split:

  • Live code stays off OneDrive: sync corrupts a .git during editing, and GitHub already covers that need.
  • No secrets in git: no environment files, keys, certificates or databases.
  • No heavy media in git: it goes to OneDrive and .gitignore keeps it out.
  • The Obsidian vault stays out of OneDrive: double sync creates conflicts, and Obsidian mobile can't open a vault inside the OneDrive app. It belongs to Obsidian Sync.

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.

Three repository segments and an airlock

My development folder splits into three segments:

  • Professional work: clients, SaaS, showcase site, internal tools.
  • Games: a separate activity, with its own segment.
  • Personal: side projects and dormant projects.

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.

What git and archives ignore

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 version kept in three places

A versioned project carries its number in three places that must always agree:

  1. The manifest: package.json, pubspec.yaml, pyproject.toml or composer.json.
  2. The top entry of the CHANGELOG.
  3. The git tag, prefixed with 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.

One pilotage folder per project

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:

  • Nothing goes into done.md without proof.
  • The agent settles no business decision for me.
  • Identifiers such as 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.

The limits I give my agent

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:

  • Dry-run before any move: it shows the plan and waits for my approval.
  • Never a deletion: it moves things to a reversible archive area.
  • Never a git push without my approval.
  • Never a git history rewrite without an explicit request.
  • No move of a project that has uncommitted changes.
  • Target inspection before overwriting or deleting it: if it contradicts its description, the agent flags it instead of acting.

For the other side of my workstation, I wrote separately about how I set up my Mac.

The number stays the reference

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.