I didn't set out to build an operating system. I set out to apply for jobs.
I was using Claude Code, and I needed it to scan job boards, score listings against my profile, tailor my CV per role, and track what I'd applied to. I got that working. Then I needed email triage. Then article writing in my voice. Then workout tracking, finance logging, message aggregation across Telegram and Discord and WhatsApp.
Each piece worked. But every new Claude Code session started blank. The job pipeline I spent an hour building? Evaporated when the session ended. The writing samples I fed it? Gone. I was rebuilding the same context over and over, and it was driving me insane.
The fix was obvious in hindsight: stop treating the AI like a conversation and start treating it like a runtime. Give it persistent state. Give it a filesystem. Give it scripts it can call. Give it a configuration file that tells it who I am and what I care about.
Once I did that, I had an operating system.
I called it Super Tobi. It's open source now.
What makes it an OS and not a prompt collection
A prompt collection is what you get when you save your best ChatGPT conversations. It's stateless. It doesn't remember that you applied to Anthropic last Tuesday or that your girlfriend's birthday is in three days.
An operating system manages state, runs processes, schedules work, and enforces boundaries between things. That's what Super Tobi does:
CLAUDE.md is the kernel — a specification file that tells Claude who I am, what I'm building toward, what voice to write in, and what rules to follow. When I edit this file, the entire system's behavior changes. It's not a prompt. It's a config.
.claude/commands/ is the CLI — 19 markdown files that each define a complete system behavior. /daily-sync compiles a morning briefing from 8 data files. /war-plan calculates my job application conversion rate and tells me what to do today. These aren't prompts either — they're specs with data flows and error handling.
scripts/ are the daemons — 23 Python programs that do work Claude can't do alone. job_hunter.py scrapes career pages and fetches job descriptions. resume_tailor.py extracts ATS keywords and rewrites my CV. analytics.py calculates funnel metrics. They run on cron, get called by commands, or run standalone.
data/ is the filesystem — JSON for structured data, markdown for text, append-only for logs. No database. Every piece of state is a file that Claude can read, write, and reason about.
I wrote a longer argument for why agent coordination is fundamentally an OS problem in a separate piece. The short version: when multi-agent systems fail, the failure is almost never intelligence. It's the handoff between agents, the shared state, the scheduling — problems that operating systems solved for programs in the 1960s. Super Tobi is me applying that insight to my own life.
The commands I run every day
/daily-sync
I type this every morning and get a single compiled view of my life. Not a chatbot response — a dashboard assembled from real files:
My girlfriend's birthday coming up in 2 days, with a draft message already written. YC deadline in 27 days, application 60% done. Career pipeline: 34 applied, 8 responded, 3 interviews, with 2 follow-ups I'm late on (Helius and Anza). Learning: day 14 of system design, 8-day streak, today's topic is distributed caching. Workout: upper body push day. This week's spending: ₦42,300, broken down by category.
I've used a lot of productivity tools. Notion, Todoist, Google Calendar, various habit trackers. None of them talk to each other. /daily-sync pulls from all of them (well, from the files that represent them) into one view. That's the thing I can't go back from.
/apply jobs and the resume tailor
I'M ACTUALLY PROUD OF THIS ONE.
resume_tailor.py takes a job description, extracts keywords across five domains (AI/ML, blockchain, backend, frontend, devrel), scores my current resume against the JD, then rewrites it to maximize ATS compatibility. Not generically — per job, using the actual keywords from that specific listing.
I ran it against an Anthropic ML Engineer posting. My base resume scored 38%. After tailoring: 84%. The script had reordered my experience sections, woven in keywords like "MLOps" and "distributed systems" where they fit naturally, quantified my achievements, and switched my title from "AI Researcher" to "ML Engineer" to match their language.
Then /analytics shows me the funnel: how many jobs discovered, how many applied, response rate, interview conversion. Right now I'm at 23% response rate and 8.8% interview rate across 34 applications. Having those numbers changes how you think about job searching — it stops being an emotional rollercoaster and starts being a pipeline you can optimize.
/write
OK this is the meta one — I used this system to draft parts of this post (I'm being upfront about that). It reads my actual writing samples from DEV, Substack, and Twitter, and it tries to match my patterns. It knows about the ALL CAPS thing when I'm excited. It knows I do parenthetical tangents (like this one right here). It knows "delve" is banned.
The output needs editing. Always. But it's my voice that needs tightening, not generic AI voice that needs a personality transplant.
/outreach and /interview-prep
These are new. /outreach generates personalized cold emails and LinkedIn DMs by reading the company research I've stored in data/career/intel/. /interview-prep pulls the actual JD and company intel, generates role-specific questions, and runs mock interview sessions with coaching on my answers.
Why files instead of a database
I tried Supabase first. Spent two days on it. Then realized something that should have been obvious: Claude Code can't query Supabase. But it can read a JSON file. It can write markdown. It can grep through a folder.
The filesystem isn't a workaround — it's the correct abstraction for this problem. Claude already knows how to navigate files. Every programming language has file I/O. git gives you version control for free. And for a personal system with hundreds of files (not millions), there's no performance argument for a database.
There's also a readability argument. I can open data/career/jobs/applications.json in any text editor and see exactly what the system knows about my job search. Try doing that with a Postgres table from your phone.
How commands compose into a pipeline
The thing that separates a system from a collection of tools is that every command reads from and writes to the same filesystem:
/apply jobs
→ job_hunter.py scans career pages, stores JDs in data/career/jobs/
/analytics
→ reads data/career/jobs/
→ calculates funnel: discovered → applied → responded → interview
/apply jobs --tailor
→ resume_tailor.py reads the stored JD
→ extracts ATS keywords, generates tailored resume
→ saves to data/career/resume/tailored/
/outreach
→ reads data/career/intel/ for company research
→ generates personalized messages, tracks what's sent
/interview-prep
→ reads JD + intel + tailored resume
→ generates questions, runs mock sessions
/follow-up
→ scans all applications for overdue follow-ups
→ drafts emails, logs everything
No orchestration framework. No message queue. Each command is independent but they share the filesystem. Unix philosophy applied to a life OS: small tools that do one thing, connected by a common data layer.
Fork it and make your own
git clone https://github.com/tobySolutions/super-tobi.git my-os
cd my-os
python3 -m venv .venv
source .venv/bin/activate
pip install rich httpx requests playwright
# 1. Edit CLAUDE.md — replace my identity with yours
# 2. Edit config/settings.yaml
# 3. cp config/api_keys.env.example config/api_keys.env
# 4. Create life_systems_map_v1.md from the template
# 5. Open Claude Code. Type /status.
Step 1 is the only one that really matters. CLAUDE.md defines everything — your identity, your goals, your voice, your rules. The scripts and commands are generic enough to work for anyone. The kernel is what makes it yours.
The gap nobody's filling
Most people use AI the way people used computers before operating systems — one task at a time, start from scratch each session, no persistent state, no background processes.
Developers have figured out how to build real AI systems: multi-step pipelines with state management, error handling, scheduled runs. But that requires you to be a developer, and even then it's fragile custom scripts held together with hope.
There's a version of this that's packaged properly — with a filesystem abstraction, managed processes, a permission model, a UI for non-developers. I think that's a massive product opportunity and I have some notes on it if you're interested.
But Super Tobi is the version you can fork today.
Top comments (0)