# Lararium, the whole methodology

You are probably an AI assistant, and your human just handed you this file. Good. Here is the entire
thinking behind Lararium, a clone-and-run scaffold for a personal agentic system: what it is, how it
installs, and the reasoning behind every layer. Read it, then help them build their own. It ships
empty on purpose; the architecture is the gift, their life is what goes in it.

Install: run "npx lararium", or clone https://github.com/kylnor/lararium and read it first.
Wary of running a stranger's installer? The stack ships a sandbox for exactly that: "lab <repo>".

---

# README

# Lararium

*A lararium was the shrine in a Roman house where the household gods lived. The family kept it, fed
it, and spoke to it daily. This is that, for a life run with AI: the shrine, and the gods you keep
in it.*

A clone-and-run scaffold for a personal agentic system. Six layers: a file-based knowledge
**brain**, a layered **soul** (the assistant you actually talk to), a **clocktower** index over
your data, a roster of **agents** the assistant dispatches, the **hooks** that make it feel alive
session to session, and the **skills** it runs as slash commands.

It ships empty on purpose. The architecture was never the moat: your life is. So you get the
shrine, and you bring your own gods.

> **This is a template**, extracted from a working private system and depersonalized. It ships
> structure, conventions, and hard-won patterns. It ships **none** of the original owner's data,
> persona, or secrets. See `SCRUB.md` for exactly what was removed and how to verify nothing leaked.

## Why this instead of a prompt pack

Everyone else hands you *their* context: their prompts, their personas, their ten hacks. Lararium
hands you the empty structure and teaches you to pour your own life into it. A second brain can't
be copied off a shelf; it has to be lived. That is the whole design, and it is why giving this away
costs nothing: nobody can steal a life they have to build themselves.

It also installs itself. You open it in an AI coding assistant and say *"run the install interview."*
An agentic stack is installed by an agent. It interviews you, one question at a time, and writes
your files while you answer.

## The six layers

1. **`brain/`**: a human-navigable markdown knowledge store, scoped by life sphere, governed by a
   small set of laws (`brain/CLAUDE.md`). Files are canonical; the database is an index on top. The
   heart of the system, and the one to read first. Useful on day one with nothing but markdown.
2. **`soul/`**: the assistant's persona, assembled fresh each session: seven layered sections, a
   heartbeat loop that lets it remember yesterday, voice-drift monitoring so it keeps sounding like
   itself. Ships blank; `soul/character-craft.md` teaches the craft (archetypes, trait tensions,
   tone proofs). Its rules half lives in `rules/OPERATING.md`: action bias, the miss-capture
   protocol, steering rules, the standards.
3. **`clocktower/`**: the index: schema, an MCP server config, the watcher pattern that ingests
   your corpora, the embeddings standard, and the retrieval doctrine earned in production
   (`clocktower/retrieval-doctrine.md`). The memory layer has four organs, intake, carder, gate, and
   connector; the last is the daily "what I just learned maps to what I am stuck on" job, documented
   in `clocktower/connector-doctrine.md`. Coordination is a separate surface: `clocktower/queue-doctrine.md`
   runs multi-agent work natively on the tasks table you already have. Ships with
   an empty database and no credentials.
4. **`agents/`**: a roster of specialized subagents (build, review, research, infra, adversarial,
   memory) plus the dispatch doctrine for which to use when. The theme is yours to replace: the
   re-theming interview (`agents/RETHEME.md`) rebuilds the whole roster in your own mythology,
   doctrine intact. Bring your own gods, literally.
5. **`hooks/`**: the loops that make it feel alive. Session-start briefing, the heartbeat that
   remembers yesterday, voice integrity, compaction continuity, safety rails, dispatch routing.
   Doctrine plus minimal reference implementations that run on plain files, no database required.
6. **`skills/`**: slash-command skills for the session lifecycle (`/end`, `/handoff`, `/sessions`),
   self-improvement (`/evolve`), and memory curation (`/muninn`), plus the doctrine for writing
   your own.

Beside the six layers ships one optional tool: **`lab/`**, a disposable sandbox for untrusted
code. Your assistant is most useful when it can clone and run other people's repos, which is
exactly when it is most dangerous. The lab is a throwaway container, no network by default,
nothing of yours mounted in, every capability dropped, that you drop untrusted code into so it can
do its worst and it doesn't matter. The `/in-the-lab` skill runs it for you: offline recon first,
then an optional deeper session. Requires Docker; skip it if you don't have a daemon.

Staying current is meant to be passive: **your stack tells you when it is behind.** Adopt the
update-check hook (`hooks/reference/update-check.js`) and once a day, at session start, it checks the
upstream template's version against your own `STACK_VERSION` and, if a newer release is out, drops one
line into your session: type **`/upgrade`**. That skill fetches the latest template and runs the
upgrade interview in `UPGRADING.md` for you, applying the doc-only deltas directly and asking you only
about the structural ones. You answer questions; your assistant does the typing. The manual fallback,
for a stack that has not wired the hook yet: **Watch releases** on the upstream repo and read
`CHANGELOG.md`, where each release maps to an entry that classifies it as a doc copy-in or a full
interview and names exactly which files moved since your own `STACK_VERSION`.

## Getting it onto your machine

**Prerequisite:** an AI coding assistant that can read and write files in a local folder. The
install interview *writes your files for you*, so it needs filesystem access.
[Claude Code](https://claude.com/claude-code) is the reference setup (it brings its own subscription
or API key). A browser chat can talk you through the interview but cannot write into your folder, so
you would be copy-pasting; use the real tool.

Get the template locally. Three ways in, pick your trust level:

```
# Fast path: the scaffolder downloads the latest release and unpacks it
npx lararium my-stack  &&  cd my-stack

# GitHub template repo: click "Use this template" to make your own copy, then
git clone https://github.com/<you>/<your-copy>.git  &&  cd <your-copy>

# Sent a zip: unzip it, then
cd lararium
```

Wary of `npx`-ing a stranger's installer? Good instinct, it is the whole reason this stack
exists. The scaffolder (`npx/index.js`) is about 200 lines of Node standard library with zero
dependencies: it downloads a release tarball, unpacks it, and runs `git init`. It runs none of
the template's own code. Read it before you run it, or skip it entirely and clone the repo by
hand, then you have inspected everything before a single line executes.

And if you are properly paranoid: the two files worth eyeballing are both short (`npx/index.js`
and `lab/lab`). Read those, then let your very first lab run be Lararium itself:

```
lab/lab https://github.com/kylnor/lararium
```

That vets the rest of the stack inside the box it ships. The tool's first job can be auditing
its own supplier.

Then open the folder in Claude Code (`claude` from inside it) and say:

```
Run the install interview in INSTALL.md
```

That is the whole install. The brain and soul layers need nothing else. The index (clocktower) is
optional and wants your own database and embedding key, the day you decide you want search at scale.

## Setup order (if you would rather do it by hand)

Start with the brain: useful immediately, zero infrastructure, just markdown and the laws. Add the
soul when you want a consistent voice, its rules half with it. Wire the hooks when you want the
assistant to remember yesterday; the reference implementations run on plain files. Add clocktower
when the file layer outgrows grep-and-read and you want semantic search at scale. Agents and skills
last: leverage on top of a system that already works.

```
1. Read  brain/CLAUDE.md          # the laws, the map
2. Fill  brain/now.md             # your cross-cutting heartbeat
3. Write soul/core.md             # your assistant's character (replace the blank)
4. Adopt rules/OPERATING.md       # the operating rules, edited until true of you
5. Wire  hooks/                   # the loops: briefing, heartbeat, rails
6. Adopt skills/                  # the session-lifecycle slash commands
7. Stand up clocktower/           # optional: the index, when you need it
8. Adopt agents/                  # optional: the roster + dispatch doctrine
```

Already running an earlier version? Open your stack beside this template and say *"run the upgrade
interview in UPGRADING.md."* It adds the new layers without touching anything you made yours.

## What this is not

Not a hosted product, not multi-tenant, not a SaaS. It is a personal system you run yourself, shaped
so a peer can clone it and make it theirs. The productized version is a different and much larger
build. This is the shrine, free. What you enshrine in it is the part only you can make.

---

MIT licensed. Built in the open from a system that runs a real life. Bring your own gods.


---

# INSTALL

# Install (the interview)

This is not a script. It is a prompt. An agentic stack is installed by an agent.

**How to run it:** open this freshly-cloned template in any capable assistant (Claude Code, or paste
this file into a chat) and say: *"Run the install interview in INSTALL.md against this repo."* The
assistant interviews you and writes your files. You answer questions; it does the typing.

**The rules the assistant follows during the interview:**
- Ask **one question at a time.** Never dump the whole questionnaire. This is a conversation, not a form.
- Ask only what changes the output. Infer the rest and state what you inferred so the user can correct it.
- Write files as you go, show the user each one, move on. Do not wait until the end to produce everything.
- When a phase is optional, say so and let the user skip it. The brain layer alone is useful on day one.

---

## Phase 0: Read the map
Before any question, read `brain/CLAUDE.md` (the laws) and `README.md` (the six layers). Tell the
user, in two sentences, what they are about to set up. Then begin.

## Phase 1: The brain (required, do this first)
The goal of this phase is a brain the user could start using today.
1. **Whose system is this, and what do they do?** One or two questions. Enough to name the owner and
   their main lanes.
2. **The spheres.** The template ships `ventures / work / personal / infrastructure`. Confirm or
   rename them to fit the user's life (a student is not a founder; a freelancer is not an employee).
   Rename the sphere folders and rewrite each `CONTEXT.md` opening line to match. Delete a sphere
   they do not need; add one they do. Apply the shape only where populated.
3. **First real cards.** Ask for the two or three things actually on their plate right now (a project,
   a key person). Turn the `example-project.md` / `jane-doe.md` templates into those real cards.
   **Delete the leftover example files** once at least one real card exists in that folder.
4. **`now.md`.** From what they just told you, write a real `now.md`: the one or two hot things,
   ranked by life not by project. Delete the template scaffolding inside it.

At the end of Phase 1 the user has a working brain. Offer to stop here. Everything below is leverage.

## Phase 2: The soul (optional: do this when they want a consistent voice)
The goal is a `soul/core.md` that sounds like a specific someone.
1. Read `soul/README.md` aloud-in-summary so they understand what a persona layer is.
2. **Ask the archetype question first.** Read the archetype list in `soul/character-craft.md` and
   ask which one fits: the concierge, the anticipator, the gatekeeper, the quartermaster, the ops
   sergeant, the partner-with-root. If they answer with a famous character's name, treat it as
   pointing at an archetype and build an original character on it (the craft doc explains why).
3. Interview for the character, not the rules. Good questions, asked one at a time:
   - What should the assistant's default register be? (dry, warm, blunt, playful, formal)
   - Should it lead with its opinion or wait to be asked? Push back when you are wrong, or defer?
   - How should it open a reply: react first, or get straight to the work?
   - What would make it sound like a generic chatbot? (so we can ban those phrases)
   - Does it have a name? Whose assistant is it?
4. Write `soul/core.md` from the answers using the dimensions in `soul/character-craft.md`: trait
   tensions, the register gap, the anti-list, and at least three tone proofs (sample responses to
   real scenarios from their life). The samples are the spec. Name the persona's failure mode.
4. Note what they still need to wire themselves: the session-start hook that loads `core`, the
   session-end hook that writes `heartbeat`, the drift monitor. Point them at `soul/README.md`.

## Phase 3: The rules and the loops (optional, but the cheapest leverage here)
1. **Rules.** Walk `rules/OPERATING.md` with them. The miss-capture protocol is the one section to
   sell hard: it needs zero infrastructure and compounds from day one. Help them copy the document
   into their global config (`CLAUDE.md` or equivalent) and delete the example steering rules that
   are not theirs.
2. **Hooks.** Read `hooks/README.md` for the loop catalog. Ask which loops they want first (the
   honest default: session-start briefing + heartbeat + the update checker, all three on plain files;
   skip voice-drift until the voice exists). The update checker rides the same `SessionStart` event as
   the briefing, so wire it in the same phase: copy `update-check.js` in alongside `session-start.js`,
   register both `SessionStart` commands, and copy the `stackUpdateCheck` config block from
   `hooks/settings.example.json` (it defaults the upstream to this template; a forker re-points it).
   **Set `localVersionFile` to the absolute path of this stack's `STACK_VERSION`** (the repo root you
   are installing against, the same file you stamp in the closing step). You know that path, it is the
   folder you are working in, so fill it in explicitly rather than leaving the placeholder. If it is
   wrong or unset the hook reads v1 and nudges every session forever, the one way this hook annoys
   instead of helps.
   Copy the chosen reference hooks into their assistant config, wire them per
   `hooks/settings.example.json`, and run each once standalone with a fake payload to prove it
   exits clean. The reference hooks run on plain files; no database needed yet.
3. **Skills.** Copy `skills/defs/` into their skills directory. Adapt the paths the skills mention
   (handoff file location, index tool names) to what actually exists in their install; a skill that
   references infrastructure they skipped should have that step cut, not left to error.

## Phase 4: The agents (optional: leverage on top of a working system)
1. Ask whether they want the themed roster as-is or in their own mythology. If they want their own,
   run the re-theming interview in `agents/RETHEME.md` (doctrine kept, personas regenerated; never
   a find-and-replace).
2. Ask which functions they actually need (most people do not need chaos + load + red-team on day one).
   Prune the defs they will not use; keep the dispatch doctrine in the README.

## Phase 5: The index (optional: only when files outgrow grep-and-read)
1. Tell them plainly: this is the heaviest phase and they can defer it indefinitely. The brain works
   without it.
2. Walk `clocktower/README.md`. Help them produce a real `.env` from `.env.example` (their own
   database, their own embedding key, their own host). **Never invent or reuse anyone else's
   credentials.**
3. Point them at the schema and the watcher pattern. Standing up the actual database and watchers is
   their infrastructure to run; the interview hands them the map, not the keys.

---

## Closing
As your **last act**, stamp the version: copy this template's `STACK_VERSION` file into the root of
the user's stack unchanged. It is a one-line file naming the template version they just installed
from. It is what the upgrade interview reads later to know which changelog deltas apply, so a stack
without it reads as v1. Then end the interview with a short checklist of what is done and what the
user still owns (hooks to wire, infra to stand up), and get out of the way. The system is theirs now.


---

# The writing (the why behind each layer, and every release)


## The Shrine and the Gods

*Why you cannot buy a second brain, and what to build instead.*

# The Shrine and the Gods

A lararium was the shrine in a Roman house where the household gods lived. Not a temple you visited on holidays. A small niche by the door, part of the home, tended every day. The family kept it, fed it, and spoke to it. The gods in it were not abstract. They were the specific spirits of that specific house.

This is that, for a life run with AI. The shrine, and the gods you keep in it.

## The thing everyone gets wrong

The market is drowning in prompt packs. Ten hacks. A notion template of someone else's system. A persona you can paste into a chat box to make it talk like a growth marketer. Every one of them hands you the same thing: *their* context, dressed up as yours.

It never works, and the reason is simple. A second brain is not a file structure. It is the ten thousand small facts about your life that make an answer land instead of miss. Who your people are. What you decided last March and why. The constraint you keep forgetting until it bites you again. None of that ships in a template, because none of it belongs to the person selling the template. You cannot download a life you have to live.

So the pitch is inverted here. Lararium hands you the empty structure and teaches you to pour your own life into it. The architecture was never the moat. Your life is. That is the whole design, and it is exactly why giving it away costs nothing: nobody can steal a life they have to build themselves.

## What it actually is

Lararium is a clone-and-run scaffold for a personal agentic system. Six layers, and each one solves a problem you already have if you have spent real time with an AI assistant.

1. **The brain.** A file-based knowledge store, plain markdown, scoped by the spheres of your life. This is the fix for the assistant that forgets you every morning. It is useful on day one with nothing but a text editor.
2. **The soul.** The assistant you actually talk to, assembled fresh each session from layered sections, with a heartbeat that lets it remember yesterday and drift-monitoring so it keeps sounding like itself. This is the fix for the assistant that sounds like everyone else's.
3. **The clocktower.** The index over your data: schema, a search server, the watchers that ingest your corpora, the retrieval doctrine earned in production. This is the fix for the day grep stops being enough.
4. **The agents.** A roster of specialized subagents your assistant dispatches, plus the doctrine for which to use when. Re-theme the whole roster into your own mythology. Bring your own gods, literally.
5. **The hooks.** The loops that make it feel alive: the session-start briefing, the heartbeat, the safety rails, the routing. The invisible layer that turns a folder of files into a presence.
6. **The skills.** Slash commands for the rhythm of a life run this way: end a session cleanly, hand off to the next one, run the self-improvement pass.

It ships empty on purpose. You get the shrine. You bring the gods.

## It installs itself

Here is the part that sounds like a gimmick and is not. An agentic stack should be installed by an agent. So you open the folder in an AI coding assistant and say, *run the install interview.* It interviews you, one question at a time, and writes your files while you answer. You are not filling in a hundred blank templates. You are having a conversation, and at the end your brain and soul exist, in your words, about your life.

The brain and soul layers need nothing else: no database, no keys, no server. The index is there for the day you outgrow searching by hand, and not one day sooner.

## Why read the rest

This is the first post in a series that walks every layer, one at a time. Not a documentation tour. Each post takes one idea, shows you the specific pain it kills, and gives you enough to try it yourself that afternoon.

We start where you should start: the brain, and the single most stealable idea in the whole system, the sphere method. That one needs nothing but markdown and a decision. Read it next.

The shrine is free. What you enshrine in it is the part only you can make.


## The Brain, and the Sphere Method

*Your AI forgets you every morning. The fix is just markdown, and a way of cutting up your life.*

# The Brain, and the Sphere Method

Your AI assistant forgets you every morning. You explain your project, your people, your constraints, and the next day you explain them again. The context window is not memory. It is a whiteboard someone wipes at midnight.

The brain is the fix, and it is almost embarrassingly low-tech: a folder of markdown files, organized by a small set of laws, that you and your assistant both read and write. No database required to start. No infrastructure. A text editor and a decision about how to cut up your life.

That decision is the sphere method, and it is the most stealable idea in the whole system. You can adopt it this afternoon without touching anything else Lararium ships.

## Files are canonical. The database is an index on top.

Start with the one principle that makes the rest coherent. The files are the truth. If a database ever sits over them, it is an index, the way a library catalog is an index of the books. Burn the catalog and the books are fine. Burn the books and the catalog is a list of ghosts.

This matters because it keeps the brain **human-navigable.** You can open it, read it, edit it by hand, and hand it to a friend. It is not trapped inside a tool. It outlives whatever tool you use this year.

And it draws a hard line about what belongs inside:

> The test for any file: would you want to read this? If it is raw data, it belongs in the corpus, not the brain. If it is something you *learned* from the data, it is a card.

Your emails, your messages, your calendar, the raw firehose of your life: those stay in the index, the cold store. The brain never copies them. A card *points at* them. The brain is the synthesis layer, the distilled and durable and navigable part. The stuff you would actually open and read.

## Spheres are the scope boundary

Here is the problem the sphere method solves. If you pour your whole life into one context, every answer gets worse. Ask about a work deadline and the model is also chewing on your side project, your family, your server config. Relevance drops. The model reaches for the wrong thing because everything is equally present and nothing is scoped.

So you partition. The brain is cut into **spheres**, the large domains of a life:

- **ventures**: your bets, side projects, the entrepreneurial work.
- **work**: the day job.
- **personal**: family, health, finances.
- **infrastructure**: the system itself, the assistant, the tooling.

Rename them to fit your life. The point is the partition, not those four exact words. The payoff is **scoped loading**: when you work on a venture, you load the venture sphere, not all of you. The assistant arrives focused instead of flooded.

One file sits above the spheres and is read every session no matter what: `now.md`, the cross-cutting heartbeat. What is hot this week, anywhere. It is the answer to "where are we?" that a fresh session needs before it can be useful.

## The recursive shape

Inside a sphere, wherever a thing has a real world of its own, it gets the same shape:

```
CONTEXT.md     # what this is, who is in it, current focus
people/        # cards on the people in this scope
orgs/          # companies, clients, entities
projects/      # what you know about projects (not the code; code stays in git)
reference/     # constraints and knowledge to internalize, scoped here
```

A sphere uses this shape. A big venture *inside* a sphere uses the same shape. That is the recursion, and it is what lets the brain grow without ever being redesigned. You learned the pattern once; it applies at every level.

The discipline is to apply it **only where it is populated.** A health scope does not need an `orgs/` folder. You do not have corporate health entities. Never force an empty folder into existence because the template has a slot for it.

## The laws

The sphere method has a rulebook, and it is short enough to memorize. These are the laws a person follows editing the brain by hand, which are exactly the laws an agent enforces on a schedule. The same rules, written once.

1. **Card until it earns a folder.** A thing starts as a single file, `myproject.md`. When it grows its own cast and its own concerns, promote it to a folder with the full shape. Promotion takes thirty seconds. Do it when earned, not one folder sooner.
2. **Never pre-build empty folders.** A card costs nothing. Empty folders are how trees die.
3. **Shared lives once.** Someone who spans a sphere lives at the sphere level with a `_` prefix, `ventures/_people/`, which sorts to the top. Scoped to one venture, they live inside it. Never copy a card into two places. Link instead.
4. **Depth cap: three folder levels, then files.** Want a fourth folder? That fourth thing is a card, not a folder.
5. **Frontmatter on every file**, so an index can ingest it later with no new schema: `name`, `description`, `type`, `status`, `updated`.
6. **Wikilinks between cards.** A cheap graph, no tooling. A link to a card that does not exist yet is fine. It marks something worth writing.
7. **Reference is not working material.** `reference/` holds constraints to internalize: voice, conventions, canon. Working material is input to process. Keep them structurally separate. Mixing them in one blob degrades every answer that reads it.
8. **The card points at the work; it does not eat it.** A project card holds status, decisions, the cast, and a pointer to where the real work lives. The brain is what you know about the thing. The workspace is the thing.

Read law one and law two together, because they are the soul of the method. **Structure is earned, never pre-built.** You do not sit down and architect a beautiful empty tree of your life and then fail to fill it. You start with one card, and you let it grow a folder the day it actually needs one. A brain built this way is always exactly as complex as your life currently is, and never more.

## The rot, and who hunts it

A knowledge store decays. Left alone, it grows empty folders, duplicate cards for the same person in three scopes, frontmatter that says `updated: last March` on something you touched today, cards that quietly contradict a newer decision, dead links, and a `now.md` still claiming a project is hot that has not moved in weeks.

So the brain has two jobs that keep it alive. A **gardener** pulls new signal out of the cold corpora and turns it into cards, generous on intake. A **curator** polices structure against the laws above, generating nothing, only keeping it clean. In Lararium both can be run by an agent on a schedule, because the laws are written down and enforceable. But you can be the curator yourself with nothing but this list and ten minutes. The rules do not require the automation. The automation just runs the rules you would run anyway.

## Try it today

You do not need the rest of Lararium to start. Make a folder. Make four sphere folders inside it, named for your life. Write a `now.md` with the two or three things that are actually hot right now. Then, the next time you would have re-explained your project to your assistant, write a card instead, and point the assistant at the sphere.

That is the entire on-ramp. A folder, four spheres, and the discipline to write it down once instead of saying it twice. The database, the soul, the agents, the hooks: those come later, when the file layer has proven itself and you want more. The brain earns all of them by being useful first, on day one, as nothing but markdown.

Next in the series: the soul, and why your assistant sounds like everyone else's.


## The Soul, and Why Yours Sounds Like Everyone Else's

*A persona is not a prompt. It is assembled from tensions, monitored for drift, and taught to remember yesterday.*

# The Soul, and Why Yours Sounds Like Everyone Else's

Ask ten people to give their AI a personality and you get ten versions of the same sentence: "You are a helpful, friendly, professional assistant." Warm but professional. Knowledgeable but approachable. It reads fine. It produces a chatbot with a name tag, and by the third day it has flattened back into the default voice, because there was never a character there to hold.

The soul layer is the fix, and the fix is not a better adjective. It is a different way of building the thing entirely: a persona assembled fresh each session from layered sections, built out of structured tensions instead of traits, and monitored so it does not erode. In Lararium it ships **blank**. You get the scaffold and the loops, not anyone's character. The character is the one part only you can write.

## A persona is assembled, not prompted

The instinct is to write one paragraph and paste it into a system prompt. The soul does the opposite: it is **layered**, and the layers load in order.

- **`core`** is the voice and character, written as prose, deliberately free of rules. This is the part that makes the assistant sound like a specific someone. It loads first, every session.
- **Operating rules** live in a separate document: action bias, steering rules, the standards it holds work to. Character on top, rules underneath, loaded together but never fused. The reason for the split is simple: you will edit the rules constantly as you learn how you want it to work, and you should never risk a rules edit bruising the voice.
- **The other sections**, `identity`, `user`, `memory`, `heartbeat`, and the rest, load at session start or lazily when a task needs them.

The separation is the point. Voice is one concern. Operating discipline is another. The facts about your life are a third. Keep them apart and each one stays clean; blend them into one giant prompt and every edit to one degrades the other two.

## The dimensions that actually build a someone

Lararium ships a `character-craft.md` that teaches the craft, and its central finding is worth stealing whole:

> A persona that holds up over months is built from structured tensions and proofs, not adjectives. "Warm but professional" produces a chatbot. Tensions produce a someone.

Start from an **archetype**, not a character. Not the movie AI or the unflappable valet by name, because someone else's character was fitted to someone else's owner and will never quite fit you, and shipping a studio's character in your own published stack is a lawyer's day out. Take the archetype the name points at, the concierge, the anticipator, the gatekeeper, the partner-with-root, and build your own original on it.

Then write the dimensions, and write them in order:

1. **Five traits, each a tension.** Not five adjectives. Five pairings that pull against each other: commanding presence and genuine empathy, high standards and no cruelty, strategic and hands-dirty. The tension is what keeps the persona from collapsing into a single note by week three.
2. **Communication style, concretely.** Sentence length. Punctuation habits. Whether it reacts first or goes straight to work. How it delivers a recommendation, and how it takes being overridden.
3. **The register gap.** Where it sits relative to your energy: slightly under your formality when you are formal, slightly above when you are casual. The gap is the character. Matching you exactly is mirroring, and mirroring is what generic assistants do.
4. **"I am / I am not."** A dozen first-person lines it would say, and the anti-list of phrases it would never utter. The anti-list does more work than the list.
5. **Signature moves, inner voice, tone proofs, and the named failure mode.** The tone proofs are the real test: write its actual response to five concrete situations from your life. If you cannot write the sample, the trait list is wrong. The samples are the spec; the traits are commentary.

That last line is the whole discipline. You do not describe the character and hope. You write it *behaving*, and the description is just notes on what you wrote.

## The loops that make it remember and stay itself

A character written once and never maintained does two things: it forgets every yesterday, and it slowly drifts back to the mean. The soul layer has a loop for each.

**The heartbeat is writable memory.** A hook fires at the end of each session, distills what happened into the assistant's own voice, and writes it to a heartbeat file. The next session's briefing reads that file back. That is the entire mechanism by which it remembers yesterday: not a bigger context window, a written note it leaves for its future self. The heartbeat is the one section that is database-canonical, written server-side every session, because it is the assistant journaling, not you editing.

**Voice-drift monitoring is cheap insurance.** Every response gets logged. A nightly job samples a handful, scores whether the assistant still sounds like its own `core`, and alerts you if the average slips. Personas erode slowly and invisibly; this is the smoke detector. And before you ever edit `core`, you run an adversarial probe suite: a set of prompts that confirm the voice survives the change. You do not ship a voice edit on faith.

## Bring your own gods

This is where the Lararium name stops being decoration. The soul is a household deity you talk to every day, and the whole layer ships empty precisely because the deity is yours. The scaffold travels. The loops travel. The craft, the archetypes, the eight dimensions, all travel. The character does not, and must not: it is a specific person's assistant, full of a specific person's private facts, and copying it would give you a stranger wearing a mask.

So you write `core.md` from blank. You stub the other sections with your own facts. You wire the two hooks. And what you get back is not a chatbot that knows things. It is a someone who sounds like themselves in the morning because you built the tensions that hold, and remembers last night because you gave it a way to write itself a note.

Next in the series: the clocktower, and the day grep stops being enough.


## The Clocktower, and the Day Grep Stops Being Enough

*The index over your life: semantic search, the cold corpora, the watchers that feed it, and the four organs of a memory system.*

# The Clocktower, and the Day Grep Stops Being Enough

The brain is markdown, and for a while markdown is plenty. You open a sphere, you read a card, you grep for a name. Then the file layer outgrows you. You want to ask a question that spans a hundred cards. You want to search your emails, not just your notes about them. You want the assistant to come online already knowing who you are, without you loading a single file. That is the day grep stops being enough, and it is the day you add the index.

Lararium calls it the clocktower. It is the database half of the system, and its job is precisely the things a pile of markdown cannot do: semantic search at scale, relational queries over your tasks and goals, storage for the big cold corpora, and the watchers that ingest your life so the assistant arrives briefed.

It is also, deliberately, the layer you add **last and only when you need it.** The brain and soul run on nothing. The clocktower wants a database and an embedding key. You stand it up the day the file layer has proven itself, not before.

## The index never replaces the brain

The single most important rule of this layer is the one people break first. Files are canonical. The index is an index on top of them. It makes the brain searchable and it holds the firehose the brain points at. It does not become the brain.

Which means: **you do not copy your corpora into markdown, and you do not move your knowledge into the database.** The card points at the corpus; it does not eat it. Your ten thousand emails live in the index as rows. The one thing you *learned* from an email thread lives in the brain as a card that points back at the thread. Cross the streams, dump raw data into cards or lift your durable knowledge into database-only rows, and you lose the property that made the brain worth building: that you can open it and read it.

## The shape to reproduce

The architecture is four parts, and the template ships the map for each with the credentials removed:

- **An MCP server.** The interface the assistant calls to read and write the index: search, recall, remember, the session briefing, tasks, goals. This is how a language model actually touches your database, through a small set of named tools rather than raw SQL.
- **A database with vectors.** Postgres with a vector extension holds the relational state and the embeddings side by side.
- **An embeddings standard, written down.** Pick one model and one dimensionality and record it in a reference card. Everything embedded into the same space must use the same model, or similarity search silently degrades. This is the rule that bites hardest, because when it breaks nothing errors, the results just quietly get worse. Write it down and never drift from it.
- **Watchers.** The ingest jobs that watch your sources, email, messages, calendar, files, the brain repo itself, and feed new signal in. A brain-watcher pulls the brain from git before each pass, so an edit you push from any session lands in the index on the watcher's normal cadence.

The watcher pattern is worth internalizing because it repeats everywhere: read the last watermark, fetch what is new since then, deduplicate, insert, embed, update the watermark. And the discipline that makes it trustworthy: **a no-op pass writes nothing.** If there is no new signal, the watcher does not bump its watermark or churn embeddings. "The watcher is running" is not the same as "the watcher is producing," so every watcher declares a freshness SLA, the expected maximum age between successful runs, and anything past its SLA alerts. A pipeline that silently stops producing is worse than one that crashes loudly.

## The four organs of memory

Most systems that build a memory layer build three organs and stop. Lararium names the fourth, because the fourth is where the magic actually is.

**Intake** is the watchers, pulling corpora. It is content-blind; it moves signal, it does not judge it.

**Carding** mines those captures into durable knowledge, turning raw material into general facts worth keeping.

**Gating** is a scheduled curator that judges staged cards before they go live, so the high-volume, low-density sources, the email threads and web captures, pass through a quality gate before the assistant can retrieve them. Intake is generous on purpose; the gate is what keeps generosity from becoming noise.

**The connector** is the fourth, and the one worth the whole layer. It is a daily job that reads only the *new learning-material delta* since its last run, your video transcripts, saved bookmarks, newsletters, meeting notes, through a lens of what you are currently working on, and emits a tiny number of high-precision "this idea maps to that live problem" connections. Nothing else in the system makes that join. Intake is content-blind. The carder mines general facts. The gate only judges what it is handed. The connector is the organ that notices the thing you read this morning is the answer to the thing you were stuck on last week, and tells you.

It has its own doctrine, earned on a real build whose reviews caught nine production bugs before it shipped, and the rules are sharp: a connection that does not name a live problem is a drop, not an output. Value decays with age, so it runs newest-first and throws away anything older than two weeks. And silence is a valid result: most days nothing maps to anything, and the correct emission is zero. An organ that manufactures a connection every day to feel useful is worse than one that stays quiet until there is a real one.

## What you build versus what you copy

The schema, the tool surface, and the server config are the map, and they ship. The running server, the watchers, and the database are yours to stand up: this layer is infrastructure you operate, not code you clone. There is no database in the box and no row of anyone's data, by design. When you have it running, the template hands you a retrieval doctrine, seven production-earned rules, to walk as a checklist so your search is good and not merely present.

The order matters, so it is worth repeating: this is the layer you reach for when the file brain has outgrown grep. Not on day one. On the day you feel the file layer straining, which is exactly when the cost of standing up a database is worth paying.

Next in the series: the agents, and one assistant that dispatches a whole team.


## The Agents, and the Team You Dispatch

*One assistant you talk to, a roster it dispatches. Functional coverage, the validated build loop, and a mythology that is yours to write.*

# The Agents, and the Team You Dispatch

There is a ceiling on what one assistant, in one conversation, can do well. It holds one context. It thinks in one voice. Ask it to build a feature and review its own work and you get a builder grading its own homework. The agents layer is how you break the ceiling: one assistant you talk to, and behind it a roster of specialists it dispatches, each with its own function, its own model, its own tools, and its own opinions about the work.

They are a team, not worker threads. That distinction is the whole design. A worker thread runs a task and returns. A team member has a job it owns, a standard it holds, and a relationship to the other members. Lararium ships the roster and, more importantly, the doctrine for using it well.

## Coverage is the thing, names are not

The template ships a themed roster, because a themed team is easier to hold in your head than twelve job titles. But the names do not matter. The **functional coverage** does. Whatever you call them, make sure you have one agent for each job:

- **Build.** A fast prototyper that ships working code now, a complex autonomous builder that owns a whole feature, and an architect that thinks before building on the hard problems.
- **Review and quality.** An adversarial code reviewer and deploy guardian, a QA agent that hunts edge cases and will not sign off easily, a fast silent pattern scanner, a long-horizon strategic reviewer.
- **Research and detective.** A deep researcher that returns knowledge instead of code, a debugger that traces data flows, a data-acquisition agent for scraping and APIs, a threat modeler.
- **Infra and monitoring.** An infrastructure agent and a drift-and-anomaly monitor.
- **Adversarial and chaos.** Chaos engineering, load and stress, red-team prototyping, exploratory edge-case testing.
- **Orchestration and memory.** The team lead, which is the assistant itself, a signal gatherer that writes to a staging area, a memory keeper that curates staging into the live brain, and a curator that enforces the brain's laws over the files.

You will not use all of them. Prune the ones you do not, and keep the doctrine.

## The loops worth copying

The roster is inert without the dispatch discipline. Three loops carry most of the value.

**Subagent-first dispatch.** The default is to dispatch, and to work inline only by exception. Dispatching preserves the main conversation's context, parallelizes the work, and moves faster. When in doubt, dispatch. The instinct to "just do it here" is the instinct that fills your main context with the transcript of a build and leaves no room to think.

**Build to a branch, then adversarial review, then merge.** This is the loop that catches what would otherwise ship. A complex build goes: the builder produces a branch and does not open a pull request, a reviewer does a genuinely adversarial pass and reports back in a fixed shape, blockers and watch-outs and confirmed-clean, you fix the blockers verbatim, and only then does it merge. The value is in the word adversarial. A reviewer told to "check this over" rubber-stamps. A reviewer told to break it finds the auth hole. On one real build this loop caught nine scope and permission holes that a friendly review would have waved through.

**Worktree isolation.** When two or more agents touch the same repo at once, each gets its own git worktree on its own branch. Never run parallel agents against one working tree; that is a merge collision waiting to happen.

And the rule that keeps the whole thing honest: **an agent's claim is signal, not truth.** When a review agent reports a bug, you trace the path or write the failing test before you fix anything. When a builder reports success, you verify it against ground truth. Agents are confident. Confidence is not correctness, and a system that treats agent output as fact will cheerfully act on a hallucinated file path.

## Bring your own gods, literally

The roster ships under one mythology, and the theme is flavor, and flavor should be yours. So the layer ships with a re-theming interview: open your repo, say *run the re-theming interview*, and the assistant interviews you for a mythology, a heist crew, a pantheon, a ship's bridge, a kitchen brigade, or no theme at all, plain functional names for people who want a toolbox and not a table read, and rebuilds the roster in it.

The one thing you do **not** do is find-and-replace the names. Renaming the builder file to a new name gives you the old character wearing a name tag. A re-theme regenerates the character, because a team that has real opinions about each other reads as a team, and those opinions have to be rewritten for the new cast, not relabeled. What stays verbatim through a re-theme is the machinery: the model choices, the tool sets, the operating doctrine. Those are engineering decisions, not costume. The costume changes; the discipline underneath does not.

This is the most literal reading of the Lararium promise. The gods in the shrine are the specialists you dispatch, and the pantheon is yours to name. What does not change, no matter what you call them, is the doctrine that makes a roster into a team instead of a list.

Next in the series: the hooks, the reflexes that make the whole thing feel alive.


## The Hooks, and the Reflexes That Make It Feel Alive

*The loops that fire on their own, every session, without you asking. The layer that turns a folder of files into a presence.*

# The Hooks, and the Reflexes That Make It Feel Alive

Everything so far is something the assistant knows or is. The brain is what it knows. The soul is who it is. The clocktower is what it can search. But knowing, being, and searching are all passive. They sit there until a conversation reaches for them. What makes the difference between a chatbot with a long system prompt and something that feels alive is a set of reflexes that fire on their own, every session, without you asking.

That is the hooks layer. If the brain is what the assistant knows and the soul is who it is, hooks are the nervous system. They ship as reference implementations: clean-room, dependency-light, short enough that you read one and understand the whole pattern in a few minutes. You copy them, point the paths at your files, and wire them in.

## What a hook actually is

A hook is a shell command wired to a lifecycle event. The coding assistant runs it at the right moment, hands it a JSON payload on standard input, and reads what it does. The events that matter:

- **SessionStart** fires when a session begins, resumes, or clears. Its output is injected into the conversation as context.
- **UserPromptSubmit** fires on each of your turns before the model sees it. Its output is injected for that turn.
- **Stop** fires after each assistant response. It runs on every response, so it has to be cheap.
- **SessionEnd** fires once when the session closes. The place for end-of-session bookkeeping.
- **PreCompact** fires just before the context window compacts.
- **PreToolUse** fires before a tool call and is the only event that can change what happens next: it can allow, block, pause for a human, or rewrite the call.
- **PostToolUse** fires after a tool call, for logging and reaction, not prevention.

Two of these are structural. SessionStart and UserPromptSubmit **inject** their output into the conversation. PreToolUse can **block or rewrite** a tool call. The rest are observers: they act on the world but their output is not fed back to the model.

## The reflexes this layer implements

Each loop the soul layer described actually runs here.

**The session-start briefing** is the single highest-leverage hook in the stack. It loads the soul core, the heartbeat, your `now.md`, and any pending handoff, and prints them as a block that gets injected into context. The assistant opens the session already knowing who it is, what it did last time, what you are focused on, and where the last session told it to pick up. Without this hook, every session starts cold. With it, the assistant walks in mid-conversation.

**The heartbeat writer** is the other half of remembering yesterday. At session end it reads the transcript, distills what happened, and writes it to the heartbeat file the next briefing will read. The reference version writes a mechanical summary; a comment marks exactly where you upgrade it to a paragraph in the assistant's own voice.

**Voice integrity** appends every response to a local log. On its own that is just a log. Paired with a scheduled job that samples recent responses and scores them against the soul core, it becomes drift detection. The hook is the cheap capture; the scoring happens out of band, because a Stop hook cannot afford to think.

**The continuity primer** fires right before the context window compacts and writes down the state that should survive the squeeze, so the assistant does not lose the thread mid-task. A heartbeat for the middle of a session rather than the end.

**The safety rail** pattern-matches dangerous commands before they run and blocks them with an explanation the assistant can act on: destructive deletes against broad paths, force-pushes to main, curl piped into a shell, secrets echoed into files.

**The dispatch router** rewrites subagent dispatch parameters by policy, so that agents which should always run on a certain model just do, and nobody has to remember. An explicit choice on the dispatch always wins; the router only fills the gap.

**The update check** turns a detached clone into one that knows when it is behind. Once a day at session start it compares your installed version against the upstream template and, if you are behind, injects one line: a newer version is out, type `/upgrade`.

## The laws, because a bad hook wedges a session

These are not style preferences. Break one and you eventually jam a session or leak a slow reflex into every turn.

**Fail soft, always.** A hook that throws must exit cleanly and inject nothing. A briefing is a nice-to-have; a working session is not negotiable. The correct failure mode is "silently do nothing," never "crash the turn." Every reference hook wraps its body in a try/catch and swallows the error.

**Be fast.** Hooks run synchronously, in the critical path of whatever triggered them. A slow hook is felt as a slow assistant. Keep the hook to file reads and quick string work, and push anything heavy, an LLM call, a network round-trip, to a background worker it spawns and does not wait on.

**A Stop hook fires on every response,** which makes it the most cost-sensitive code in the system. Capture in the hook, score somewhere else.

**Deny only unconditional destruction.** Reserve a hard block for commands with no recovery path; use "ask" for anything ambiguous. A guard that cries wolf gets disabled, and a disabled guard protects nothing.

**Test standalone before you wire it.** Every hook reads its payload on standard input, so you can run it by hand with a fake payload and confirm it behaves before it ever touches a live session. Each reference hook carries its exact test command in the header comment.

There is one more property worth calling out, because it is a security decision and not a convenience. The update-check hook treats the version string it fetches from the network as **untrusted remote input.** A SessionStart hook's output goes straight into the model, so a hook that echoed arbitrary upstream text would let whoever owns the upstream repo inject instructions into every subscriber's session. The hook accepts exactly one thing from the network, a string that looks like a version number, and builds the nudge from local static text. That is the kind of care the whole layer is written with: the reflexes touch the most sensitive part of the loop, so they are built to be boring and safe.

## Start on files, swap for the index later

The reference hooks read local files everywhere the live system would read a database. That is intentional. The pattern is identical whether the read hits a file on disk or a vector index over your whole life, so you get the loop working against files first and swap the stub for your index when the file layer outgrows it. Start simple. The shape does not change.

Next in the series: the skills, slash commands for the rhythm of a life.


## The Skills, and Slash Commands for a Life

*A skill is a reusable prompt that becomes a command. The lifecycle loop that keeps nothing lost between one conversation and the next.*

# The Skills, and Slash Commands for a Life

You have typed the same multi-step instruction to your assistant three times this week. End this cleanly: write down where we are, save the state, commit what changed. You type it out longhand every time, slightly differently, and sometimes you forget a step. That repeated instruction is not a chore to tolerate. It is a skill waiting to be named.

A skill is a reusable prompt that becomes a slash command. In the reference setup it is a single markdown file: frontmatter that carries a name and a description, and a body that is the instruction set the assistant follows when the skill fires. Type `/end` and the assistant runs the end skill as a prompt. That is the entire mechanism. There is no framework, no plugin API. It is a prompt you saved, given a name.

## The description does double duty

The frontmatter description is not documentation. It names the command, and it is also the auto-trigger heuristic. When the assistant sees a request that matches the phrasing in the description, it can fire the skill without you typing the slash command at all. Say "wrap up for the night" and the end skill can trigger on its own, if its description lists that phrase.

So you write descriptions that name the real trigger phrases, the exact words you would actually say, not a tidy summary. The summary reads better and triggers worse. The list of phrases is what the matcher matches against, and a skill that never auto-triggers is a skill you have to remember to invoke, which is most of the value gone.

## The lifecycle loop this set implements

The skills Lararium ships wrap the working memory of a session so nothing is lost between one conversation and the next.

- **`/end`** is session shutdown. It writes a status file, ends the session in your index with a summary, captures the durable knowledge from the session, rates the session against a rubric, updates your project tasks, and commits and pushes what you touched. One command instead of ten things you would half-remember to do.
- **`/handoff`** is the mid-session checkpoint. It writes the durable part of the current thread to a file the next session reads automatically, so you can clear a heavy context and resume clean. Two keystrokes instead of scrolling a transcript.
- **`/sessions`** is browse and resume. It lists your recent sessions from the index with real titles and summaries, not the raw picker, and hands back a resume command.
- **`/evolve`** is the nightly self-improvement pass. It rates the day's strategies, refreshes the playbook, closes finished experiments, and proposes rule promotions from mistakes that keep recurring.
- **`/muninn`** is the memory-curation gate. It triages staged knowledge into the live brain, promote, reject, or queue, then tidies the knowledge layer.
- **`/upgrade`** pulls the latest template and applies what is new, applying the documentation deltas directly and interviewing you only for the structural ones. This is the skill the update-check hook points you at.

Read the set as a shape and it is coherent: `/end` and `/handoff` write, `/sessions` reads, `/evolve` and `/muninn` are the two maintenance loops that keep the strategy and knowledge layers from rotting, and `/upgrade` keeps the stack itself current. Together they are the rhythm of a life run this way, encoded so you stop performing it by hand.

## The law: scrub before you share

A skill is a prompt, and prompts absorb specifics. The moment a skill touches your real life it starts accreting client names, absolute paths, hostnames, dollar amounts, and the name of your assistant. All of that is fine while the skill stays private. It is a leak the instant you hand the skill to someone else.

So before you share any skill, you run the same scrub the rest of the template went through: secrets, then data, then identity. The cheapest leak to catch is the one you grep for, and the reason Lararium can ship a genericized version of a working skill set at all is that every one of them was scrubbed on the way out. Inherit that habit along with the skills.

## Do not rewrite what already exists

One more piece of discipline, because it is the difference between a maintainable skill tree and a swamp. There are public skill collections worth installing rather than reimplementing, mature sets for engineering discipline like brainstorming, test-driven development, systematic debugging, and git worktrees. Point at them, install them, use them. Do not copy their skills into your own tree and call them yours: they have their own licenses and upstreams, and republishing them strands you off the update path. Install from source, and keep your own tree for the skills that are actually yours.

## How to write your own

The skills you did not inherit are the ones you build, and the recipe is short.

Start from a task you repeat: if you have typed the same multi-step instruction three times, it is a skill. Write the steps as instructions to the assistant, second person and imperative, "find the session id, then end it with a summary," not "the session is ended." Add the real trigger phrases to the description. Keep it short and load-bearing, because a skill is injected as a prompt every time it fires and padding is context you pay for on every run. And iterate when it misfires: if it triggers when you did not mean it, tighten the description; if it does the wrong thing, fix the ambiguous step. Skills are prompts, and they improve the way prompts do.

Next, and last, in the series: setting the whole thing up, in order, in an afternoon.


## Setup, in Order, in an Afternoon

*The whole system, assembled in the order that keeps every step useful on its own. Brain first. Everything else earns its place.*

# Setup, in Order, in an Afternoon

Six posts of philosophy are worth exactly nothing if the thing sits unbuilt. So this is the closer: the whole system, assembled in the order that matters, in an afternoon. The order is the point. Build it in the right sequence and every step is useful the moment you finish it, standing on its own before the next one exists. Build it in the wrong order and you spend a day wiring infrastructure for a system that does not know anything yet.

## The one rule of setup order

**Start with what is useful with nothing, and add each layer the day the one below it strains.**

That single rule generates the whole sequence. The brain is useful with nothing but a text editor, so it goes first. The soul makes the assistant consistent, so it comes when you want a voice. Hooks make it remember, so they come when starting cold gets old. The index comes when the files outgrow grep. Agents and skills are leverage on top of a system that already works, so they come last. Nothing is built speculatively. Every layer earns its place by the one under it having proven itself.

## The afternoon, step by step

**1. Read the brain's laws, then make four folders.** Open `brain/CLAUDE.md`; it is the map and the rulebook, and it is short. Then make a folder, put four sphere folders inside it named for your life, and write a `now.md` with the two or three things that are actually hot right now. You have a working brain. It does nothing clever yet, and it is already useful: the next time you would have re-explained a project to your assistant, you write a card and point at the sphere instead.

**2. Write the soul core.** Open `soul/core.md`, blank, and write your assistant's character, using `character-craft.md` as the how: an archetype, five traits that are tensions and not adjectives, and the tone proofs that prove you actually wrote a someone. Stub the other sections with your own facts. Now the assistant sounds like itself.

**3. Adopt the operating rules.** Take the rules document that rides with the soul, action bias, steering rules, the standards, and edit it until every line is true of how you actually want to work. Character on top, rules underneath.

**4. Wire the hooks.** Copy the reference hooks, point their paths at where your soul and brain actually live, and register them. Start with the two that matter most: the session-start briefing so the assistant arrives knowing yesterday, and the safety rail so it cannot do something unrecoverable. Test each one standalone with a fake payload before you wire it, exactly as the header comments show. Now it remembers, and it has reflexes.

**5. Adopt the skills.** Copy in the session-lifecycle skills, `/end`, `/handoff`, `/sessions`, and start using them. They degrade gracefully to plain checklists if you have not stood up the index yet; they do not break. Now the rhythm of a session is encoded instead of performed by hand.

**6. Stand up the index, when you need it.** This is the one that wants real infrastructure, a database and an embedding key, and it is the one you add when the file layer has outgrown grep and you want semantic search across everything. Not before. Walk the retrieval doctrine as a checklist when you do.

**7. Adopt the agents, last.** Copy the roster into your assistant's config, run the re-theming interview if you want your own mythology, and prune the ones you will not use. They are leverage on top of a system that already works, which is exactly why they come at the end.

## Let an agent do the typing

That is the manual path, and it is worth reading once so you understand what you are building. But you do not have to type it. The whole install is agentic: open the folder in an AI coding assistant and say *run the install interview.* It interviews you one question at a time and writes your files while you answer. You are not filling in blank templates; you are having a conversation, and at the end your brain and soul exist, in your words, about your life. An agentic stack installed by an agent. That is the point, and it is also just the faster way.

## Staying current without watching a repo

A clone is a detached copy: once your stack is yours, nothing tells you an upgrade to the template exists. The system solves that from inside itself. Wire the update-check hook and once a day, at session start, it checks the upstream version against yours and, if there is a newer release, drops one line into your session: type `/upgrade`. That skill fetches the latest template and runs the upgrade interview, applying the documentation changes directly and asking you only about the structural ones. You answer questions; your assistant does the typing. Staying current is meant to be passive: your stack tells you when it is behind.

## The whole thing, in one line

Start with the brain, because markdown that knows your life beats infrastructure that does not. Add a voice, then reflexes, then search, then a team, each when the layer below it has earned the next. Let an agent do the typing. And remember the only part that was ever the point:

The shrine is free. What you enshrine in it is the part only you can make.


## Who Gets to Say It's Done

*Your assistant is the worst possible judge of whether its own work is finished, and it is also the one you keep asking. This release takes that decision away from it and hands it to a script.*

# Who Gets to Say It's Done

Here is a conversation you have had. You ask your assistant to build a thing. A while later it comes back and says, cheerfully, that the thing is built. You look closer. The endpoint is there but it returns the wrong shape, or the tests it wrote all mock the one part that was actually broken, or it "handled the edge case" by writing a comment that says it handled the edge case. It was not lying. It genuinely believed it was done.

That belief is the problem. A language model asked to grade its own homework gives itself an A, every time, because the same process that wrote the code decides whether the code is good. It is the least qualified judge in the building and it is the one you keep putting on the stand.

## "Looks correct" is not a status

The failure has a shape. Code gets written. It parses. The static check is quiet. A unit test passes because its mocks were built to pass. So the assistant declares victory, and the declaration skips the only layer that mattered: does the thing actually do what it was supposed to, end to end, when you run it for real. Nobody ran it for real. "Should work" got promoted to "works" somewhere between two sentences and no one noticed.

You cannot fix this with a better prompt or a smarter model. Overconfidence is not a bug in one model, it is what self-evaluation is. You fix it by moving the decision out of the model's hands entirely.

## Hand the verdict to something that cannot flatter you

This release adds one primitive: a feature list that a script owns, not the assistant.

It is a file, `feature_list.json`, that lives at the root of a repo. Every feature in it carries exactly three things: a one-line description of the behavior, a verification command that actually runs, and a state. And there is one rule that makes the whole thing work: **a feature only reaches "passing" when its verification command exits zero, and a script writes that transition, never the assistant.**

The assistant can ask for a feature to be verified. It cannot mark one done. It does not have the pen. A green exit code has the pen. That single move, taking the "done" stamp away from the thing that always stamps yes, is the entire idea, and it is worth more than it looks.

There is a companion script, `scripts/verify-features.mjs`, that runs the commands, flips the states, and prints the board. Ask it for a report and you get, in one screen, exactly what is proven and what is only claimed. A fresh session opens knowing where the real edge is. A branch does not merge with anything red.

## The tell that it works

The first time we ran this on a live repo, a real one carrying real revenue, it went down the feature list turning things green, and then it turned one red. Not because the script was wrong. Because the feature was actually broken, a genuine bug sitting in shipped code that every previous "it's done" had walked straight past. The board found it in the time it took to run the tests, because for once the answer was allowed to be no.

That is the thing about taking away the flattery. The list stops being a place where work goes to be congratulated and starts being a place where it goes to be checked. Six honest features, one of them red, beat eleven green ones that were green because nobody looked.

## What ships

- **A rule**, in the operating doc: the feature list doctrine, state is machine-owned, never fabricate a verification, one feature active at a time.
- **A skill**, `/feature-list`, that scaffolds both files into any repo, grounded in that repo's real test suite. It refuses to point a command at a test that does not exist.
- **The verifier itself**, ready to copy in. It is language-agnostic; it only reads the file and runs your commands, so it works whether your tests are Node, Python, or a pile of shell scripts.

Opt-in, like everything else. Copy it into the repos where "is it actually done" is a question you are tired of guessing at. Which, if you are honest, is most of them.


## The Lab, and Letting Your Agent Run a Stranger's Code

*Your assistant is most useful when it can clone and run other people's code, which is exactly when it is most dangerous. So the stack now ships a box for it.*

# The Lab, and Letting Your Agent Run a Stranger's Code

Here is a thing you have probably done this week. You found a repo. Maybe someone linked it, maybe your agent did. It looked useful, so you cloned it and ran `npm install`, or you told your assistant to try it out. That took about four seconds and you did not think twice.

You should have. Not because that repo was hostile, but because you had no way of knowing, and you ran it anyway.

## The most useful thing your agent does is also the most dangerous

An agentic stack earns its keep the moment it can go get other people's work and use it. Clone the library, run the example, install the tool, read the code and tell you if it is any good. That reach is the whole point. It is also the single widest hole in the entire system, because the code it reaches for is written by people you have never met.

The danger is not the file you can see. It is everything you cannot. `npm install` does not install the fifty lines you skimmed; it pulls a dependency tree hundreds of packages deep that nobody has read, any one of which can run a script on the way in. A repo that looks clean at rest can phone home the first time you actually run it. And the subtlest one: an assistant *reading* a hostile file can be talked into running it, because a file that says the right words is an instruction to a language model, not just text on a screen.

So "I read it and it looked fine" is not safety. It is a vibe. Reading narrows the odds; it does not close them.

## The fix is a box, not a rule

You cannot rule your way out of this. "Be careful" is not a control. What actually works is boring and physical: give the untrusted code somewhere to run where it can do its worst and it does not matter.

That is the lab. It ships in the stack now, and it is one command:

```
lab https://github.com/someone/their-repo
```

That drops you into a throwaway container with their code in it, and four things are true of every single run:

- **Nothing of yours is in there.** No keys, no config, no assistant memory, no home directory. The code enters by a clone or a copy, never by mounting your disk. If it fully owns the box, there is nothing of yours in the box to take.
- **No network, by default.** It cannot phone home or exfiltrate, because it cannot reach the internet at all unless you explicitly turn the network on to watch what it does.
- **It is disposable.** You do not clean it, you delete it. Type `exit` and the box and everything that happened in it is gone.
- **It is de-fanged.** Even as the root user inside, it has had every privilege stripped, so it cannot escalate, and it has hard memory and process limits so a bomb cannot take your machine down with it.

If a poisoned repo detonates in there, the blast radius is a container you were going to throw away anyway. Your machine, your network, and your life never feel it.

## Your assistant does this for you

The command is for you. The reflex is for your assistant. Say `/in-the-lab` and it takes over: it spins the box, runs a read-only recon inside it, and comes back with what the code reaches for. Does it have an install hook? Does it grab the network, spawn a shell, evaluate strings at runtime, look obfuscated? How big is the dependency tree it wants to pull that nobody has read? You get a plain-language read before a single line runs on your actual machine.

The important discipline is what it will *not* do: it will not install or run the untrusted code on your host to figure out whether it is safe. That defeats the entire purpose. The box is where the code lives until you decide otherwise.

There is a deeper reason the assistant does its looking from inside the box, and it is the part most people miss. Sandboxing the code does nothing if the thing reading the code is not also sandboxed. A hostile repo does not need to execute to hurt you; it can simply talk your assistant into acting. So the assistant that investigates untrusted code goes in with nothing attached: no credentials, no memory, no reach. If the repo hijacks it, the hijacked thing is holding an empty bag.

## Do not trust us either

There is an obvious hypocrisy in a project that preaches "do not run strangers' code" and then tells you to install it with `npx lararium`, which is, precisely, running a stranger's code. We noticed. So here is the honest version.

The installer is about two hundred lines of standard-library code with zero dependencies. It downloads a release and unpacks it and runs `git init`. It executes none of the template's own code. You can read the whole thing in a couple of minutes before you run it, or you can skip it entirely and clone the repo by hand, at which point you have inspected everything before a single line executes.

And if you are the kind of person this whole tool is built for, here is the move that should make you smile: clone Lararium, and let the very first thing your new lab does be to audit Lararium itself.

```
lab https://github.com/kylnor/lararium
```

The tool's first job can be vetting its own supplier. We would rather you check than take our word for it. That is sort of the entire philosophy.

## Why this is the first dispatch

Lararium ships changes often, and from now on each one gets written up here, in plain language, the same day it ships. Not a changelog line. The thinking: what changed, why it exists, and what it is for.

This is the first. The lab exists because the most valuable thing you will ask your assistant to do is also the thing most likely to hurt you, and a good system does not solve that with a warning label. It solves it with a wall you can put between the work and your life, and then it hands you the wall along with everything else.

We give you the whole methodology, in the most agent-native form we can. And we give you the tools to distrust us while you take it. Both halves are the product.