A Fork-Your-Own Life OS an AI Agent Reasons Over, Without Owning Your Data
Designed, built, and shipped a fork-your-own life operating system: principles, vision, goals, areas, and projects as plain markdown an AI agent reasons over, under one rule the agent can read and question every file but never writes the record. A public MIT template plus a static launch site and privacy-by-construction adoption tracking, with the author's own corpus never committed or published.
The Problem
AI agents are good at organizing and connecting information, but handing one your whole life raises a trust problem most "AI life coach" products ignore: the moment something other than you authors your principles, goals, or journal, the record stops being yours.
The core gap is not capability; agents can already read files and ask good questions. It is a missing structure and a missing boundary, a durable, portable, self-owned place to keep the layers of a life with one hard rule about who may write them. A hosted app answers this by taking custody of the most private data a person has; a chatbot answers it by generating plausible insights nobody actually decided. Both give up ownership.
And it had to be shareable without being invasive: a scaffold others could fork and run with their own agent, while the author's content, and every forker's, never left their own repository.
The Approach
Modeled a whole life as a spec'd system: principles, vision, goals, areas, projects, and daily/weekly/monthly journal and review folders, all plain markdown in the user's own git repository, no backend and no account. The structure is committed; the content lives under your-life/, gitignored by default, so the scaffold is corpus-free by construction and forks without carrying anyone's data.
Wrote the operating contract as an agent-neutral AGENTS.md with one non-negotiable rule: the human decides and commits, the agent organizes, connects, surfaces, and challenges, but never silently authors the record. This is the same pattern that runs the finance engine (the math decides, the AI narrates) and the marathon coach's daily recommendation (a rules engine owns the call, the LLM explains it), drawn in a third domain.
Layered Claude-Code-native acceleration on top without forking the contract: nine persona subagents (Intake, Journalist, Coach, Skeptic, Therapist, Stoic, Future-Self, Biographer, Forensic-Auditor) that read their lens file at runtime and stay read-only over your-life/, five cadence slash commands (/capture, /daily, /weekly, /review, /coherence-check), and a SessionStart hook that nudges overdue reviews.
Shipped the front door as a static site on S3 + CloudFront + ACM, one landing page and a quick-start, with no third-party scripts and no client analytics.
Made adoption measurable without surveilling anyone: a counted-redirect Lambda behind /r/starter 302-redirects to the template's "Use this template" page and increments a day-bucketed counter with no PII, and a scheduled GitHub-poll Lambda reads forks, stars, and clones from a read-only token.
Gated the publish itself: before the repo went public, an allowlist check confirmed only structure files were tracked (never corpus), a secret scan and a relative-link-escape check ran clean, the internal extraction runbook was stripped, and a sensitive-content audit signed off. The repo was created private and flipped public only after the gate passed.
The Impact
- A public, MIT-licensed GitHub template (CaskeyCoding/specself-starter), template-enabled, forkable in one click and runnable with any capable agent
- One operating rule enforced by design: the agent reads and questions every file but authors none of the record, the same decide/narrate boundary that runs the finance and coaching engines
- Corpus-free by construction: the life content lives in a gitignored your-life/ tree, so the method is fully shareable while a user's content is never committed to the template, never published, and never seen by the author. What an agent sends to its model provider is the user's choice of agent, not the template's
- A live front door at specself.ai (static, no third-party scripts) with privacy-by-construction adoption tracking: a no-PII counted redirect verified end to end, plus a GitHub-native forks/stars/clones poll
- A Claude-Code-native bundle layered on the agent-neutral contract: nine persona subagents that read their lens at runtime and stay read-only, five cadence commands, and an overdue-review nudge
- Shown working, not asserted: the author runs it on his own life (foundation complete, principles and journal accumulating, weekly cadence held), shown only in aggregate so the proof never exposes the corpus
Evidence
Related
I Keep My Whole Life in Spec Files. My Agent Reads Them and Never Writes Them.
Spec-driven development, pointed at a life. Why my principles and goals live as markdown an AI agent reasons over, and the one rule that makes handing an agent your life safe: it can challenge the record, but it never writes it.
Composite What You Trust, Watch What You Don't: A Trust Boundary for Data With Money Attached
Every system that fuses signals into one consequential number has a fault line: the data you trust enough to composite into a grade versus the data you only trust enough to watch. How I drew that boundary in my personal finance engine, and how a test keeps it honest.
Spec-Driven Development and the Folder Architecture That Makes It Work
Why spec-driven development and structured folder architecture are the missing infrastructure for AI-assisted engineering: methodology, common mistakes, and where to start.
Lesson 9: Test Your Git Hooks, CI Checks, and Merge Rules
Run a monthly drill with a deliberate violation. Verify which controls reject it, report failures, and confirm cleanup. The drill attempts real merges, including an administrator override; use a disposable test repository and inspect the resulting evidence.
Lesson 8: Schedule Agent Runs and Configure Alerts
Run the task queue on a schedule. Separate urgent failures, requests for your decision, and routine logs. Detect missed runs, and understand why a watch on the same machine cannot detect that machine's complete failure.
Lesson 7: Automate Code Review, Merge Checks, and Deployment Verification
Add a separate reviewer, require automated checks before merging, and verify the deployed result before marking a task complete. Configure a runner, a GitHub workflow, and command restrictions, with explicit limits on what each can verify.