Operating System

I call it harnesson disk; on this page I’ll call it what it actually is — my operating system.

The whole thing runs on three substrates. Each one is a different way Claude Code executes work, but they all read from and write to the same persistence layer: a git-backed markdown wiki, a Supabase database with pgvector for semantic search, and a handful of local JSON state files.

Localis a Claude Code session on my laptop. Interactive dev, skill authoring, ad-hoc research — anything triggered by me typing at the keyboard.

Cloud is scheduled Claude Code routines. My morning brief runs daily at 7:05am. Reflection sessions happen Tuesday and Friday. The wiki ingestion pipeline runs Monday. Email triage runs three times a day. All triggered by cron.

Slack is the orchestrator bot. It classifies DMs into intents, presents approval buttons for consequential actions, and exposes /run commands for on-demand workflows. Triggered by a message or a button click.

Three execution surfaces, one shared memory. That’s the whole architecture.

The knowledge pipeline follows a pattern Andrej Karpathy described for LLM-managed wikis. Captures land as raw markdown — a Slack DM, a pasted URL, a voice transcript. A triage skill compiles them into a five-domain wiki organized by topic: business, code, dharma, home, and music. That compiled knowledge surfaces back through a Streamlit dashboard for operating and Obsidian for reflection. One-way flow, no cycles.

Automations are grouped by what triggers them, not by what they do. There are synchronous asks (me typing), scheduled cron jobs, passive event listeners, and human-approved actions that wait for a Slack button press. Organizing by trigger type instead of function made the system much easier to reason about as it grew.

The building block of the whole system is a skill. A skill is a SKILL.mdfile — a self-contained prompt that both a person and Claude can read. It describes what the skill does, what inputs it expects, what outputs it produces, and any constraints. That’s it. No framework, no SDK, no wrapper class.

There are 37 active skills right now. Some are simple: session-auto-capture writes a summary at the end of every Claude Code session. Some are orchestrators: email-inboxcoordinates fetching, classifying, labeling, drafting, and queuing emails for review. Skills compose into workflows, and workflows get packaged as plugins — the plugin architecture comes from Jared Irish’s Superpowers pattern for Claude Code.

The insight (which took me a while to internalize) is that a well-written SKILL.md file is more maintainable than a Python script doing the same thing. Both the human and the model can read it, edit it, and reason about it. When something breaks, you fix prose, not code. Anthropic published how Claude Code’s internal architecture works with CLAUDE.md files; skills are the same idea extended to reusable units of work.

Every skill that does something consequential — sending an email, modifying a file, posting to a channel — goes through a human-in-the-loop approval flow. New skills start at T3: explicit approval required for every run. After ten successful executions, they can graduate to T2: a four-hour auto-approve window. Proven, low-risk skills can reach T1: fully automatic. The tiers exist because blanket automation is how you get bad emails sent to customers at 3am.

A typical day: the morning brief fires at 7:05am, pulling from Gmail and Google Calendar to produce a prioritized summary of what’s on deck. Email triage runs three times — classifying, drafting responses, and queuing them for my review in Slack. The Tibetan Spirit customer email pipeline runs every thirty minutes during business hours.

In between the scheduled routines, I run synchronous sessions for whatever I’m building. Slack-DM capture is always available — I can message a thought, a URL, or a question and it gets classified and routed to the right place. No single workflow tries to do everything. The system works because each piece is small and runs on its own schedule.

Real deployed agents right now: personal email triage (three times a day via launchd), Tibetan Spirit customer email triage (every thirty minutes), a wiki researcher for background deep research, and a chief of staff agent that assembles the morning brief.

Plain text is the right substrate.The wiki is just markdown files in a git repo. Every tool change, every model upgrade, every framework rewrite — the markdown survives all of it. I’ve rewritten the orchestration layer three times. The wiki has never needed a migration.

Skills beat code. A well-written SKILL.md file is more maintainable than a Python script because both the human and the model can read it. When something breaks, I edit prose. When I want to change behavior, I edit prose. The skill files are the closest thing to a single source of truth for what the system does.

Orchestration is disposable.The hooks, scripts, and glue code get rewritten every few months as the underlying tools change. That’s fine. The skills and the wiki persist. Investing too much in orchestration durability was a mistake I made early on and eventually learned to stop making.

Human-in-the-loop isn’t friction, it’s quality. The Slack approval flow catches more mistakes than any test suite I’ve written. It’s also how I stay calibrated on what the system is actually doing. Fully autonomous sounds appealing until you read the email it was about to send your customer.

Start with one habit.The morning brief was the first thing I built, and it’s still the most valuable piece of the system. Everything else grew from having one reliable daily touchpoint. If you want to build something like this, start with the one workflow you’d actually miss if it stopped running.