Side Project Empire, Part 2: The Automation Stack That Ships
Originally published on Medium. Read here free — no account needed.
You picked projects that compound. Now here’s how you run all of them without drowning.
You open a repo you haven’t touched in three weeks. Twenty minutes later you’re still scrolling your own code, trying to remember how it works and where you left off.
Now do that fifteen times, because that’s how many active projects you’re running.
This is the part of the side project empire nobody warns you about. In Part 1 I gave you the 7-trait filter for picking projects that compound instead of consuming you. You ran the rubric, you picked something that scored a 6 or 7, and you started. Good.
Then you started another one. And another. Picking was the easy part. Now you have to carry all of them, and the context-switching alone can bury you.
Here’s the reframe that saved me. Running 15 active projects, some of them spanning several repos each, is a systems problem, not a discipline problem. Discipline doesn’t scale past a few repos. A system does. 🛠️
The Enemy Is the Connective Tissue
When you run one project, you keep everything in your head. When you run fifteen, the thing that quietly kills you is the connective tissue, the repeated cross-repo chores that no single project justifies solving, but all of them together demand.
It’s the 20 minutes of re-orientation every time you reopen a cold repo. It’s the README that quietly went stale six commits ago. It’s the weekly status update you write from memory on Friday. It’s the pile of half-captured ideas you’ll never file. It’s re-solving a problem you already solved in another repo last month because you forgot you did.
None of these are hard, but that’s exactly why they’re dangerous. Each one is small enough to ignore and frequent enough to bleed you dry little by little.
Back in Part 1, trait number four was reusable surface area, the idea that the projects worth keeping share patterns, code, and learnings that transfer. The automation stack is that principle turned into infrastructure. One system, and every repo plugs into it. Build the connective tissue once, and all fifteen projects get it for free.
The Unlock: Write It Once, Run It Everywhere
Before the tools, the architecture, because it’s the whole reason the tools scale.
Everything I’m about to show you now ships as one thing, a full Claude Code plugin called Staksmith, public on GitHub. Install it once and the whole stack comes with it. Each automation is a skill, a folder of instructions Claude follows when I invoke it.
The version I ran a few months ago was a mess. Every project had its own copy of these commands sitting in the repo’s .claude/commands/ folder. Fix a bug in one, and the other fourteen copies stayed broken. Classic drift.
The fix was to stop copying and start packaging. As a plugin, Staksmith installs from a single source, so every project sees the same skills and a fix I make in one place is live everywhere at once. No hand-wiring per repo, and nothing drifts out of sync.
And because it’s just skills underneath, you don’t have to swallow the whole thing. Clone the repo, grab the one automation you want, and drop it straight into your own skills directory, either the global ~/.claude/skills/ so it follows you everywhere or a single project's .claude/skills/ when it only belongs there. Lift one, lift five, lift all of them.
That’s the shift that makes a portfolio-wide toolchain actually maintainable for one person. Without it, you’re running fifteen forks of a system, and forks rot.
The Stack: 5 Automations That Carry the Load
Here’s the connective tissue, automated. I’ve ordered these the way you hit them in a normal day.
For each one, I cover what it does, the chore it kills, and why you’d build your own.
1. Get Oriented Instantly
What it does: Two skills split this job. The Vault-to-Code Bridge reads my planning notes for a project and generates that repo’s CLAUDE.md and an architecture doc, complete with the decisions and trade-offs I'd written down in prose. It fuzzy-matches a vault project like BillScribe to its repo, so I don't wire anything up by hand. Then Handoff writes a short breadcrumb at the end of each work session, capturing what I just did, the current state, and the next move.
The chore it kills: The cold-repo re-orientation tax. The generated CLAUDE.md tells me the stack, the constraints, and how the thing is built, while the handoff doc tells me exactly where I stopped and what's next. Opening a repo I haven't touched in weeks costs me a two-minute read instead of an afternoon of archaeology.
Why you’d build one: A repo that explains itself the moment you open it is the single biggest cure for context-switching pain. This is the “vault-driven planning” half of my workflow, and it’s the reason I can jump between five projects in a day without paying the orientation tax five times.
2. Keep the Docs From Lying
What it does: Code-to-Docs Sync hunts for drift between the code and the docs. It compares the tech stack your README claims against what’s actually in package.json, checks that the build commands in CLAUDE.md still match your scripts, and flags docs that haven't moved in a month while the code churned. Then it proposes the fixes.
The chore it kills: Stale documentation, the kind that turns a helpful CLAUDE.md into an actively misleading one. I wire it into a post-merge git hook so it runs quietly after every merge instead of waiting for me to notice.
Why you’d build one: Docs that lie are worse than no docs, because you trust them and get burned. When you’re spread across a dozen repos, you will never keep them all current by hand. Something has to watch for you, so you catch the drift while it’s one line instead of one rewrite.
3. Let the Weekly Review Write Itself
What it does: Every Friday at 5pm, the Weekly Momentum Report scans all my repos for the week’s commits, pulls the tasks I closed out of my vault, and writes the whole thing into a weekly note. Highlights, a per-project breakdown, blockers, and a git changelog, assembled while I’m not looking.
The chore it kills: The Friday “what did I even do this week” scramble. I used to reconstruct my week from memory, which meant I forgot half of it. Now the report is waiting for me. On Sunday I skim it instead of writing it.
Why you’d build one: A weekly review is the highest-leverage habit in a multi-project life, and it’s also the first thing you drop when you’re busy. Automating the gathering means the habit survives your worst weeks. The judgment stays yours. The bookkeeping doesn’t have to.
4. Stop the Inbox From Becoming Guilt
What it does: A three-step pipeline runs nightly. Inbox Scan inventories everything I’ve captured, Inbox Classify reads each note and picks its PARA home with a confidence score, and Inbox Organize moves the confident ones. Anything ambiguous gets flagged for me rather than guessed at.
The chore it kills: The capture backlog. Every idea I dump during the day gets sorted overnight, so I wake up to a clean inbox instead of a growing pile of someday-notes.
Why you’d build one: An unsorted capture is a thought you’ll never find again. (I keep a manual Inbox skill too for hands-on sorting sessions. The nightly pipeline is what keeps the pile from ever forming.) The confidence score is the key design choice. Let the machine handle the obvious calls, and save your attention for the genuinely ambiguous ones.
5. Reuse What You Already Solved
What it does: The Skill Auto-Extractor mines my git history for patterns I’ve repeated across projects. When it spots the same sequence three or more times, it drafts a reusable skill from the commits, ready for me to review and promote.
The chore it kills: Re-solving solved problems. The third time you do the same setup by hand, you should be turning it into a tool. This notices the repetition you’re too busy to notice yourself.
Why you’d build one: This is the flywheel, the part of the stack that builds more of the stack. It’s trait number four from Part 1 made literal. It’s your reusable surface area, extracted automatically from the work you were already doing. Every project you ship quietly makes the next one faster to ship.
The Glue: A Few CLI Shortcuts
The skills do the heavy lifting, but a handful of thin shortcuts make them frictionless. I invoke any skill as a /command, so running the whole momentum report is one keystroke, not a script I have to remember. Standing up a new repo with the full stack is one plugin install, no per-project wiring. And the git hooks mean the docs check and the nightly sort just happen, no invocation at all.
None of this is fancy. That’s the point. The best automation is the kind you forget is running.
A Week in the System
Here’s what a normal week actually looks like with the stack carrying the connective tissue.
Friday, 5pm. The momentum report fires while I’m making dinner. By the time I sit back down, my week is documented.
Sunday. I skim the report, adjust next week’s priorities, and glance at whatever the inbox pipeline flagged as too ambiguous to auto-file. Fifteen minutes, tops.
Monday. I open a repo I haven’t touched since last Tuesday. Its CLAUDE.md, generated from my notes, tells me exactly where I stopped. No 20-minute reload. I'm writing code inside of two.
Wednesday, after a merge. The post-merge hook flags that my README still claims a library I swapped out. I approve the one-line fix and move on.
Across the whole week, I wrote real code and made real decisions. The re-orientation, the status update, the doc upkeep, the filing, all of it ran underneath me. That’s the difference between fifteen projects being a recipe for burnout and fifteen projects being a system that compounds.
What I’d Skip (and What Breaks)
I’d be selling you something if I pretended this stack is free. A few honest caveats.
Don’t build this on day one, or for one repo. The whole thing pays off at portfolio scale, once you’re juggling roughly five or more active repos. Below that, it’s over-engineering, and you’d be automating a problem you might not have yet. Build the projects first. Build the connective tissue when the switching starts to hurt.
Automation you don’t trust is worse than none. Early on, every skill ran in dry-run mode, showing me what it would do before it did it. Trust is earned, so my newer skills now ship with local eval harnesses (canned test fixtures, graders, and a pass gate that has to stay green before I change anything). The automation is tested like production, because it is production for my workflow. A skill that silently breaks is negative leverage.
The stack is maintenance too. These tools don’t run themselves forever. They’re software, and software rots. Packaging the stack as one plugin is what keeps that maintenance from multiplying by fifteen, but it never drops to zero.
The Setup for Part 3
So the stack carries the load, and you can finally run the empire without it running you.
Here’s the part that turns this from a productivity story into a money story. Look back at what the stack produces as byproducts: the skills you extracted, the architecture docs you generated, the patterns you named, the public repo itself. In Part 1, trait number seven was content generation, the idea that the right projects spin off assets while you build. This stack is an asset factory.
Part 3 is about turning those byproducts into income, without quitting your day job. The blog post to packaged product to Gumroad loop, run on a real cadence, with real numbers. The connective tissue you just automated is what frees up the hours to run it.
So here’s my question for you: what’s the one piece of connective tissue eating your weekends right now? The status update? The stale docs? The re-orientation tax? That’s the first thing to automate. Tell me what it is in the comments, and if you want a starting point, the whole stack is on GitHub to fork. 💡