Chitragupta: My Personal Assistant Is a Git Repo
I wanted a Jarvis — email, calendar, travel, investments, FIRE tracking. I ended up building no app at all. A weekend's notes on why the assistant turned out to be a repository of instructions, a Drive folder of records, and a handful of calculators.
I've wanted a Jarvis since roughly every Iron Man movie. The wishlist was specific: triage my email, know my calendar, manage my repos, plan family trips, keep my investment ledger, and tell me — honestly — how far I am from financial independence.
I never once tried to build it. It always seemed too fancy — surely months of plumbing before anything would actually be functional — so it sat in the most procrastinated bucket I own: the post-retirement project list. Something to tinker with when I finally had time.
There's a nice irony in how that resolved. The project I deferred until retirement turned out to be the one that tracks how far away retirement is — and it took a weekend. The assistant has no application code at all. It is a git repository. And the thing I named it after tells you most of what you need to know about the design: Chitragupta, the record-keeper of Hindu mythology, who maintains the complete ledger of everyone's deeds. Not a genie. A bookkeeper.
The realization: the app already exists
Claude Code sessions can already read my Gmail, calendar, and Drive through connectors I'd authorized once, in a settings screen, with none of the OAuth ceremony. They can run shell commands. They clone whatever repo the session starts on — and they read that repo's CLAUDE.md and skill files before the first message.
That last part is the whole trick. A repo's CLAUDE.md is standing instructions: who you are, what you're allowed to do, where things live. Skills are markdown procedures the session can invoke. So the "app" is:
- A private repo as the brain. Operating rules, a persona, and six skills: a daily brief, repo management, travel planning, investment/FIRE tracking, spend tracking, and a monthly review. Start a session on this repo and Claude is Chitragupta. Start a session anywhere else and it isn't. That's the entire deployment story.
- A Google Drive folder as the database. Portfolio, goals, trip itineraries, a memory file, an expiry ledger for documents and insurance. Nothing personal ever enters git.
- Connectors as the hands. Gmail, Calendar, Drive, GitHub — already authorized, already scoped.
- Zero-dependency Node scripts as the arithmetic. More on this below, because it's the rule I'd defend most fiercely.
No server. No cron infrastructure. No framework. The repo is a few hundred lines of markdown and three small calculators.
The rule that matters: the model never does money math
The FIRE question — when can I stop working? — is a compounding problem: net worth, savings rate, withdrawal rate, inflation-adjusted goals, loan amortization. Exactly the kind of arithmetic a language model will do confidently and wrongly.
So the repo's rule number three reads: "Money math is never done in your head." There are three plain-Node calculators — fire-calc, loan-calc, goal-calc — no dependencies, no install step, deterministic output. Chitragupta's job is data plumbing and interpretation: fetch the JSON from Drive, run the script, explain the result. When I ask "what if I retire on a 4% withdrawal rate instead?", it doesn't estimate — it re-runs the calculator with a --set override and quotes the output.
This division of labor is, I think, the correct general shape for LLM + personal finance: the model handles language (parsing a mutual-fund screenshot, categorizing a bank alert, asking whether that ₹50,000 UPI transfer was a one-off), the script handles numbers. In two days of heavy use, every figure it has told me traces back to a command I could re-run myself.
What it actually did
Some moments from the first 48 hours that sold me:
It reconstructed two international trips from my inbox alone. I said "I have trips planned to Bhutan and Vietnam this year." It searched Gmail, found a 26-email negotiation with a Bhutanese tour operator — dates, hotels, a payment, the cancellation policy — plus flight confirmations, hotel bookings, and an airport-taxi receipt for Vietnam, and produced two complete itinerary files and calendar events with flight numbers. It also noticed the tour operator had missed their own ticketing deadline, which became the first item on my to-do list.
It caught a collision I would have hit in an airport. When I gave it my driving licence expiry for the documents ledger, it cross-checked against the trip files: the licence dies mid-vacation, in another country. Renewal is now scheduled for early December, before we fly. That check is no longer luck — it's written into the travel skill as a standing procedure.
It audited a month of spending from bank alerts. Every debit alert in my inbox, categorized against known SIP mandates and EMI, refunds matched against charges, one classification question asked ("who is this transfer to?") — and a comparison of actual lifestyle spend against the assumption my entire FIRE number rests on. That assumption turned out to be conservative, which is the good direction to be wrong in.
It priced my habits honestly. I mentioned I replace my car every ten years. It amortized that into annual expenses and told me what the habit permanently adds to my FIRE number. There's a conversion rate I now can't unknow: at a 3.33% withdrawal rate, every ₹1 lakh per year of recurring spend adds ₹30 lakh to the corpus you need.
The lesson I didn't expect: corrections compound
The most valuable behavior wasn't any single feature. It was this loop: every time I corrected it, the correction became permanent.
I told it my wife covers part of the household budget from her own income — now every spend report adds that estimate before comparing against the plan. It once created a calendar event a day off because of a timezone quirk in all-day events — the fix is a convention in its memory file, and it hasn't repeated the mistake. The first test session on my phone felt like talking to a generic chatbot — it narrated its plumbing, "let me search Drive for your files" — so we wrote a voice section into CLAUDE.md: lead with the answer, keep the machinery backstage, speak like a record-keeper. The next session opened with "Your net worth stands at…" and the persona clicked.
At the end of each day I say: "update the Chitragupta repo with everything we learned today." The assistant then commits its own lessons — new extraction rules for bank emails, the document-collision procedure, a gitignore bug it found in its own privacy guard. The repo accumulates scar tissue. A framework can't do this; a folder of markdown that the assistant itself maintains absolutely can.
What doesn't work yet
Honesty section. Scheduled automation is the big gap: connectors currently work only in interactive sessions, so my planned 8 AM auto-brief became an on-demand brief — I open a session with my morning tea and say "brief." The platform will presumably close this gap; the repo has a note waiting for that day. The Drive connector can create files but not edit them, so updates are replace-and-trash — a small daily tax of cleanup clicks. And email attachments are out of reach, so policy PDFs still require me to type one line or send a screenshot.
None of these are dealbreakers. They're design constraints, and the repo documents each one so no future session rediscovers them the hard way.
The thesis
The assistants that stick won't be the ones with the best demos. They'll be the ones that keep the best records. A chatbot answers your question and forgets you; a record-keeper gets the ledger a little more complete every single day — your goals funded and tracked, your deadlines clustered and watched, your corrections remembered.
The whole build costs nothing beyond the Claude subscription I already had, and its entire codebase is markdown plus three calculators. The genie was never the point. Chitragupta writes things down.