AITechnology

Building a personal operating system with Claude Code

· 5 min read

Claude Code is super useful if you point it at a codebase. I found it even more helpful when I pointed it at my life.

The result is something I call life-os: a personal operating system with no app and no dashboard, just a folder of markdown files and a set of recurring conversations with an LLM that has read everything and forgets nothing.

First, whether this is for you: if you already use Claude Code (or Claude Cowork, or really anything with tool access) for work, you have everything you need. If you don’t, this isn’t a getting-started guide — it assumes you’re already comfortable wiring up MCP servers and living in plain-text files. The leap I’m describing isn’t technical. It’s deciding that the same tool you use to refactor code can run your week.

Some context on why I bothered: I work in a role where I wear a lot of hats, I have three kids, and I’m slowly winding down a side business in my free time (which I have none of). Strategy comes naturally, and so does hammering away at whatever’s in front of me. The weak link – the part I have to spend disproportionate energy to overcome – is the middle: decomposing goals into next actions, remembering on Thursday what Tuesday Mike committed me to (Tuesday Mike, it turns out, is a jerk), and tracking tasks that have been delegated or are waiting on third-parties.

So I automated the middle.

How it works

The architecture is extremely simple. Claude Code connects to my real data through MCP servers — Bear, Todoist, Google Calendar, Home Assistant, and even my Oura ring. My goals live in a goals.md. Household logistics live in a context.md. And every ritual is a markdown file of instructions that Claude reads on demand when I say a trigger phrase. Want to change how a ritual behaves? Edit the file. That’s the whole deployment pipeline.

The rituals that actually earn their keep:

The workhorse is the Daily Pre-Brief. When I say “pre-brief,” Claude silently pulls my calendars, my full task pool, yesterday’s review, and a behavioral profile (more on that in a minute), then presents a recommendation — not a menu. Something like:

Tuesday — Marketing Day. Two calls: 10:00 author check-in, 2:30 vendor sync.
~6.5h usable work time. Kids with Grandma 10am–4pm. One task carried from Monday.

Today — Work (~3.5h in a ~6.5h window)
1. Prep the author check-in            [15m] — due today
2. Draft the Q3 launch one-pager       [1h]  — due Thursday, pulling forward
3. Review the pricing spreadsheet      [1h]  — carried from Monday
4. Reply to the distributor thread     [30m]

Today — Personal (~1h)
1. Mow the lawn                        [1h] — weather holds

Defer
- Review Accounts Payable approvals → Thursday (Ops day; not urgent)

Delegate
- Check on status of pallets from EU → [ops]. What to say: "Can you call the freight forwarder and check on the status of the EU order?"

Drop
- "Look into podcast hosting" — superseded; we picked a host last week.

Any changes? Or should I run with this?

I react to that plan and make changes; I don’t construct it. That distinction is the entire point — constructing the list is exactly the kind of work I’m worst at when it’s 7am. The ritual prompt is blunt about it: Claude makes the recommendation. I react. Don’t present options — present a recommendation.

The system learns from being wrong

Every time I override the morning triage (“no, that moves to Thursday”), the correction gets logged with my stated reason. Periodically, a ritual mines those logs for patterns — nothing counts as a pattern until it’s happened at least three times — and writes the conclusions into a mike-patterns.md file that the pre-brief silently reads every morning. So far it’s distilled ~58 corrections into rules like “never defer a task under 15 minutes” and “month-end financial tasks can’t be done until the month ends, even if I have time earlier in the week”.

The same ritual calibrates time estimates from my completed-task history. From 119 labeled tasks, it’s learned that “find a document” is a 15-minute job and “update pricing for 2027” is a 4-hour one, and it applies those numbers by matching the wording of new tasks, not their labels. The assistant I have now is measurably sharper than the one I had three months ago, and there’s a mechanism making that continue.

Two other design decisions turned out to matter more than I expected. The AI never writes my journal: my daily logs are recorded verbatim, because ten years from now I want to read what I actually said, not what a model thought was important. And the system is allowed to produce nothing — a brain dump with no new action items is a valid outcome, and tasks that are secretly wishes get migrated out of Todoist into a someday-backlog instead of rotting with fake due dates. A system that manufactures work to justify itself is a system you stop trusting.

If you build one

Start with one ritual, not fifteen. A ten-minute daily review — the AI reads your calendar and task list, you describe your day — will teach you more about what you actually want than any amount of upfront architecture.

Add the corrections loop early. It’s the flywheel that turns a static prompt into something that gets better; everything else is furniture.

And keep it all in plain files you can read and edit. The whole reason this works is that nothing is hidden — I can open any ritual and see exactly why the system did what it did. The moment your system’s behavior is opaque to you, you’ll stop trusting it, and a life system you don’t trust is just another to-do app.

Leave a comment

Your email address will not be published. Required fields are marked *