Systems

I run Claude Code against a single mono-repo that holds every active project, the automation scripts, the knowledge vault, and the generated output. Coding, research, writing, deploying and debugging all happen through that one surface. There is no context-switching tax between "the writing tool" and "the deploy tool" because there is only one tool.

The custom command library has grown to a few hundred entries. Some are complete pipelines: one command researches a topic, writes the piece, generates a cover image, and either publishes it or commits the file — in a single call. Others are conversational rather than mechanical. The evening reflection command runs a coaching session against four behavioural patterns I have mapped for myself, and calls them out when it sees them. That is not automation in the usual sense; it's a second opinion that already knows the history.

Context management is its own discipline. Analysis runs in a sandbox so raw file bytes never enter the conversation window. Reference material that gets read repeatedly is cached rather than re-sent. Work with three or more genuinely independent parts gets split across parallel sub-agents with clear file boundaries; anything with a dependency chain stays sequential, because wrong parallelism is slower than no parallelism.

The failure mode is drift. A command breaks quietly when the service underneath it changes an API, and nothing surfaces the breakage until I try to use it. The mitigation is a periodic audit rather than an expectation of getting it right first time. Every gotcha I hit twice gets written into the project instructions file so the next session inherits the fix instead of rediscovering the bug.

The interface is only as good as what sits behind it — undocumented edge cases compound into invisible friction.

The server is a modest single-core box in Singapore. Docker Compose manages the stack: a workflow engine, an agent API, a vector store, Postgres and Redis, tracing, static file serving, backups and health monitoring. It is headless and managed over SSH. Nothing about it is impressive — that's the point. It has survived two years because it is small enough to understand end to end.

The scheduling split is the design decision that matters most. Anything needing the machine itself — Docker, local files, the messaging bridge — runs as a cron job on the server. Anything that only calls external APIs and reports a result runs as a cloud-scheduled routine instead, so it doesn't compete for memory and doesn't die when the box is under pressure. Roughly twenty routines and twice as many cron jobs, split on that single rule.

Everything that runs unattended reports into one channel. A daily intelligence digest, a weekly product scout, an algorithm-update watcher that stays silent unless something actually moved. That last one is the design I'm most attached to: a monitor that produces no output on a quiet day is doing its job, and most people build the opposite.

Mobile control runs through a messaging bot that executes commands on the server under a dedicated non-root account, as a service unit so it survives reboots. Things break at inconvenient times. Being able to diagnose and restart from a phone, on a motorbike, in another country, is worth more than the elegance of the code that does it.

The recurring constraint is memory. Two gigabytes across sixteen services means heavy operations queue behind each other, so an hourly health monitor reports pressure and anything inference-heavy goes to the cloud rather than the box. The limit is a forcing function — anything that can't justify its footprint eventually gets dropped, which is a healthier default than infinite capacity.

Separate report-only work from machine-bound work. Mixing them is how you get 3 a.m. dependency failures.

The vault is a folder of markdown files inside the same mono-repo as the code — operational reference, project notes, CRM entries, diary, research. Keeping it inside the repo means it is version-controlled and backed up by the same nightly sync as everything else. No separate service, no proprietary format, no dependency on a company continuing to exist.

The operational layer is the highest-leverage part. Reference files get read at the start of the sessions that need them. The rule that generates them is simple: anything I have looked up twice becomes a note, and anything I have debugged becomes a gotcha entry. The index file has a hard line cap with detail delegated to separate files, specifically so loading it stays cheap — a knowledge base that is expensive to consult doesn't get consulted.

Notion covers what markdown is bad at: filtered views, structured records, anything relational. Content planning, book synthesis, contact tracking. The split is roughly — operational reference where the interface can read it directly, structured records where they can be queried. I have twice tried to collapse the two into one system and both times the result was worse than the split.

Capture runs through the messaging bot. A voice or text note becomes a dated markdown file in the vault without opening a laptop, which is the only reason the diary has survived; anything requiring a laptop gets written for three weeks and then abandoned.

The honest weakness is currency. The vault is only as good as the last time I updated it, and synthesis — turning captured notes into something usable — is still manual. A weekly nudge exists precisely because without an external prompt the review drifts. That's not a tooling problem, and I have stopped trying to solve it with tooling.

Operational reference belongs where your primary interface can read it directly — not behind an API call with a rate limit.