Building a Living Strategy Repo: Version-Controlling My Career Strategy

The problem

I love having a plan. I love taking my aims, my desires, my ideas, and structuring them in ways that I find easiest to follow through on.

AI's made it so much easier to have a new idea for a project, a life plan, a research topic I'm interested in discovering more on, and then having the ability to really drill into it.

The problem is - you generate a lot of disparate chats. Claude has projects, which makes it easier to collate these disparate chats into at least vaguely aligned groupings. The planning documents generated can exist on that project. Perfect. But they're read-only. The friction of trying to keep them all up to date (especially if you have enough separate but related aims) can cause them to become stale quickly.

Increase the volume enough, and things that are important to you can start falling through the cracks.

The idea

Recently, I was coming back to a career trajectory plan I'd been thinking through - I had some additional thoughts on how it could be extended.

I could not for the life of me find the details of it.

My overall planning document hadn't been updated to include the most recent ideas.

Turns out - the ideas, initial decisions, draft architecture specs were all living exclusively in chat history.

There's no version control (beyond asking for updated documents), no single source of truth, and no way to track what's changed or why without trawling through relevant conversations.

The biggest piece of friction in the process: I was using AI to plan my career future, but the AI can't remember what we planned.

The onus is on me to keep track, organise, and structure my thoughts and the conversations and artefacts from AI related to it.

Then a solution hit me, and I was surprised how long it took me to arrive at it - why do I not have a private repo to track all of this?

The process

I went through and audited ~10-15 conversations I'd had around different aspects and iterations of the plan, along with the ~6 project documents created so far.

Next step - categorise it all. I came up with six buckets; strategy, projects, content, infrastructure, research, and decisions.

What you might actually want to capture may vary drastically from me, but for my use case, these covered the broad strokes of what I care about and want to capture (the other bonus being, since this is a Git repo, I can expand it as needed when something new comes up).

Here's a shocker - as part of this, I found a decent chunk of work and project ideas related to the plan from conversations that weren't captured anywhere in the existing planning docs.

Oops.

At this point, the concept fully validated itself in my mind. The uncaptured ideas were some of the most interesting I'd come up with to date; full architecture specs for tools that would tie half a dozen separate projects into an interconnected system — sitting in chat history, completely undocumented.

Another interesting aspect of this process was identifying what had been well-documented (earlier aspects of the plan and related projects) vs. what existed only in ephemeral chats (all the more recent ideation and projects - did the compounding interest of the initial plan leading to new ideas make it too exciting to keep ideating through them, rather than doing something boring like updating the docs? Doesn't sound like a dev thing).

The repo

With the data organised in a sane way, next step was creating the repo itself.

My thinking was;

• a private GitHub repo with structured directories
• each idea gets enough context to pick up cold
• decisions logged with rationale (so future-me doesn't need to re-derive them)
• living documents that update as projects progress

For the visual people out there, here's an abridged structure tree of what came out from the above thinking;

strategy/
├── README.md # Index, current state, quick links
├── CHANGELOG.md # Decision log with dates and rationale
│
├── strategy/
│   ├── overview.md # Core philosophy, positioning, identity
│   ├── timeline.md # The phased plan
│   └── principles.md # Compound interest, energy planning, shipping constraints
│
├── projects/
│   └── ...
│
├── content/
│   ├── principles.md # Content creation principles
│   └── drafts/ # Actual draft content
│       └── ...
│
├── learning/
│   ├── ...
│
├── reference/
│   ├── infrastructure.md # Deployment details, costs, accounts
│   └── research/
│       └── k-shaped-divergence.md # Research compilation
│
└── personal/
    ├── operating-manual.md # Energy management, habits, rhythms
    └── decisions-log.md # All decisions with rationale and dates

The why (and why it matters beyond my situation)

I personally know of a few people using AI in a similar way to me, and I know in the abstract that many many more are doing the same thing out there. AI being used not just as a coding buddy, but as a tool to chart out ambitious plans, iterate and ideate through them, refine them and update them as living plans as they go.

The problem with using it as a strategic thinking partner is that since it's chat-based, all of the context created is throwaway by default. You're the bottleneck - your understanding, your ability to structure the information and retain it, and link it together when necessary.

The fix turned out to be simpler than I'd expected. So why not create your own personal RAG repo?

As Claude itself put it, the gap between "we discussed this" and "this is documented" grows silently.

Well said, and well worth avoiding.

What it enables

So there you go.

A boring but useful, meta use case for AI integration.

It's not the most exciting thing I've worked on, but since creating it yesterday, it's already beginning to repay the time investment.

The aspect of it I'm really excited about is how it ties into and enables some future plans I have - exploring RAG beyond business domain use cases. Why can't I set up a RAG system for my own life?

I just created the first step of it.