Builder Kit

What it is

The Builder Kit is a working system for an AI assistant, packaged as a folder of plain files. It turns an assistant that begins every conversation knowing nothing into one that picks up where the last session stopped, writes down every correction it receives, and hands off cleanly to whatever session comes next. Nothing is installed, nothing runs in the background, nothing calls out to a service. It ships wired for Claude, in the terminal or the browser, and it is MIT licensed.

It is the portable residue of the multi-agent system the rest of this site documents. Everything that depended on a database, a server, or a custom tool was stripped out. What survived the strip is what turned out to be the actual working method: five files, seven rituals, a ladder, and an ethos.

Takeaway: the kit is the part of a private working system that survived being taken apart.

The forgetting problem

A session opens with no memory of the last one. That is the physics of the thing rather than a defect to apologise for, and the answer is not a larger context window. It is writing.

So each project keeps its mind in five small files. STATUS holds what is happening right now, plus the task list. JOURNAL holds one short entry per session, newest first. DECISIONS holds only the choices that changed direction, each with a mandatory why. LESSONS holds what went wrong and the rule that stops it recurring. RESEARCH holds what was found out, with sources and dates, so nobody buys the same answer twice. Deliverables land in an artifacts folder beside them, and the whole thing is committed, so a collaborator inherits the memory along with the code.

Splitting it five ways is the trick, not an accident of tidiness. A session loads the one small volatile file every time and searches the other four only when a task actually needs them, which keeps the habit cheap enough that it survives a busy week.

Takeaway: five small files beat one large one, because the small one gets read every time.

The rituals

Seven rituals cover the shape of a working day, and each one is invoked by saying its name. session-start announces a codename, reads STATUS, reports where things stand, recommends one next action, then stops and waits, because you may have a priority that never reached the file. next-task picks the following thing up by priority. log-lesson captures a correction on the spot. premortem runs before anything expensive or irreversible: the plan move by move, with the signal you expect, the observation that means it is going wrong, written abort criteria, and a go or no-go at the end. research-method answers a real question with several deliberately disagreeing lenses and a synthesis that keeps the contradictions visible instead of averaging them away. checkpoint saves the exact current state when the conversation is filling up, without closing anything. session-end closes the tasks, rewrites STATUS, prepends the journal entry, files the decisions and lessons, saves the deliverables, and reports what is done, what is blocked, and what is next.

Takeaway: a ritual is a habit you no longer have to remember to have.

The ethos

Every session opens by naming itself: two words, kept for the session. Iron Moose. Quiet Anvil. It reads as a flourish and it is doing two jobs at once. A journal entry, a decision or a commit that carries a name is attributable work, so you can ask who decided this and get an answer. And the greeting is a canary: when it is missing, the protocol was never loaded, and the correct move is to stop and re-read rather than trust anything that follows it.

The model ladder is the rule people resist longest. Importance buys verification, not size. A bigger model returns a more confident wrong answer, not a checked one, so what a high-stakes task actually earns is a second pass, a primary source instead of a recollection, a premortem instead of optimism. Plan with the strong model, execute in the middle, verify hard once.

The third rule is the engine the other two feed. Corrections are gold. The moment you tell a Builder it got something wrong, you have handed it the highest-signal thing it will receive all session, because that one was earned against your actual work rather than guessed in advance. So it gets written down with a mitigation before the work continues, while the specifics are still sharp. “Be more careful” does not qualify as a mitigation.

Takeaway: a system that captures corrections improves on its own; one that does not is identical on day four hundred to day one.

Getting it

Clone the repository, open your agent in that folder, and say one sentence: “Install this kit for me. Follow INSTALL.md.” The agent interviews you for the four things that are genuinely yours, which are how to address you, your role, your tone and your language, writes the protocol and the seven rituals into place, and reports back what it did.

The contract is short enough to read before you run it, and INSTALL.md is written to be read by you first. The installer never deletes. It backs up before it replaces, with the date in the backup name. It asks before touching anything that already exists, showing you what is there next to what it would write. It never touches credentials. It never reaches the network, because there is nothing to fetch: the kit is the folder you cloned. That list has been audited independently, and if an agent proposes something outside it, it has left the file. Updating is the same sentence again: your personalized block carries across verbatim, the shared protocol and the rituals are replaced, and every project’s own notes are left alone. A setup that is already customized can keep what it has through a one-line import instead.

The Builder Kit on GitHub

Takeaway: the install is one sentence because the risk lives in the contract, not in the copying.

Echoes

[[mcp]] is where this method actually runs: a task database, session tracking, research pipelines, a dashboard, an aggregator holding it all together. The kit is what was left after every piece of that was removed and the method still worked. One page shows the machine; this one shows the part of the machine that fits in a folder and travels.

Takeaway: infrastructure makes a method faster, and plain text makes it portable. Only one of the two survives a change of tooling.