Claude Code Isn't Just for Engineers

There is a lot written about how engineers use Claude Code. It’s a far more versatile tool than that. I am an engineer at heart, and the highest-leverage thing it did for me had nothing to do with writing code. Over the last few months, I made Claude Code the runtime for my entire operating manual, and rebuilt my stack around it.

The forcing function was landing in my current role. I was suddenly responsible for a lot of moving parts. Multiple teams, 50+ people, spread across several geographies and timezones. People pinging me on Slack, sending email, catching me after a meeting with a thing I needed to remember. Things got dropped. The only thing keeping five surfaces in sync was my brain, which had other work to do. The playbook I’d built at Mixpanel assumed I could walk over to someone’s desk and read the room. The one from Pocus assumed the whole company fit in my head. Both stopped working within a few weeks. I realized quickly that none of what I had done in the past would work in this new world, so I needed to rethink my setup from first principles.

The Stack

I made a decision early on to go all in on Claude Code. Not just to use it but to live in it. One front door for everything. What to raise with a report in our next 1:1, I ask Claude. My weekly highlights, I ask Claude. What the last month actually looked like across the org, I ask Claude. Not an assistant I check in with now and then. The interface to my own job became a single conversation.

My stack at the time was scattered. Obsidian for notes. Remember the Milk for todos. Notion for 1:1 docs, one per report. Work and personal calendars, kept separate. Slack and Zoom for communication. But if Claude Code is the runtime, every other choice in the stack has to be rethought around it, starting with the most basic one: where does the state live? My answer is the least fashionable one available. Plain markdown, in a git repo. A file per person, covering reports, skip-levels, peers, and the people I report to. The org chart. A registry of the Slack channels and DMs that matter. Daily logs, timestamped and append-only. No SaaS tool anywhere in the loop. The whole thing is durable, greppable, private, and diffable.

It also kills a problem I could never solve in the old world. In Notion, my most sensitive material, 1:1 notes and things people told me in confidence, sat in a tool where a stray share could expose it to the wrong person. Here the repo is encrypted with git-crypt, the key lives in 1Password, and it only decrypts on my own devices. Nothing sensitive leaves the repo.

The Sync

Remote work has an underrated upside: nearly every interaction is capturable. I run Fireflies on everything (only if everyone in the room agrees), sensitive, trivial, high-stakes, routine. That’s the passive intake. The active intake is the most personal mechanic in the system. I talk to my repo by dropping items into a private Slack channel with exactly one member: me. A thought between meetings, a reminder, a voice note dictated through Wispr Flow while I’m walking, they all land there. Personal life goes into the same place as work, on purpose. I don’t want a system where work quietly outranks the rest of my life. The two hold each other in balance only if they live in the same store.

Then the engine turns all of it into state. The flagship is a skill I call /sync, and the first thing to understand is that it is not a chat reply. I kick it off and it works for twenty to thirty minutes. It pulls everything since the last run, Fireflies transcripts, the channels and DMs that matter, my saved items, the one-person inbox, and classifies as it goes. Cursors in a state.json keep it incremental, so each run reads what’s new rather than the entire world. This is a batch job, not a prompt returning a paragraph. Here’s the shape that makes it work. Every signal becomes a first-class insight, a structured object with a source, the entities it touches, an importance, and a set of proposed destinations. Routing is separated from materialization. Before a single file is written, the sync proposes the entire fan-out, every insight mapped to one or more destinations from a closed set: a person’s observation log, an item on a 1:1 agenda, a Linear todo, a decision record, a kudos, a follow-through check. I review the whole plan at once, correct what it got wrong, and only then does it write.

The guardrails matter as much as the engine. Every write is propose-and-confirm. Anything outward-facing is draft-never-send. And I deliberately disabled the agent’s persistent memory. The repo is canonical, and I don’t want a second, private copy of my world accumulating somewhere I can’t see, diff, or encrypt. The last thing each run does is propose edits to its own operating manual. The skill that processes my day ends by suggesting improvements to how it processes my day. It accretes rules from its own mistakes.

Loops

That engine runs on a twenty-to-thirty-minute clock. The things it tracks don’t resolve on that clock. They close over weeks. Engineers work in tight loops: write, verify, deploy. A manager’s loops are a different animal. They run over a longer horizon and refuse to stay inside any one tool. Someone flags an issue in a meeting. It needs a lap through legal and finance. It closes three weeks later in a Slack thread. Opened in a transcript, resolved in a channel, a month of latency in between, and no single tool that sees the whole thing end to end. This is exactly the shape that used to fall through the cracks, because the only thing spanning those tools was my memory. The skills that close these long loops give me my mind back. They hold the open end so I don’t have to.

But a skill can only close a loop if it knows what matters, and that was the part I had to teach it. I had to write down how I actually triage, which forced a lot of tacit judgment into the open. Proximity on the org chart works as a ranking function: a comment from a direct report weighs differently than the same comment two levels away. Substance matters more than the length of the meeting it came from. A third independent source elevates a pattern from noise to signal, so one mention of a retention risk is a data point while the same concern from a second and third direction is something to act on. And the cardinal rule: the system ranks for surfacing, never for filtering. It orders what I see. It is never allowed to decide I shouldn’t see something at all.

Writing all of this down would have been worth doing with no AI in the picture. We talk about infrastructure as code and prompts as production code. This is judgment as code, the tacit weighing a manager does by feel, written down plainly enough that something else can run it. The agent just gave me a reason to finally do it.

Skills

These skills are deeply personal. They work for me, and probably only for me, because they’re shaped around how I happen to think. I hate looking at todos in a UI, a pure quirk. And so the whole system bends to keep todos out of any interface and accessible via Claude. Your quirks are different, so your system should be too.

There’s a common instinct to build a sprawling library of skills, a catalog you’re proud of and never touch again. I’ve found the opposite works. A very small set, iterated on constantly, beats a wide library left to rot. Mine started trivially. The first version of this repo did one thing: it watched my Slack saved items for documents I needed to read. I built it because document-reading had become unmanageable and I needed one place that told me what actually required my eyes. Everything else grew from that seed, one revision at a time. Fewer skills, sharpened often, is the entire lesson.

As an example, one skill I lean on most is /prep. I type /prep and a name, and it hands me everything I need for a 1:1 with that person: the topics I’d flagged, the commitments still open, the things worth raising while they’re fresh. The signals that used to slip get captured, so the most important threads are in front of me without a Notion doc to maintain or a memory to trust.

I have one test for whether something earns a skill: would I do this the same way again next week? A one-off, however tedious, is cheaper to just do than to encode and maintain. And if I’d only do it once a month or a quarter, I treat it as a one-off too, because things move quickly enough that the skill would be stale by the time I reached for it again. The bar is lower than it sounds, because the same session where I notice the friction is the one where I build the skill to kill it.

Fin

None of this transfers wholesale, and it isn’t meant to. Don’t copy my repo. Copy the method: pick a runtime, give it a single canonical home for state, write your own judgment down as code, and keep the loop tight enough that you’re improving it every week.

I’ve shared how I do it, but I’m sure there are better ways. If you’re an engineering leader who has bent Claude into the shape of your own job, I’d like to hear how.

I had an open todo to write this post. Now that it’s written, I need to update my skill so it watches my blog, notices this went up, and closes the todo on its own. The system writing its own last line.