Here is what I built: a skill called session-state, designed to give Claude Code a running memory of the work we were doing together. Key decisions, dead ends, things tried and abandoned. The AI equivalent of notes scribbled on a whiteboard mid-meeting.

Here is what it added: nothing.

Here is what the weekend was worth anyway: quite a lot, actually. And crucially, it was just a weekend. A small, self-correcting loop. The kind that’s harder to maintain the faster you go.

Lately I have at times found myself annoyed at the Claude Code collaboration experience. It sometimes goes from this amazing feeling of flow to a disjointed chore of repetitions. What kept nagging at me across my Claude Code sessions was continuity. Or rather the lack of it.

The first flavour of this is post-compaction derailment. That slightly deflated feeling after a big /compact, when the shared context feels thinner and you find yourself re-explaining decisions you’d both already made.

The second is session exit anxiety. The low-grade dread of closing the terminal mid-work. Did it save enough? Will the next session be severed from this one entirely, a clueless innie who has no idea what their outie got up to all afternoon?

I raised both with Claude. And we did what a PM and an eager developer do when left unsupervised without user input or validation: we over-thought it.

The design was elegant, in theory. A skill that used hooks to build a running record as we worked, listening for the right events, writing notes at the right moments. We discussed it thoroughly. We iterated. We were very collaborative and very wrong.

The premise was flawed from the start. I’d assumed hooks would give Claude visibility on certain events in the session. They don’t, at least not in the way I’d imagined. Some hooks don’t surface what you’d expect them to surface. The information simply isn’t there. I’d built a motion sensor for a room with no motion.

I found this out by installing the prototype into a real project repo. It did nothing. Which is at least a clean failure mode.

After the third iteration of the specification, still over-engineered, still not reliably solving the actual problem, I asked Claude for a brutally honest analysis. It obliged. The conclusion was clear: “The problem is discipline, not lack of automation.” And then, with what I can only describe as well-earned smugness: “Sometimes the best code is the code you don’t write.”

I dropped the project at that point. Claude was right.

But here’s what the wrong path taught me.

Hooks are genuinely worth understanding if you’re going to build with Claude Code. Not the vague “hooks fire when things happen” mental model I’d been working from, but the actual behaviour: what fires when, and what information is actually available. I know that now. I had to break something to find it.

And /compact, which I’d been treating as a mild inconvenience and an occasional surprise, is doing something more interesting than I’d given it credit for. It’s not just compressing the conversation. It’s synthesising context, preserving what matters, handing a coherent model to the next session. When it’s working well, it’s a good handover note, not a lossy backup.

The problem wasn’t the tool. The problem was that I was letting sessions run too long before compacting, and then wondering why the context felt bloated and confused afterwards. A long sprawling session produces a long sprawling compact. Smaller sessions, compacted deliberately and often: the output is sharper, the next session starts cleaner.

I already knew this. That’s the bit that stings, slightly. I’d even heard it straight from the horse’s mouth. An Anthropic developer, at a Claude Code Curious meetup, saying exactly this out loud. The answer was in things I’d already read about: shorter loops, cleaner handovers, don’t let context drift. I just hadn’t applied it to the act of compacting itself. And yet I went home and designed something I thought would add to it, when all I needed was a reminder to be a bit more disciplined.

Mario Zechner wrote recently about what happens when you remove yourself from the loop entirely. My weekend was a much smaller version of the same trap. Three things I’ll carry forward, because Claude Code is powerful enough to go very wrong, very fast, if you point it in the wrong direction:

Research before you design. We built a solution before we understood the constraints. A mistake I’ve warned others about, forgotten myself the moment I started prompting. The lesson is the same whether you’re writing a spec, building a skill, or vibing some analysis work.

Know what you’re actually asking for. “Hooks do things when events happen” is not a working mental model. Read the documentation. Actually read it, before you start ideating, not after the third failed attempt.

The wrong path isn’t wasted if you pay attention. I came out of this weekend knowing things I didn’t know going in: about hooks, about /compact, about where my own process has gaps. That’s not a consolation prize. That’s the real output.

A weekend well spent on an answer I already had.