Troels Frimodt Rønnow

I have a folder on my laptop called ~/os. It is the most boring directory I own — eight markdown files, no code, no fancy structure. It is also the single highest-leverage thing I have built in the last year, and I almost did not build it because it looked too simple to be worth the time.

That folder is what turned Claude Code from a smart autocomplete into something I now think of as a daemon. Same binary, same model, same MCP servers. The difference is that it remembers me between sessions and runs jobs while I sleep. If you only use Claude Code inside an IDE to fix flaky tests, you are getting maybe a fifth of what the tool actually does.

The four layers nobody explained to you

Moritz Kremb laid this out cleanly on Behind the Craft. His personal OS has four layers that stack:

A folder with memory. Not a git repo. A directory Claude reads at the start of every session — who you are, what you are shipping this quarter, what it learnt last time.
Tools. APIs, MCP servers, CLIs. The hands.
Skills. Reusable instructions for repeated work — "upload these video files", "refill the grocery cart", "draft the weekly review".
Routines. Scheduled jobs that fire on cron.

The reason this matters is not the taxonomy. It is the order. Engineers reach for skills and routines first because they look like code. The folder feels like documentation, so we skip it. Six weeks later you have a graveyard of half-working automations and no idea why the agent forgot what you told it last Tuesday.

Build it backwards. Folder first. Routines last. If you ever find yourself writing a skill before you have written a paragraph about who you are, stop.

The grocery skill is not about groceries

Moritz's grocery example is the one I keep recommending to people. He does not type out what he wants every Sunday. He has a markdown file that tells Claude how to read his weekly meal plan, check the last receipt for what is still in the fridge, hit the supermarket's API and refill the cart. He approves once. The job runs.

This is not impressive because it is groceries. It is impressive because it is cheap. A markdown file plus an MCP. The same machinery you would build for "deploy on green" works for "feed my family". Once the OS exists, the marginal cost of the next skill is roughly the time it takes to type out the instructions.

If you have ever spent an afternoon stitching together Zapier and three webhooks to do something that almost works, you already know why this feels different. Zapier sells you a graph of nodes. Claude Code sells you a shell that can read prose. Prose composes; node graphs do not.

The leak in your second brain

Skills are the output side. The harder problem is what feeds the agent in the first place.

Wyndo's piece on Michael Simmons's setup puts a finger on the gap I had been ignoring for two years. Articles, web clippings, book highlights — most of us already pipe those into Obsidian or a notes vault and point Claude at the directory. Solved problem.

Podcasts do not make it in. We listen on the commute, hear something good, forget which episode it was a week later, lose it. The Dwarkesh interview where someone said the thing about scaling — gone. The Lenny's episode with the pricing framework — gone. Hours of the highest-density thinking in our industry never become input.

Simmons fixes this with Snipd. Tap a button when something lands; Snipd cuts the clip, transcribes it, attributes it, and syncs the starred ones into the vault. He is sitting on roughly 11,000 notes, a lot of them captured by tapping a screen while walking the dog.

The compounding move is not the app. It is the principle behind it: anywhere you consume information without capturing it is a leak in your second brain. Podcasts are the obvious leak. Slack DMs are another. Voice memos. Video calls. Pick the leak that costs you the most and plug it before you build another skill.

The engineering problem hiding in a productivity post

Here is where most of the existing personal-OS content goes soft. It is written for creators, so it stops at the workflow. For an engineer the interesting questions start exactly where those posts end.

How do you version a memory file so two machines do not fight over it? How do you sandbox a routine that could burn $40 of API credits overnight if something loops? How do you write a skill that fails loudly instead of silently ordering the wrong groceries? How do you keep a folder of secrets out of Claude's context when it does not need them, and how do you audit that you actually kept them out?

These are the problems you already solve at work. State management. Idempotency. Observability. Secret scoping. Blast radius. The "user" being you instead of a customer does not change the engineering — it just changes the stakes. Corrupting your own inbox is more painful than corrupting a staging table, and there is no on-call to page.

If you are already good at this, you have an unfair advantage. Most people building personal OSes right now are not engineers — they are creators with a knack for prompts. Their setups work until they do not, and then they have no idea what broke. You can build the same thing and have it survive contact with reality, which is the only version that compounds.

A prediction you can disagree with

Within eighteen months, "personal OS repo" is going to be a thing engineers talk about the way we currently talk about dotfiles. Most of them will be private. The ones that get shared publicly will be templates, not finished systems, because the value is in the memory layer and the memory layer is, by definition, yours.

The corollary is the part I would bet on: engineers who start one in 2026 will have a year of compounded context by the time the rest of the industry catches up. The ones who keep treating Claude Code as a smarter rubber duck will start every session from zero. Same model. Different leverage.

The plausible counter is that Anthropic — or someone — ships a hosted version that flattens the moat. Your folder lives in their cloud, skills are a marketplace, memory is a managed service. If that happens fast enough, the DIY phase ends before most engineers notice it started.

I do not think it happens fast enough. The folder is too personal, the skills are too specific to one human's actual life, and the kind of person motivated to build this in 2026 is exactly the kind of person who does not want their second brain on someone else's server. The hosted version will exist. The serious engineers will not use it.

The small move I'd start with

Do not build a routine this week. Do not write a skill. Open a directory called ~/os — or whatever you want to call it — and put one file in it. A markdown document that says who you are, what you are working on this quarter, what tools you use, and how you like Claude to talk to you. Point Claude Code at it. Use it for one real non-coding task and notice what it forgets. Write that down too.

That is the OS. Everything else — the skills, the routines, the podcast pipeline, the calendar agent — is just layers on a folder you have not created yet.

Sources I drew from: