A Repo Called self

I have a private GitHub repo called self. I built it because I wanted to maintain my own personal memory and context, and I wanted to use a coding agent for normal chatbot use cases. Coding agents are great at reading files, writing documents, and working inside a repo, so I gave them a repo to work in: one that already had a lot of context about me built in.

To seed it, I did something a little strange. I interviewed myself for two hours and wrote it all down: my history, my family, my professional life, goals, aspirations, how I like to communicate, and how I want models to communicate with me. Then I put those notes in the repo and told my agents to read them first.

The structure

Three top-level directories:

• self/ is the stable reference material from that interview, plus everything I've added since. Profile, values, goals, health and training notes, technical preferences, how I make decisions. Agents read this first. It rarely changes.
• workspace/ is the active work area. Drafts, explorations, half-formed plans. Messy is fine here.
• output/ is finished documents. When something in workspace/ has been reviewed and is actually done, it moves here.

workspace/ and output/ are grouped by life area: projects, finances, career, learning, life.

The README is written as much for agents as for me. It has a literal "For Agents" section: read self/ first, check workspace/ for anything in progress, treat output/ as settled thinking. The whole workflow:

1. self/        read first
2. workspace/   create and iterate
3. output/      finalize

Everything is in git, so when an agent updates a document, the diff shows me exactly what changed.

Why the output folder matters

A chat transcript is a dead end. The good thinking in it evaporates when the session closes. A finished document in output/ is different: the next agent can read it, build on it, or push back on it.

Over time output/ has filled with things I never would have kept otherwise. Specs written before building an app, so the build starts from a document instead of a vibe. Retrospectives after: day-one notes on new tools, a post-mortem of an experiment where a coding agent nearly shipped something wrong, a retro on a project I shut down. Notes on papers I've worked through. A playbook for how I pair with LLMs on code.

The payoff shows up every time I start something new. When I ask an agent for advice on a project, it has read how my last three projects actually went. When it drafts something for me, it already knows how I want it structured. Decisions accumulate instead of getting made again from scratch.

Then it grew jobs

If agents can read and write this repo interactively, they can do it on a schedule too. Today a handful of scheduled agents run daily on Google Cloud Run Jobs. (They started as GitHub Actions, but GitHub's cron would fire up to two hours late. Cloud Scheduler fires within seconds.) The pattern is the same every time: at a fixed time, fetch some data, commit results back to the repo, email me a digest.

• A dev-log agent looks at yesterday's coding activity across all my repos every morning, writes daily logs back into self, and emails me what shipped, what's open, and which PRs are waiting on review.
• An analytics agent pulls PostHog data across my deployed apps and emails one cross-app digest: tables, a trend chart, geography.
• An appointment scanner watches a booking system for earlier slots than the one I currently hold and emails me when one shows up. No more refreshing a website by hand.

The infrastructure is boring on purpose. One container image, and each job clones the repo fresh at run time, so changing a job means editing a script and pushing. Secrets live in Secret Manager. If a job fails, I get an email about that too.

My favorite detail is that the jobs live in the same repo they act on. The infrastructure, the memory, and the outputs share one git history.

Where this goes

The specifics don't matter much. What matters is the shift: instead of treating LLMs as a chat box I visit, I maintain a place where they work. I review diffs and read morning emails. The agents do the rote reading, watching, and summarizing.

Every new capability models gain makes this repo more useful, because the context is already sitting there waiting.