Learn

/ Extracted, not designed

Insight · Origin

Extracted, not designed.

Most protocols are architected up front, then applied. Mine ran the other way. I built first, named the patterns second, and only saw the shape by reading my own commits back.

01

There was no protocol.

On the 12th of November I opened an empty folder and started building a workout tracker with Claude Code. No methodology. No CLAUDE.md worth the name, no decision log, no task files. Just me, an AI, and a React app I wanted to use at the gym on Monday.

For the first 75 commits there was nothing to extract, because nothing had recurred yet. I was changing my mind in public. The app had a backend, and then it didn't.

gym · the first week

$ git log --oneline --reverse | head
0cb62ef Initial commit
ad1f913 Initial gym app setup with backend and frontend
5f8dae7 Add workout app prototype screens
a2152d6 Add feedback and rating system to workout app
ee73d98 Simplify to frontend-only app with localStorage

That last line is the whole mood. Five days in, I tore out the backend and went frontend-only. You cannot design a protocol on top of that. There is no pattern yet, only a person working out what they are building. A protocol written here would have been a guess in the shape of a method.

02

The patterns showed up before the name.

Seventy-five commits in, on the 9th of December, one commit changed the shape of the work. Not a feature. A pile of markdown.

gym · the pivot

$ git show --stat d04437f
chore(docs): migrate to file-based autonomous workflow

CLAUDE.md          |  22 +-
CONTEXT_PROMPT.md  |  14 +-
DECISIONS.md       | 144 ++++++
PRFAQ.md           |  73 +++
PROGRESS.md        |  93 ++++
TODO.md            |  75 +++
WORKFLOW.md        | 125 +++++
7 files changed, 544 insertions(+), 2 deletions(-)

Five new files in one move. Decisions with their rationale. A progress log. A task list. The product FAQ I would later use to reject features. This is the day files-as-memory was born in this codebase.

But here is the part that matters. I did not think "I am building a protocol." I thought "I keep losing the thread between sessions, so let me put the state in files the AI reads first." It was a fix for the problem in front of me, not a design for a system. The behaviour arrived. The name did not.

A protocol you design is a hypothesis. A protocol you extract is a measurement.

03

Extraction is reading your own history back.

Six weeks later, on the 19th of January, the commit log says something different.

gym · the hinge

$ git log -1 --format='%ad  %s' --date=short 6c9eeae
2026-01-19  docs: align to duo Protocol v1

Align to. Not invent. Not design. By January the patterns I had reached for over and over, decisions recorded with their reasons, tasks named by what they unblock, scope modifiers for how much context to load, were already sitting in the history. I had not planned any of them. I had needed each one, reached for it, and moved on.

Extraction is the moment you read that back and notice the repetition. The git log was the dataset. The protocol was the thing that kept showing up in it. Naming it was not a creative act. It was a reading.

04

Extraction is compression.

A week after that, the 27th of January.

gym · the consolidation

$ git log -1 --format='%ad  %s' --date=short 2085988
2026-01-27  docs: v1.0 architecture consolidation — 20 ADRs → 5 pillars

I had written 20 architecture decisions, one at a time, each one solving the thing in front of me. Consolidating them into 5 was not throwing 15 away. It was finding the 5 shapes the 20 were all instances of.

That is what extraction is. Compression. You keep what recurred and you drop the scaffolding that held it up while it was forming. The protocol is the compressed form of the work, not a plan the work was poured into.

05

You re-extract. It is not one and done.

Extraction is not a single event. The evidence keeps coming, and sometimes it tells you that you extracted the wrong thing.

gym · the correction

$ git log -1 --format='%ad  %s' --date=short 8be71d6
2026-05-07  docs: delete ROLE_PROTOCOL.md — scar tissue describing unused workflow

At some point I had written 539 lines describing a workflow of ceremonies. Start rituals, make rituals, hygiene rituals. It read well. I was not doing any of it. The doc described the workflow I wished I had, not the one my commits showed.

Anti-pattern

Extracting aspiration instead of behaviour.

Writing down the method you wish you followed, rather than the one your history proves you follow. It feels like progress. It produces scar tissue, a document everyone has to maintain and nobody obeys.

Deleting it was extraction too. The evidence, the real sessions and the actual commits, said the ceremony was fiction, so it went. This is the same instinct as one of the protocol's own rules, generated beats maintained. If a doc can be rebuilt from the source, rebuild it from the source. Here the source was the history, and the history said less.

06

Build first. Read back. Extract.

So if you are building with AI and wondering when to write your protocol, here is the honest answer. Later than you think.

  • Build the real thing. You cannot compress a pattern you have not repeated. Ship enough that the patterns have somewhere to come from.
  • Read your own history back. The commits are the dataset. Ask what you reached for more than once.
  • Keep what recurred, drop the scaffolding. 20 decisions become 5 pillars. What survives the compression is the protocol.
  • Delete what you only aspired to. If the history does not show you doing it, it is scar tissue. Re-extract when the evidence changes.

The through-line

The gym was the proxy, not the point. The protocol is what was left after I compressed six months and 400+ commits down to the handful of patterns that would not stop showing up. I did not design it. I read it off the work. That is the whole method, and it is the same move underneath every essay here. Good structure is not drawn up front. It is recognised.