# The real boot file (sanitized public version) This is the actual CLAUDE.md running a portfolio of agent-operated businesses, sanitized only where keys, client names, and project ids lived. Two files matter: the small root file every agent session reads first, and the brain README it points at. Both are below. --- ## Part 1: the root file (verbatim, sanitized) ```markdown # repo guide This repo is the ** command center**: the operations dashboard (Next.js, at the root) + the master **brain** (`brain/`) + the video-channel subsystem (`/`). ## Read this first **Start every session by reading `brain/INDEX.md`.** It is the map of every venture I run, with status and where each lives. The conventions and the status contract are in `brain/reference/conventions.md`. The brain is the strategy/identity layer (markdown, in git). High-volume structured data lives in a database per venture. The dashboard (this app) is a read surface over both. ## Working rules - **Voice:** no em-dashes inside sentences (an AI tell I kill on sight). Sentence case. Plain and direct. - **Model efficiency (standing rule):** burn tokens freely, but match model to task: the top model for judgment, the mid model for research/drafting/most building, the small model for mechanical/bulk work. Set the model deliberately when fanning out agents. - **Reuse the venture pattern**, don't reinvent it: a `_brain` knowledge table + a task queue + a session log + entity tables + a small Next.js dashboard + a Claude Code skill as the front door + scheduled sessions over the queue. - **Subsystems have their own front doors:** the video subsystem has its own skill and its own PROJECT-RULES.md. Other ventures live in separate repos (see `brain/INDEX.md` for paths). - **X posting:** all main posts go through the posting engine + its drafts table (see `brain/reference/` and the publisher agent definition); never hand-post an engine-owned lane. ## Databases - ``: the shared project (one schema prefix per venture). - ``: venture A. ``: venture B (separate projects). ``` That is the whole file. About 35 lines. Everything else lives one pointer away. --- ## Part 2: the brain README it points at (abridged, sanitized) The root file stays small because the brain carries the weight. The README is the contract for how any session, human or scheduled, reads and maintains the knowledge layer. ```markdown # The brain: boot sequences + maintenance discipline ## Boot sequences (ordered read lists; follow them, do not improvise) - **Master session:** 1. INDEX.md -> 2. the latest daily digest -> 3. NEEDS-ME.md -> 4. OPEN-ITEMS.md -> 5. the status CLI -> 6. conventions.md. (Digest before backlog: the digest is the freshest truth.) - **Each venture:** its own ordered list, ending at its own front-door skill. ## Update discipline - **Current truth at the TOP of every file.** Never append reality under a stale top. - **Bump the `updated:` frontmatter on every edit.** - **Big rulings become dated decision records**, not bullets in a backlog. - **Executed plans get stamped ("executed " / "superseded by X") and moved to archive/.** Never leave a done plan saying "planned". - **New brain files get `git add`ed the same day** (the daily autosave only commits tracked paths). - **Digest retention:** keep the last 30 daily digests flat; monthly rollups go to archive. Nothing is deleted. ## Precedence when docs disagree 1. the live database -> 2. the latest digest -> 3. decision records -> 4. the backlogs -> 5. venture and reference files -> 6. anything in archive/ (history only). ## LIVE SCHEDULES registry One table listing every scheduled task: cadence, what lane it drains, and its state. A lane is only alive if a task here drains it, and a task only counts as armed once a completed run is verifiable. Update the table the same day any schedule changes. ``` --- ## Why these lines earned their place - **"Read the INDEX first."** The boot file does not try to BE the knowledge. It points at a map. Sessions that boot from a map stay consistent; sessions that boot from vibes drift. - **The voice rules.** An agent that writes in your name will leak AI tells unless the tells are named in the file it boots from. The em-dash rule alone has saved me from sounding like a press release hundreds of times. - **The model-tiering rule.** Agents spawn agents here, and the spawner picks the model. Without the rule in the boot file, every subagent defaults to the expensive brain for mechanical work. - **The venture pattern.** The fastest way to launch venture number five is to make it shaped exactly like ventures one through four. The pattern is written down so no session reinvents it. - **"Subsystems have their own front doors."** A root file that tries to hold every subsystem's rules goes stale in a week. Each subsystem gets a skill and a rules file; the root just points. - **The posting rule.** The one hard "must not": everything public goes through one audited engine with a draft queue and sign-offs. An agent that improvises around the plumbing is how accounts die. This line is a scar, not a guess. - **Precedence order.** With dozens of markdown files and a database, documents WILL disagree. Deciding the tiebreak order once, in writing, ends a whole class of agent confusion. - **The schedules registry.** "The system handles it" is not an owner. Every lane lists the scheduled task that drains it, and a task is not armed until a completed run is verified. Steal the structure, not the words. Yours should read like your operation: your ventures, your scars, your tiebreaks. The file is where every mistake gets written down once, so the next session inherits the fix instead of rediscovering the failure.