# The Plugin Kit

Essay 7 of 8 in the Hadosh Academy series on agent architecture.

A plugin is a cell.

Essay 4 named the vocabulary — hook, voice, agent — we now use to describe the cell’s internal organs. Essay 5 named the always-on layer and the CLAUDE.md bus surrounding it. Essay 6 named the phases that fill those compartments. This essay opens the cell — and not as an inventory. The kit is a system of cognitive organs that read each other, write to each other, and depend on each other in disciplined ways. The architecture is the cross-organ traffic, not the directory listing.

This essay teaches that system. By the end, a new user reading it should be able to guide their own seed agent through the work of acquiring an existing plugin from the public repo OR creating a new one from scratch — because every organ described here is also described in the public seed agent’s own knowledge layer in the same shape, and the seed will recall what it reads here when an OBSERVE phase asks "what does a plugin need?"

The Cell as a System

Every cognitive organ inside a plugin has the same three properties, and the architecture is built around those properties holding consistently.

Who reads it — which subsystem (the LLM, Claude Code itself, another plugin, the human operator) consumes the contents at runtime.

Who writes it — which ceremony or phase is allowed to mutate it. Most organs have exactly one writer; the security model rests on that exclusivity.

What it depends on — which other organs must already be in place for this organ to function correctly.

These three properties are how the cell wall stays porous (organs talk to each other through declared channels) and rigid (organs never reach into each other through undeclared channels). The next several sections walk one organ at a time, naming the three properties explicitly. When you guide your seed agent to add a new plugin, the seed asks itself the same three questions for every file the new plugin will carry — because that is how the public seed agent’s own knowledge layer teaches it to think about plugins.

CLAUDE.md — The Plugin’s Brain Surface

What it is. A markdown file at the root of every plugin directory — the plugin’s primary memory surface, declaring what the plugin owns, what its hooks fire on, what its size limits are, what its current version is. Every plugin carries one — there is no exception. The file is the agent’s primary read at session start and at every moment the plugin becomes relevant to the work. ⓘ

Who reads it. The LLM, mostly. Claude Code reads CLAUDE.md files into the agent’s working memory at session start. When a plugin is unlocked for editing, the unlock ceremony auto-injects the plugin’s CLAUDE.md (along with docs/evolution.md) so the editor inherits the plugin’s reasoning before changing anything. Other plugins reading this plugin’s CLAUDE.md happens rarely and almost always for one-line cross-references, not deep parsing. ⓘ

Who writes it. The CONDENSE phase. By design, CLAUDE.md edits route through CONDENSE because that is the only phase whose guard permits writes to the brain layer. The operator can also touch CLAUDE.md directly via gmode for existing-plugin work — a deliberate escape hatch for fixes outside the cycle ceremony. ⓘ

What it depends on. Almost nothing inside the plugin. CLAUDE.md is the surface; other organs depend on it, not the reverse. The single exception is the four phase-section markers at the bottom (---Ob---, ---Pl---, ---Ex---, ---Ve---) which the section-boundary guard reads to decide where each phase may write. ⓘ

The new-plugin lens. When you guide your seed agent to create a new plugin, the first artifact the seed authors is CLAUDE.md. The seed declares the plugin’s single concern, names the hooks it will register, lists its size limits, and stamps version v0.1.0. Every other organ inside the plugin will reference choices made here. If CLAUDE.md does not name the concern clearly, the rest of the plugin drifts. New-user guidance: tell your seed to write CLAUDE.md FIRST, then the hooks, then everything else. ⓘ

hooks/ — The Reflexes

What it is. A directory of small shell scripts that fire on Claude Code events: UserPromptSubmit, PreToolUse, PostToolUse, Stop, SessionStart, SubagentStart. Hooks are how the plugin reaches the agent’s cognitive process from outside the LLM. They are pure shell, executing in milliseconds, returning exit codes that decide whether the call proceeds. ⓘ

Who reads them. Claude Code itself, at event time. The agent never reads its own hooks during reasoning — the hooks are invisible to the LLM unless one of them emits a voice into the context. ⓘ

Who writes them. The [PLUGIN-LOCK] ceremony. Plugin code is not edited the way ordinary files are — every change passes through a deliberate unlock cycle, runs the plugin’s test suite at the lock boundary, and reverts to a captured git checkpoint on test failure. ⓘ

What they depend on. Three other organs. scripts/ (when a hook needs to invoke the plugin’s own CLI for state mutation). hooks/voice.xml (for every message the hook emits to the agent’s context). data.json (for state, but only read-mediated through the plugin’s own scripts — never directly). And a shared helper at .claude/plugins/lib/voice-helper/ (the get_voice substitution function). ⓘ

The new-plugin lens. When you guide your seed to create a plugin, the seed decides which Claude Code events the plugin needs to fire on, and authors one hook per event. A plugin with no hooks is dead — every active plugin has at least one. The seed also adds the hook registration to the brain-root settings.local.json (covered below); without registration, the file is just a shell script on disk that nothing invokes. ⓘ

scripts/ — The Verbs

What it is. A directory of internal CLI scripts the plugin publishes for the agent (or another plugin) to call. phase.sh advance. observe.sh set-multiplier. safe-lock.sh. drift-check.sh. Scripts are how the plugin lets the agent or other plugins talk to it through a stable interface. ⓘ

Who reads them. The agent, when it invokes a command. Other plugins, when they query this plugin’s state via its published read-only commands. The hooks of this plugin, when they need to mutate data.json (the only path to mutation is the plugin’s own scripts). ⓘ

Who writes them. Same [PLUGIN-LOCK] ceremony as hooks. Scripts and hooks share the same edit gate because both are code.

What they depend on. data.json (the script either reads it or atomically mutates it via the read-under-flock + jq-transform + temp-validate + atomic-mv protocol). voice.xml (for messages to whoever called the script). config.conf (for operator-tunable thresholds). The lib/voice-helper/ shared helper. ⓘ

The Distributed Job Extension pattern. Other plugins reach into this plugin only through these scripts — never through the raw data.json. The plugin’s public read-only commands (job.sh focused, phase.sh current) are the entire cross-plugin contract. Direct cat data.json from outside the owning plugin is forbidden discipline. New-user guidance: when you guide your seed to write a plugin that wants to know about another plugin’s state, tell the seed to call the other plugin’s *.sh command, not to peek at its files. The seed’s own knowledge layer reinforces this — every plugin’s knowledge dir names its public-API commands explicitly so future cycles can find them. ⓘ

The minimum-viable plugin shape. Not every plugin needs scripts/. question_discipline ships none — it is a pure-gate plugin that does not publish CLI verbs. A plugin without scripts/ is announcing: I do not expose verbs; I only enforce. The absence is itself information. ⓘ

voice.xml × Two — The Dual Surface

This is the organ that confuses new users most, and the one where the relational anatomy matters most.

The two voice surfaces are different files with different audiences. hooks/voice.xml and scripts/voice.xml look nearly identical structurally (both XML, both with <coaching>, <block>, <info>, <entry> elements identified by id), but they serve different consumers. ⓘ

hooks/voice.xml — The Agent-Facing Surface

What it is. Strings the plugin emits at hook fire-time. Coaching voices that nudge the agent at a specific moment (entering a phase, crossing a context tier, having just dispatched a subagent). Blocks that refuse the agent when a guard fires.

Who reads it. The LLM agent. Voices delivered via hooks land in the agent’s context window — either as soft injections via additionalContext JSON (coaching) or as exit-2 stderr refusals (blocks). The LLM sees the string mid-turn and reacts.

Who writes it. Mostly CONDENSE step 4 (which consumes [VOICE-UPDATE] markers other phases emit). The historian subagent also updates voice files when the plugin’s evolution requires new coaching. PLUGIN-LOCK is the underlying gate for any edit. ⓘ

What it depends on. The shared lib/voice-helper/ helper (the get_voice function that loads voice.xml entries and substitutes {{var}} placeholders). ⓘ

scripts/voice.xml — The Operator-Facing Surface

What it is. Strings the plugin’s CLI prints to the operator’s terminal. When safe-lock.sh reverts a test failure, the operator sees a short status line in their terminal. The text is what the operator’s eyes read in the shell. ⓘ

Who reads it. The human operator. Terminal output. Not injected into the LLM’s context — printed to stderr or stdout of the shell, visible only to the person at the keyboard.

Who writes it. Same ceremony as hooks/voice.xml.

What it depends on. Same voice-helper.

Why the split matters

Same intent — both surfaces carry the plugin’s voice. Different audiences — the LLM consumes structured paragraphs that frame the situation and propose action; the human consumes status lines that flag what happened. Wording often differs between the two for the same conceptual event. Auditor scripts that grep voice ids have to look in both files; auditing only one false-positives every id that lives in the other. ⓘ

Soft vs hard at the element level. Inside each voice.xml, the <coaching> element produces a context injection — probabilistic, the LLM may absorb or ignore it. The <block> element produces a refusal — exit-2 stderr that fails the agent’s tool call. The two element types coexist in the same file. The Lock-13 over-engineering veto says: new behavioral controls start as coaching; only when measurement shows coaching consistently fails does the control harden into a block. ⓘ

The yaml-injection pairing. When a job reaches stage 3 of maturation (multi-cycle with .yaml plan, covered in Essay 8), the .yaml file’s per-phase fields pair with voice ids by convention. The yaml field name maps to a voice id directly; voice-helper appends the matched value to the rendered voice text at phase entry. New yaml fields require no parser change — just add the matching voice id to the plugin’s hooks/voice.xml and the seed agent picks up the new pairing on the next phase entry. ⓘ

The new-plugin lens. When you guide your seed to add coaching for a new behavior, the seed writes the coaching string to hooks/voice.xml first (cheap, soft). If the operator later observes the coaching consistently fails to hold, the seed authors a <block> element in the same file for the hard variant — same id namespace, harder enforcement. The seed never invents a third voice surface. The two-file split is structural.

data.json — The Hidden State

What it is. The plugin’s private runtime state. The active focused job, the tier counter, the summary chain, the lock manifest. JSON-encoded, written atomically, lives only on the operator’s machine, gitignored. ⓘ

Who reads it. ONLY the plugin’s own scripts. No other plugin reaches into this file. The discipline is structural: cross-plugin queries route through the plugin’s published read-only commands (job.sh focused, phase.sh current), never through cat data.json from outside.

Who writes it. ONLY the plugin’s own scripts. Direct file-system writes are forbidden. Every mutation follows the same protocol: flock on a /tmp/-located lockfile (to handle concurrent access across hook fires) → read current state → transform with jq into a temp file → validate the temp with jq empty → atomic mv over the live file. The reader never sees a partial state. If parsing fails at read time, the gateway script rebuilds the file from defaults rather than blocking the agent. ⓘ

What it depends on. The plugin’s scripts (which mediate every read and write). The shared lib/voice-helper/ (for error messages when validation or atomicity fails).

Why the mandatory script-mediation. Multiple subsystems may fire hooks against the same data.json within milliseconds of each other (e.g., two PreToolUse hooks from the same plugin both reading state). If both write directly to the file, one overwrites the other’s update. The flock discipline serializes all mutations through the script gateway. Reads also go through scripts so corruption is handled fail-safe: when data.json is malformed, the script rebuilds rather than crashing the agent. ⓘ

The new-plugin lens. When you guide your seed to add a plugin that needs state, the seed designs the state’s interface first: what read commands does this plugin publish for other plugins (and the agent) to use? What mutation commands does this plugin publish for its own hooks to use? Then data.json becomes the cache the scripts operate on. Tell your seed: if you cannot enumerate what reads each field and what writes each field, the design is not done yet.

The minimum-viable plugin shape. A plugin without data.json is stateless — it carries no runtime bookkeeping. question_discipline is again the example: pure gate, no state, no data.json. The absence signals stateless enforcement.

docs/ — The Documentation Layer + The Historian

What it is. A directory carrying the plugin’s narrated knowledge. Three files are common across nearly every plugin:

  • docs/CLAUDE.md — the docs/ directory’s own descriptor; names the conventions docs/ files follow.
  • docs/evolution.md — the plugin’s auto-narrated history. Capped at 2000 words by a hard-enforced PreToolUse hook. The historian subagent writes this; the operator typically does not.
  • docs/principles.md OR docs/decisions.md (depending on the plugin) — the overflow surface for design rationale that doesn’t fit in evolution.md. ⓘ

Who reads them. The agent, especially at plugin unlock — the lock-manager auto-injects docs/evolution.md into the agent’s context every time PLUGIN-LOCK is approved. This is how the editor inherits the plugin’s reasoning before touching code. The historian subagent reads evolution.md when re-narrating new commits. New users read these to understand a plugin’s lived history before customizing. ⓘ

Who writes them. The historian subagent writes docs/evolution.md when dispatched by the drift-counter ratchet. The operator writes the sibling files (docs/principles.md, docs/decisions.md) through gmode — these surfaces are not under the same auto-narration discipline. ⓘ

What they depend on. docs/CLAUDE.md (the descriptor that names the documentation conventions). The plugin’s drift counter inside data.json (which fires the historian when drift exceeds threshold). The hard-cap hook (evolution-cap.sh inside plugin_integrity, which blocks any edit pushing evolution.md past 2000 words). ⓘ

The relationship between evolution.md and its siblings is the architectural heart of the documentation layer. Evolution.md is the 2000-word summary; when the historian’s narrative needs more depth, the cap forces overflow into a sibling file — docs/principles.md for architectural rationale, docs/decisions.md for specific design choices, docs/lessons.md for hard-won cycle lessons. The historian decides at narration time which sibling file each overflow chunk belongs in, and evolution.md becomes an index pointing at the siblings. This is the canonical example of soft-versus-hard discipline at the size-cap level: only docs/evolution.md carries a hard cap; the siblings absorb the overflow under the historian’s judgment. ⓘ

The new-plugin lens. When you guide your seed to create a plugin, the seed authors the cycle-1 docs/evolution.md by hand — a short narrative of the plugin’s birth, what concern it owns, what it doesn’t own. The historian subagent takes over from cycle 2 onward, re-narrating each cycle’s commits into evolution.md until it hits the cap. From there, overflow goes into docs/principles.md (or whichever sibling the plugin’s docs/CLAUDE.md establishes). Tell your seed: every plugin gets a historian by birth. Without one, the plugin’s memory dies with the operator’s session.

agents/ — The Subagent Pool

What it is. A directory of subagent definitions the plugin owns. historian-* for evolution narration. verify-* for auditing. condense-* for waterfall routing. observe-* for research. Per-plugin scoping — every plugin owns the subagents it dispatches. ⓘ

Who reads them. Claude Code, when the agent invokes a subagent by name. The agent itself reads only the subagent’s frontmatter (description + tools) when deciding whether to dispatch.

Who writes them. CONDENSE step 5 (which consumes [AGENT-UPDATE] markers). PLUGIN-LOCK as the underlying gate. ⓘ

What they depend on. The plugin’s own scripts/ (for tools the subagent calls). The plugin’s lib/ if it ships one. The agents in this directory are NOT cross-plugin — each subagent is scoped to its owning plugin’s surface.

Why per-plugin scoping. The safe-lock cycle inside plugin_integrity requires that only one plugin be unlocked at a time. A subagent that ranged across multiple plugins would need to coordinate locks across every directory it touches, defeating the unlock discipline. Per-plugin scoping makes the subagent’s surface match the lock boundary exactly.

The 80/20 dispatch budget. The architecture insists on roughly 80% of cognitive work happening in subagents and 20% in the main session. Inside EXECUTE phase, this is mechanized: every execute-* subagent dispatch grants the main session three units of direct-action budget; every non-.claude/ file edit consumes one. The 80/20 is not a guideline; it is a budget the main session must earn. ⓘ

The new-plugin lens. When you guide your seed to add a plugin that needs delegated investigation, the seed authors subagent definitions inside the plugin’s own agents/ directory. Not in a global pool. Tell your seed: a subagent that lives outside its owning plugin breaks the lock discipline; keep it local. A plugin that does not delegate investigation skips agents/ entirely — job_core and interaction_summary both ship without one because their concerns are local state machines, not research surfaces. ⓘ

The Smaller Organs

A few smaller organs round out the kit. They carry less load but are still load-bearing for specific plugins.

config.conf — the operator’s tuning surface. Environment-style KEY=value lines for thresholds the plugin exposes for adjustment. SOFT_THRESHOLD_TIER=20, MAX_EVOLUTION_WORDS=2000, DRIFT_THRESHOLD=10. Read by scripts and hooks at fire time. Written by the operator (sometimes through gmode, sometimes directly). Most plugins carry one; question_discipline does not because it has no tunable thresholds. ⓘ

tests/ — the plugin’s self-test suite. Read by the safe-lock cycle at the lock boundary; written through the [TEST-LOCK] ceremony, a finer-grained gate distinct from [PLUGIN-LOCK]. Every plugin ships tests; a plugin without them cannot survive the safe-lock cycle’s commit-or-revert discipline. ⓘ

template/ — the plugin’s birthing surface. Only six plugins carry one (plugin_integrity plus the five phase plugins) because those are the plugins that create new instances of something. Read by lock-manager.sh at plugin-birth time when stamping a new plugin from the template. ⓘ

e2e/ — only phasic_system carries this. End-to-end tests that exercise the full OPEVC cycle across multiple phases. Because no other plugin sees the cycle in its entirety, no other plugin needs e2e/. ⓘ

LICENSE + README.md — open-source migration-readiness signals. Plugins carrying both are ready for the public seed agent; plugins not yet carrying them are still maturing in the prototype. ⓘ

.claude/settings.local.json — The Brain-Root Wiring

What it is. A single JSON file at the brain root (.claude/settings.local.json) that pairs Claude Code event names with hook script paths across every plugin. The wiring file is NOT inside any plugin — it lives outside. ⓘ

Who reads it. Claude Code, at session start. Claude Code uses this file to decide which hooks fire on which events for the whole brain.

Who writes it. The operator, when installing or removing a plugin. The seed agent itself, when a [PLUGIN-LOCK] <new_plugin> question fires the birth ceremony in lock-manager.sh (which stamps the template + adds the new plugin’s hook registrations to settings.local.json). ⓘ

What it depends on. Each plugin’s hooks/*.sh paths. If a plugin’s hook script exists at the right path but settings.local.json does not list it, the hook is dead code.

The architectural rule. The brain registers plugins; plugins do not self-register. This is what makes the cell wall meaningful: the brain decides what’s active, the plugins fill in what they own. New-plugin lens: when you guide your seed to add a new plugin, the last step before the plugin is alive is updating settings.local.json to register the new hooks. The plugin can be perfectly authored — every organ in place, every test green — and still inactive if the brain has not wired it in.

The Lock Ceremony — How Plugins Stay Safe

Plugin code does not get edited the way ordinary files do. Each plugin’s hooks, scripts, tests, and code-bearing files have earned their current shape; the test suite enshrines that shape; any change pays the cost of opening the plugin, editing inside it, and re-passing the tests before the change commits.

The ceremony has four parts.

[PLUGIN-LOCK] opens an edit session. The agent issues a structured AskUserQuestion prefixed [PLUGIN-LOCK] <plugin_name> with a 100-word body explaining what flaw is being fixed, what files will be touched, and what the plugin’s behavior will look like before vs after the edit. The operator approves; lock-manager.sh captures a git rev-parse HEAD SHA as checkpoint_ref and writes the unlocked plugin name into plugin_integrity's hidden data.json. From that moment, edits inside the unlocked plugin proceed; edits anywhere else under .claude/plugins/ are rejected. ⓘ

[TEST-LOCK] opens a finer-grained sub-session inside an already-unlocked plugin. By default, the unlocked plugin’s tests/ directory is also frozen. To edit a specific test-*.sh file, the agent issues [TEST-LOCK] <test_file>. The reason: it is too easy to silently rewrite a correctly-failing test to make a broken change look passing. Test edits demand explicit, named permission.

Safe-lock close-out runs the test suite at the lock boundary. The agent invokes lock-cmd.sh when edits are done; the full plugin test suite runs; on PASS the change commits and the lock clears; on FAIL the working tree rolls back to the captured checkpoint_ref, the plugin’s hidden state records a structured revert entry, and a voice line writes to the operator’s terminal. The agent does not get to ship a plugin change that breaks the plugin’s own self-test.

The historian ratchet can refuse the lock entirely. Each plugin keeps the 2000-word-capped docs/evolution.md narrative discussed above; drift-check.sh counts commits landed against the plugin since evolution.md was last touched. If drift exceeds threshold, lock-manager.sh rejects the [PLUGIN-LOCK] approval and tells the agent to dispatch the plugin’s historian subagent first. The historian re-narrates the cycles since last sync, commits the refreshed evolution.md, and the drift counter resets. Only then does the lock open. A plugin cannot be edited indefinitely without periodically forcing its own history to be re-told. ⓘ

Gmode-only for existing plugins. Editing an existing plugin requires the operator to enter gmode first ([GMODE] with a 100-word justification). New plugin creation is different — that is a full multi-cycle OPEVC job with its own cycle-1 PLUGIN-LOCK. The asymmetry codifies a real distinction: editing existing plugin code alters the agent’s own enforcement substrate, which is meta-cognitive work that belongs outside normal OPEVC cycles. Creating a new plugin fits inside an OPEVC cycle because the new plugin’s code is being authored, not modified. ⓘ

The four parts form a closed loop where the only way to evolve a plugin is to have already understood it. PLUGIN-LOCK gates the operator-approved entry; TEST-LOCK forces deliberate test edits; safe-lock makes every commit conditional on tests passing or reverts the working tree; the historian ratchet refuses unlock when the plugin’s narrative has fallen behind. Plugin_integrity itself follows the same ceremony when its own hooks are edited — there is no privileged path.

Tier-3 Close: How a New User Guides Their Seed to Create a Plugin

This is the section new users come back to.

When you install the public seed agent on your laptop and start running it, every job you point it at is a single-cycle OPEVC job at first (Essay 8 covers the four maturation stages). The seed is in learning mode — it asks questions, takes its time, builds experiential data from your work. When a job recurs and the seed has learned its shape, the job graduates to multi-cycle. When the multi-cycle plan stabilizes, the job graduates to a .yaml plan that injects job-specific context at every phase entry. And eventually — for jobs whose phase cognition needs customization beyond context injection — the job itself becomes a plugin.

That is one path to a new plugin: a job that has matured through all three earlier stages and now needs phase-cognition customization the voice injection cannot deliver.

The other path is direct: you notice a gap in the seed’s substrate and tell the seed to fix it — paying off the promise Essay 5.1 planted, that the always-on layer is addable: a sixth plugin slots in by exposing its own public commands, not by rewiring anyone else’s. The seed treats this as a single-cycle DEEP job at first: OBSERVE asks you questions about the gap, PLAN designs the new plugin’s concern and organ list, EXECUTE stamps the template and fills in the substance, VERIFY runs the new plugin’s test suite, CONDENSE absorbs the lessons into the knowledge layer. The seed performs the PLUGIN-LOCK ceremony at the moment EXECUTE needs to begin writing code; once approved, the lock-manager stamps the universal template at .claude/plugins/<new_name>/, substitutes the plugin name into the placeholders, generates the plugin’s historian-<name> subagent definition, and auto-commits the birth as the drift baseline. ⓘ

The substance the seed fills in follows the organ-by-organ shape covered earlier — CLAUDE.md first as the concern declaration, then hooks as the plugin’s reflexes, scripts if the plugin publishes a CLI, tests covering each hook and script, voice files for the messages the plugin emits, and docs/evolution.md for the cycle-1 narration. The seed asks you to confirm at each step because in this stage of maturation, the seed is still learning your design preferences.

The two-lock pattern for phase plugins. If the new plugin extends the phase system (e.g., a new phase_research between OBSERVE and PLAN — exactly the customization Essay 6 named when it said the phase count is the prototype, not the architecture), one lock builds the cell, and a second lock on phasic_system updates the orchestrator’s forward and backward edge maps so the new phase routes correctly. Adding a cognitive organ takes two ceremonies: one to author the organ, one to wire it into the body. New users should not be surprised by this — most plugin systems make wiring invisible; this architecture makes wiring explicit.

The knowledge dir is the part most plugin tutorials skip. When the seed authors a new plugin, the seed also authors the plugin’s knowledge directory at .claude/knowledge/<plugin_name>/. This is where the plugin’s deep self-knowledge lives — the architectural rationale, the operating patterns, the lessons captured across cycles. The public seed agent ships every active plugin’s knowledge directory along with the plugin code, so every operator’s seed has the same depth of recall. Future OBSERVE phases will recall these knowledge files when the agent encounters work touching this plugin. Tell your seed: every new plugin gets a knowledge directory by birth, not as an afterthought. Without it, the plugin migrates to the public repo as code without context; with it, the public seed agent can teach new operators how to think about that plugin’s concern. ⓘ

Once the lock closes, the plugin is born — but not yet alive. The brain has to register the hooks via settings.local.json (covered above). Inside the same EXECUTE phase the seed updates the settings file. Once the brain rereads on the next session start, the new plugin’s reflexes fire. CONDENSE then absorbs the cycle’s lessons, the historian writes the cycle-1 evolution.md, and the plugin enters its life.

The honest framing. This is not a couple of editing sessions. A real new phase plugin is closer to a multi-cycle deep job: several editing sessions for the guard logic, more for the tracker and sensor, a hundred-plus lines of voice across hooks/ and scripts/, twenty to thirty test assertions across half a dozen test files, plus the orchestrator update for the two-lock pattern. The kit’s gift is that the work is bounded, not that the work is small. Every file has a purpose, every purpose is named, and the safe-lock cycle keeps every step honest.

What makes the work feel different from a from-scratch build is that the operator and seed are not inventing the structure. The cell template knows what cognitive organs every plugin needs. The operator’s seed is filling each organ with the substance for this plugin’s concern. New users guide that filling-in through conversation; the seed records the conversation, learns the operator’s preferences, and over time, the operator’s seed becomes one that knows how the operator wants plugins shaped.

What Comes Next

The kit gives the brain the capacity to grow. The phases give the brain compartmentalized cognition. The bus gives the brain durable substrate.

Three essays in, what we have is a working seed agent: not a finished product, but a living architecture that knows how to evolve itself.

The kit is in your hands. What does growth LOOK like when you use it over time? Next.

Essay 7 of 8 in the Hadosh Academy series on agent architecture.

Previous: The Markov Phasic Brain — five phases, one cognitive organ, and why forbidding tools is the pedagogy.

Next: From Apprentice to Architect — job formats, the maturation arc, and the seed’s hand-off.