← the notebook

I keep building my own tools

Half my GitHub is just coursework. The other half exists because something didn't fit me and I built the version that did — and after a year of it, that half is most of what I actually do.

If you scroll through my GitHub it looks a bit random, and half of it is. A crypto rebalancer. A realtime chat. A small game in C++. Those were for studies — I built them because they were assignments, not because I needed them. The other half is different: skills for AI coding agents, a tool that auto-indexes library documentation so an agent can actually find it. Different years, different languages.

That second half has a plan, and it’s newer than it looks. About a year ago I started building things because I wanted something and it wasn’t there, or it was there and it didn’t fit me — starting with a very bad first version of Peak Health. For a long time I didn’t notice I was doing it. Now I can’t stop seeing it.

Take the thing I work on most right now. I liked Matt Pocock’s agent skills, but they were separate steps you had to invoke one by one. Then I tried HumanLayer and saw something better — the agent could keep moving on its own instead of waiting for me to call the next step. But the part that actually bothered me was the grilling. It was its own step: you invoked it, answered the questions, moved on. And after the session the best parts went loose — a sharp idea, an improvement worth keeping, and it never made it into the spec, the design, or the code. Good thinking, dropped on the floor.

I don’t think anything in life is a straight line. You should be able to come and go. So grilling shouldn’t be a step you invoke — it should happen anywhere, whenever there’s something worth pushing on. So I collapsed two dozen separate skills into one and called it materialize: it drives an idea all the way to shipped code, grills me at any point, carries the context across every phase, and picks how much process the work actually needs. Has it been life-changing? No. It’s been much better. Not perfect, just much better — and I’ll take that.

Notice what that actually is, though. I didn’t refuse other people’s tools. I took the quality I liked from Matt’s skills and the auto-progression I liked from HumanLayer, and I built the version that fit me. That’s usually how it goes — other people’s work is full of ideas worth stealing, I just reimplement them my way, incrementally, instead of adopting the whole thing wholesale.

It’s the same instinct behind Eat or Skip. Every nutrition app shows my dad a number he has to decode instead of telling him the human thing — is this food good or not. So instead of complaining about it forever, I’m building the app I wanted to hand him. Same with Peak Health: I tried the existing training apps, none of them fit, so I built my own.

I used to think this was a bad habit. Reinventing things, not-invented-here. But mostly I’ve stopped fighting it. The friction of “this doesn’t exist” or “this doesn’t fit me” is not noise. It’s the most useful signal I get. It’s the thing that tells me where a real problem is, and whether I care about it enough to spend my evenings on it. The projects I abandon are the ones where the annoyance wasn’t real. The ones I keep are the ones that bothered me enough.

So no, the GitHub isn’t one clean story. Half of it is coursework I’ve mostly forgotten. The other half is a list of things that annoyed me enough to fix — and that half is most of what I do now, honestly: find the thing that doesn’t fit, and build the version that does.