Type something to search...

The weekend I rebuilt what I already knew

The git history says I built it in one weekend. The git history is lying — and the squashed repo is the tell.

Warning

Viewing a draft version — this page is not published.
The weekend I rebuilt what I already knew

Kickoff

The git history says I built it in one weekend: fifty-eight files, ten thousand lines, landed in a single commit on the 2nd of February 2026. The git history is lying, and the lie is the interesting part.

~/Workspace/eyelock/claude-config-toolkit — 2 February 2026
git log —shortstat —date=short —format=‘%h %ad %s’

a496520 wip: distributable claude code config with artifact examples

52 files changed, 9533 insertions(+)
one weekend, one commit — because it wasn't new knowledge, it was a demo

The project was a distributable configuration toolkit for AI-assisted development: how a team writes, shares, and measures the artifacts that steer an agent — commands, skills, agents, rules, plans. None of it was new knowledge to me. There was a messier predecessor repo. The concepts had been proven across my January systems. I squashed all that history away on purpose and started a clean repo, because this thing had a different job than everything I’d built before. A clean commit history is, among other things, a form of theatre, and I mean that as a professional compliment.

It wasn’t for me. A session note from that weekend says it plainly: “preparing for presentation next week.” It was for a room of colleagues — and, two months later, for a much bigger one.

The Run

The backtrack

This was the first time I did something that became my standard move, and the through-line of the second half of this series: the backtrack. By February, my personal frontier was well past configuration files. But you cannot walk into a room of colleagues and open with your frontier. Try it and watch the room perform three stages of a very specific reaction: polite interest, quiet alarm, and then the particular silence of people mentally scheduling a meeting to discuss whether this is a “you” problem. What a team can adopt is one or two rungs below it — clean, self-explanatory, working. So I stepped back down the ladder and rebuilt what I already knew, properly, in a shape someone else could pick up. Proving something to yourself and promoting it to others are different engineering tasks. They produce different artifacts, and only one of them is remotely embarrassing to show a colleague.

What the rebuild taught the builder

The rebuild sharpened the ideas, too — writing for an audience always does. Two concepts got named that weekend that I still use constantly. Context dilution: every instruction you load into a model’s context competes with every other one, so an over-stuffed config makes the agent worse — my 200-file prompt library wasn’t just unwieldy, it was actively diluting itself, a fact it would have been nice to know eleven months earlier. And progressive disclosure, the antidote: load a minimum, teach the agent where to find more when it needs it.

The weekend’s best moment: I pointed a fresh Claude session at the toolkit and asked it to audit the system it would itself be configured by. Its verdict — “the system teaches itself correctly but doesn’t fully implement its own teachings” — remains the most concise code review I’ve ever received, and it was right, and it took roughly four seconds to write, which is its own kind of insult.

sessions/2026-02-01-forensic-analysis-report.md — a fresh Claude session audits the system

VERDICT: Architecturally sound with minor execution issues

The system teaches itself correctly but doesn’t fully implement its own teachings.
the most concise code review I've ever received. it was right.

Both ideas survived the trip to work. Two months later, progressive disclosure had a slide of its own in the AI Week introduction: around a hundred tokens of description at startup, the full skill only when it’s needed, and a practical ceiling of a few hundred lines per skill before it starts diluting itself. And the “starter kit” from this weekend’s Training Ground grew up into the week’s two on-ramps: one for people building their first skill, one for people packaging what they already had (Post 12).

The Debrief

This is the shared-configuration stage, and it opens, as these things do, with a forensic audit nobody asked for:

On The Training Ground

The Forensic Audit. Turn the model loose on your own agent configuration — the exact move that produced my favourite verdict of the year: “The system teaches itself correctly but doesn’t fully implement its own teachings.” Then measure how far your setup is from something a colleague could adopt.

Info

You’ll need: an agentic CLI and your accumulated configuration — CLAUDE.md files, skills, rules, hooks, whatever’s grown in ~/.claude or your repo’s config directory over the months.

Commission the audit5 min

Fresh session, no task loaded, pointed at your config directory:

Forensically audit this agent configuration as a system. Report:
1. Contradictions — places where two files disagree.
2. Rules stated but not mechanically enforced anywhere.
3. Teachings not implemented — things the config says to do that
   nothing actually does.
4. Dead weight — files nothing references.
5. The newcomer path: what someone would need to read, in order,
   to work the way this config intends.
Be specific. Quote file and line. Do not be polite.
Sit with the verdict15 min

Read it all. It will be uncomfortably specific — mine found rules I’d written twice with opposite meanings, and a beautifully documented workflow no hook actually triggered. Mark each finding: fix, delete, or actually fine (with a reason). The third category is allowed; unexamined config isn’t.

Derive the starter kit15 min

Now the backtrack move. Same session:

A colleague wants to work the way I do, starting Monday. They will not
read all of this. Derive the SMALLEST configuration that covers my top
three tasks: <name them>. Maximum three files. Write it to ./starter-kit/.

Watch what the agent keeps — that’s what’s load-bearing. Watch what it drops — that’s your frontier: real to you, invisible to a newcomer.

Test the kit cold15 min

Fresh session that can see only starter-kit/. Run one of the three tasks. Where it stumbles, the kit is missing something load-bearing — patch the kit, not the session, and re-run. Two rounds usually does it.

Measure the distance5 min

Count what didn’t make the kit: files, rules, concepts. That count is the distance between your frontier and Monday-adoptable — the exact gap this post is about. Keep the kit; it’s the thing you demo at work, while your full config stays your personal workshop.

Tip

What you just proved: proving something to yourself and packaging it for others are different engineering tasks with different artifacts. The audit shows your system the way a stranger meets it; the starter kit is the backtrack — one step down the ladder, built deliberately. When you champion a practice at work, budget for the demo version, not just the frontier one.

I should disclose that I have never once, in my adult life, cleaned a physical room by first inviting a stranger in to catalogue everything wrong with it. This would strike most people as an unreasonable way to tidy a room. Software is, apparently, the one domain where I will not only tolerate this but pay for the privilege, on a recurring basis, and call it a practice.