Setup, wiring, staffing: a working Claude Code environment.

It is a knowledge operating system, not a developer terminal.

Every design decision downstream of this one reflects it. The files I care about are markdown and HTML, not source code. The artifacts I produce are research briefs, framework documents, published web pages, and account plans. The friction I care about reducing is not compilation time or test coverage; it is the friction of knowledge work. Source sprawl. Context drift across long sessions. Losing track of which framework belongs to which chapter. Forgetting which target account said what in which quarter.

If you treat Claude Code as a developer's terminal, you end up wiring it for CI/CD, git workflows, and test runners. If you treat it as a knowledge operating system, you end up wiring it for context loading, voice enforcement, graph routing, and memory hygiene. The rest of this document is the second path.

The instrument follows the framing. Choose the framing first.

Finder tags carry the type system the filesystem does not have.

My Desktop has four hot folders. The important ones are color-tagged in Finder, and the tags are a type system, not decoration. Red means the Brain, the knowledge operating system. Structured, machine-readable, hand-curated. Green means the Site, the live deploy folder: push equals live in thirty seconds. Every other folder is uncolored, which means scratch, reference, archive, or legal. Color is the exception, not the category.

• 🔴 RBD Brain/The knowledge operating system. Graphs, methodology, book, board files. Hand-curated. Claude queries these before anything else.
• 🟢 RBD Site/The live deploy. Git repo wired to GitHub and Netlify. Push equals live in thirty seconds. Every write here is consequential.
• RBD Site Reference/Specs, templates, QA process, internal docs, animations, frameworks. Not deployed. Read often, written less often.
• Strategy/Revenue ops, partnerships, workshops, outreach. The business layer sitting on top of the knowledge layer.

This matters because when Claude edits a file, it needs to know whether it is touching canonical knowledge, deployable content, private reference, or archive. The filesystem does not encode that distinction natively; a linter hook scoped to the colored paths can, and mine does (§07). The generalizable principle: if you want Claude to treat different files differently, put them in different folders and wire your hooks to those paths. Do not try to teach Claude a policy. Teach the harness.

PDFs do not survive long threads. Graphs do.

Early in this practice I tried the obvious thing: upload a 300-page manuscript, a slide deck, a prospect research file, and ask questions. It worked for about ten turns. Then attention drifted, the source of a quote became ambiguous, and I could not tell whether the framework I was seeing was my own or a paraphrase.

The workaround is a file format I now use for almost everything I want Claude to understand at a glance: a 5 to 15 kilobyte markdown file, structured as a graph. Nodes at the top (a list of entities with short labels), edges in the middle (the relationships between them), and attributes at the bottom (per-node detail). The header of the file is a loading instruction telling Claude how to read it. I call these knowledge graphs, not because they are a graph database, but because they are shaped like graphs and read like graphs.

Six of these lived in the Brain in April. Eleven clusters do now:

• ip-graph/The intellectual-property side. A compressed map of the frameworks and concepts from my book: what each one is, how they relate, and which buyer problems they apply to.
• prospect-graph/The sales side. Ten target-account files plus four shared files (topology, attributes, signals, plays). Each account file holds the current state of outreach.
• ic-index/A registry of every published research product on my website. Title, price tier, topic, file path. The registry points at the deployed products; it does not copy them.
• book-reference/The full 320-page manuscript, re-shaped from a PDF into a plain-text corpus with a chapter index and canonical framework definitions (§05).
• board-files/Working files for the strategy board (§12): dossiers, context sheets, past deliberations.
• methodology/The runbook for authoring new knowledge graphs, plus, since June, the session-mining pipeline (§19).
• client-graph/Added since April. Client work: the active client list, a lessons log, and a proof database compiled from JSON sources by a merge script, so every credibility claim traces to a source entry.
• sac-graph/Added since April. The relationship graph for a collective of independent consultants I belong to. Thread map, commercial state, roster, voice file. The account team in §12 works over it.
• rfp-engine/Added since April. The data behind the daily opportunity hunt: scoring criteria, source list, a seen ledger, digests, pre-drafted responses.
• chief-of-staff/Added in July. Priorities (top 3, parked, autopilot), a framed decision queue with a closed log, an ideas backlog, and staff-meeting minutes.
• sessions/One-page breadcrumb manifests, one per retired session (§18). Pointers, not copies.

Every graph is under ~15 KB. Every graph loads in a single Read call. Every graph is hand-edited, on purpose. If you have a body of knowledge you reference constantly, shape it as a small dense markdown graph, not a folder of documents.

A graph you can load in one Read call becomes part of Claude's working memory for the whole session. A folder you have to walk becomes context Claude keeps losing. Size the unit to the Read call, not to the topic.

Four types, one registry, auto-loaded every session.

Claude Code has a memory system at ~/.claude/projects/<slug>/memory/. The default is a single file, MEMORY.md, auto-loaded at every session start. I use a different shape: MEMORY.md is a registry, not the content. It holds one-line pointers to individual memory files, typed by filename prefix:

• user_*.mdFacts about me. Who I am, what I do, how I work. Decays slowly.
• feedback_*.mdRules and corrections: "avoid this form," "always use this phrasing." The accumulated judgment of the practice. Should never decay.
• project_*.mdActive initiatives. Deadlines, live proposals, engagements in flight. Decays fast. Needs pruning.
• reference_*.mdPointers to external systems and verified facts about tools. Decays only when the external system changes.

The registry has grown with the practice: 118 files as of July, up from roughly two dozen in April. The distribution tells you what the system actually is: 74 of the 118 are feedback rules, 26 references, 14 active projects, 4 user facts. Nearly two thirds of everything the system remembers is accumulated judgment about how to work, not facts about the world. That ratio is the product of the close-out ritual (§18) running at the end of every session for four months.

Why this beats a single big memory file: the single file ossifies. You stop editing it because any edit feels risky and any edit bloats it. A sharded registry is easier to update (edit one small file, add one line to the registry) and cheaper to load.

320 pages turned into a skill in an hour.

My book is 320 pages, and until April it sat on my Desktop as a PDF. Every time I wanted Claude to quote from it or verify a framework name, I attached the PDF to the session; attention would drift and by hour two I could not tell whether a definition came from the book or from Claude's memory.

The fix was to stop treating it as a document and start treating it as a knowledge graph. I ran the PDF through a text extractor, wrote the full text to a plain file with page markers, computed chapter line ranges, pulled out the glossary definitions, and authored a skill that routes queries to the right slice. Concept questions load the definitions file. Location questions load the chapter index. Exact-quote questions search the full text, so citations come back with line numbers.

The result: the book loads by skill description, not manual attachment. Any mention of a framework name fires the skill and the canonical definition is present without me doing anything. The generalizable pattern: if you have a long reference document you cite constantly (a book, a methodology, a contract, a regulatory text), do not attach it. Extract it. One hour of work, reused daily since.

Eighteen authored skills. The description field is the routing logic.

Skills are folders under ~/.claude/skills/, each containing a SKILL.md whose frontmatter description tells Claude when to use it. The description is the routing logic: Claude reads every description at session start and invokes a skill when the prompt matches its trigger vocabulary. You do not invoke skills; the vocabulary does. Write the description as a list of trigger phrases in the register you actually type ("qa this," "run qa," "ready to ship"), not documentation voice ("this skill helps you review quality"), and the right bench of tools loads itself whenever you talk that way.

The authored library has tripled since April: six skills then, eighteen today, in four benches, plus the Anthropic-maintained file-format set (pdf, docx, xlsx, pptx) that ships with the product:

• Editorial benchThe original six, still in daily use. rbd-writing-voice (the voice standard), rbd-site-nav (navigation consistency), world​-class-web-app (page-quality patterns), book-reference (the manuscript, made searchable), qa (two-layer quality review), retire (session close-out triage).
• Voice benchAdded since April. Register control per document genre: megan-voice (personal messages, matched to the recipient), proposal-voice (bid and engagement documents), newsletter, post-session (turns a client session transcript into a full deliverable package), rfp-response, distill (curates the client lessons log into stable patterns).
• Staff benchAdded since April. Skills that convene agents rather than produce documents: board (the five-seat strategy board, §12), sac (the account team, §12), avery (the digital EA, §14), cos (chief of staff, §10), dump (the intake door, §17).
• Harness benchConfigures Claude Code itself. update-config, keybindings-help, loop, schedule, claude-api.

The staff bench is the shape worth noticing. A skill used to be a way to load knowledge into one context. The staff skills instead act as conveners: board reads the decision on the table, routes it to the seats whose lens applies, and synthesizes their answers into one recommendation. The skill is the meeting; the agents are the attendees.

The full authored inventory, for anyone replicating the setup. Fires-on is the trigger vocabulary in each description; writes-to is the file each skill is allowed to touch.

The design pattern to copy: every custom skill bundles its reference material in a references/ subdirectory and uses the SKILL.md purely as a router, under a page long. Claude reads the description to decide whether the skill applies, and loads the references only when it needs them.

~/.claude/skills/book-reference/
├── SKILL.md                 # router: when to load which reference
└── references/
    ├── frameworks.md        # definitions + relationships (concept queries)
    ├── chapters.md          # chapter → line ranges (location queries)
    └── book.txt             # full extracted text (exact-quote queries)

Two hooks wired. Skills fire on topic match; hooks fire on events.

The difference between a skill and a hook is worth understanding precisely. A skill is topic-routed: it fires when the vocabulary of your prompt matches its description. A hook is event-routed: it fires when Claude Code emits a lifecycle event (SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, Stop). Skills depend on Claude recognizing that a skill applies. Hooks are executed by the harness itself, so memory is not load-bearing for them.

I have two hooks wired. load-manifest runs at SessionStart and injects the Brain's routing table (§16 shows the script). qa-lint runs at PostToolUse on every Edit, Write, and MultiEdit call, and runs a regex linter against the file that was just modified. Three design decisions inside it are worth naming:

• Scope by path prefix. The hook runs only on .md and .html files inside the four hot folders. Everywhere else it exits silently.
• Warnings over blocks. The hook exits with code 2 and writes to stderr, which surfaces violations to Claude as feedback without undoing the write.
• Self-documentation is a known limitation. The hook flags its own rule names whenever a document like this one quotes them. A planned escape marker is not built yet.

The generalizable principle: if a rule must hold regardless of whether Claude invokes the right skill, build it as a hook. Hooks are the harness. Skills are the working bench. They do different jobs.

Regex for speed, rubric skill for judgment.

My QA process is defined in a canonical spec document with two layers: a compliance checklist (brand conformance, copy rules, source accuracy, structure) and a value rubric (seven dimensions scored 1 to 5). The two layers have different shapes. The checklist is mostly regex-checkable: banned phrases, exposed scaffold labels, placeholder links, voice violations. The rubric requires reading the whole piece and forming a judgment. So they are wired as different artifacts:

The regex layer catches cheap violations on every save so they never reach the deep pass. The judgment layer grounds every score in the spec verbatim and refuses a SHIP verdict while any blocker is live. When designing a QA system, separate the checks that can be regex from the checks that need judgment, and wire them as a hook and a skill respectively.

One assistant became a staff. Two frictions forced it.

The April version of this document describes an instrument: one Claude, one context, wired to a filesystem. The July version describes an organization. Two frictions in the single-context model drove the change.

Posture collision. The context that drafts a plan is a poor critic of that plan. Ask one assistant to be strategist, accountant, lawyer, and skeptic on the same question and you get an average of the four, weighted toward agreement. Separate contexts with separate charters fix this; the agent who argues against a decision never helped write it.

Work with no session. A daily opportunity hunt needs to run at 6:40 on a Tuesday regardless of what I am doing. Skills fire when I talk, hooks fire on harness events, and neither fires when the clock does. Scheduled tasks close that gap.

An agent, in Claude Code terms, is a markdown file: a role description, what she optimizes for, and a tool allowlist. Most of mine are about a page. Hiring a new advisor costs one file, so the roster grows to fit the work instead of the work bending to fit one generalist.

An agent costs one markdown file. At that price, you staff for the work you actually have.

One executive, five units, thirteen seats.

The staff is organized as mission-shaped teams, not a reporting tree: each unit exists for one mission (my attention, decisions, one relationship, the machine, my operations). I am the only executive. Every seat advises, drafts, or maintains; none decides.

Two seats are deliberately not agent files. The chief of staff is the main loop playing a role through a skill, because the job needs the whole session's context. Avery is a skill plus a charter folder, because his work lives in email and calendar rather than analysis.

The roster is governed by wave discipline. Wave 2 (an ideator seat, a household CFO, a whole-life promotion of the values seat) is queued behind a two-week trial with an evidence bar and a default of no. Two seats were evaluated and rejected: a standing HR agent, because ad-hoc expert spawning already covers it, and per-client account teams, because a client earns a team only when the relationship is multi-threaded, political, and high-volume.

Nine rules that decide what gets built. They came before the seats.

The org chart is the output. These rules are the input; every seat in §10 either satisfied them or did not get built.

• Standing vs spawnedA standing agent must have recurring workload and a written retirement condition. Everything else is spawned for the task and discarded. This is the rule that keeps eleven from becoming forty.
• One executiveAgents carry perspective and labor, never authority. The ceiling everywhere is a recommendation.
• Mission-shaped teamsSeats form around a mission (a decision, a relationship, the machine, my operations), not a reporting tree. When the mission ends, the team retires.
• One writer per graphAdvisory seats get read-only tools. Each knowledge graph has exactly one writer, so every reader can trust the state.
• Verifier, not debaterCheckable questions get an auditor; judgment questions get a debate. The systems team has no contrarian because system state is a fact, not a position.
• Stage, then approveAnything that runs unattended writes to a staging folder, a queue, or a draft. Nothing merges to canonical files or leaves the machine without sign-off.
• One door, no chasingThe staff never asks me for status. Current state enters through the dump protocol (§17), and a fresh dump outranks every file on disk.
• Evidence protocolEvery claim an agent makes about system state quotes the command and output that produced it, and no maintenance report reaches me as fact until the auditor passes it (§13).
• Waves, not sprawlNew seats enter in waves, behind a trial period and a measurable evidence bar, with a default answer of no.

The board debates decisions. The account team manages one relationship.

The strategy board is convened by /board: the skill reads the decision on the table, routes it to the seats whose lens applies, runs the debate, and lands one recommendation with the disagreements shown. Big calls get all five seats; a pricing question might get the CFO and the contrarian only. The design decision worth copying is the contrarian: red-teaming a plan is something everyone intends and no one remembers under deadline, and a permanent seat removes the remembering.

The account team applies the same convening pattern to one high-stakes relationship, over its dedicated graph. Three advisors read; the context gatherer alone writes, sweeping Gmail, Drive, and Calendar and rewriting the graph so the team works from current state. It is the discipline a data team applies to a warehouse, applied to a folder of markdown files: because exactly one agent writes, every reader can trust the state.

The pattern generalizes to any relationship that clears the bar in §10: multi-threaded, political, high-volume. The graph holds the state, the gatherer owns the state, the advisors consume it.

The fixer never certifies the fix. Week one proved why.

Two incidents shaped this unit. On July 6 a cleanup pass found the SessionStart hook had been failing silently: MANIFEST.md was missing from the Brain, and every session for some period had loaded without its routing table. No alarm fired; the manifest had to be reconstructed from the live folder structure. The systems team was built two days later: an engineer who fixes broken plumbing (anything new is propose-only), and a read-only auditor who verifies claims against live state and reports to me, not to the engineer.

On its first day of operation the design paid for itself. Asked to diagnose two pipelines, the engineer returned a complete, confident, fabricated report: nonexistent paths, invented log entries, zero tools actually run. The auditor's claim-verification pass failed all five claims. The real state, checked directly afterward, was mostly healthy.

Three standing rules came out of that night. Every engineer claim quotes the command and its output, and "not found" is the required answer when something cannot be located. The auditor checks primary records (scheduler state, pipeline cursors) rather than inferring health from a quiet output folder. And no maintenance report reaches me as fact before the auditor passes it. A CIO will recognize the first half of this shape: change and audit are separate roles because incentives differ. The second half is specific to language models: an agent can confabulate a plausible report, so verification cannot be a step the same agent performs. It has to be a different agent with different tools.

The machine has a mechanic and an inspector, and the inspector caught the mechanic inventing a repair on day one.

An EA with a charter file, and four jobs that run on cron.

Avery is the digital EA: his own folder, a charter he reads before acting, a threads file for open commitments, a log, a briefs archive, a drafts folder, and his own address for operational email. He drafts; he never sends. The charter is the design decision worth copying: sessions come and go, the charter persists, and one file fixes his voice, his boundaries, and his standing duties.

• Morning briefWeekdays 7:00. Avery drafts the day: calendar, inbox triage, industry news. Lands as a Gmail draft, not a sent message.
• Weekly briefSundays 18:00. What moved, what is stuck, revenue, decisions owed, what to protect this week.
• Opportunity huntWeekdays 6:40. Scores new RFP and contract opportunities against a criteria file, dedupes against a ledger of everything already seen, and pre-drafts the promising ones into a staging folder.
• Proof compoundingSundays 15:00. Distills the week's session transcripts and stages proof, product, and book candidates for review (§19).

All four follow the stage-then-approve rule from §11: digests to a staging folder, candidates to a queue, briefs as drafts. Nothing merges and nothing leaves the machine without sign-off. That is what makes it safe to let the system run at 6:40 a.m. without me.

Short sessions, closed by a triage ritual, restarted cleanly.

Most Claude Code users I know run long sessions. I do the opposite: short sessions, restarted aggressively, sometimes three or four times in a working afternoon. The reason is memory hygiene. Long sessions drift; context bloats, facts get restated inconsistently, and by hour three Claude is working off a slightly wrong version of what I said in hour one. Short sessions force distillation: whatever I have learned or decided has to be crisp to survive the restart.

Short sessions only work if nothing worth keeping is lost between them. That requires a clean loading handshake at session start (§16), a push channel for current truth (§17), and a close-out ritual at session end (§18). This part describes all three, plus the mining pass that runs over the transcripts afterward (§19).

  SESSION START
      │
      ├──▶ MEMORY.md auto-loads          # Claude Code default
      └──▶ MANIFEST.md auto-injects      # load-manifest SessionStart hook
      │
  WORKING SESSION                    # kept short for memory hygiene
      │
      ├──▶ "dump:" routes current truth  # intake door, any session
      ├──▶ qa-lint fires on every save   # PostToolUse regex hook
      └──▶ skills route by vocabulary    # book-reference, qa, board, ...
      │
  /retire                            # triage and route nuggets to home files
      │
  RESTART                            # clean context, updated memory
      │
      ▼
  SESSION START                      # the loop continues

A hand-curated routing table, injected unconditionally at start.

The MANIFEST.md file at the root of the Brain is the table of contents for the knowledge system. It lists every use case I regularly work on and, for each one, the files to load. It is hand-curated because the intent lives in the curation: a rule like "when working on accounts, always load the four shared prospect-graph files together" is a judgment call the filesystem cannot know on its own.

Early in the design I assumed I would write a hook that pattern-matches the prompt for keywords and injects the MANIFEST only on a match. I got thirty triggers in and realized they would rot the moment I added a new partner or initiative. So I inverted the design: the hook loads the MANIFEST unconditionally, every session. It costs about 3.5 KB of context. It eliminates an entire class of "I forgot to load it" friction, and there is no trigger list to maintain.

#!/bin/bash
# load-manifest.sh · SessionStart hook
# Unconditionally injects MANIFEST.md at every session start.
# Loud failure if the file is missing.

set -uo pipefail
MANIFEST="$HOME/Desktop/RBD Brain/MANIFEST.md"

if [ ! -f "$MANIFEST" ]; then
  echo "load-manifest ERROR: MANIFEST.md not found" >&2
  exit 2
fi

MTIME=$(stat -f '%Sm' -t '%Y-%m-%d %H:%M' "$MANIFEST")

python3 - "$MANIFEST" "$MTIME" <<'PY'
import json, sys
path, mtime = sys.argv[1], sys.argv[2]
content = open(path).read()
wrapper = f"""# MANIFEST.md (auto-loaded by load-manifest hook)
Source: {path}
Last modified: {mtime}

---

{content}
"""
print(json.dumps({
    "hookSpecificOutput": {
        "hookEventName": "SessionStart",
        "additionalContext": wrapper,
    }
}))
PY

The generalizable principle: before you build a trigger list, ask whether you could just load the thing every session. Always-load beats conditional-load for small files.

The dump protocol: how current truth enters a system that is not allowed to ask.

The no-chase rule creates a freshness problem: if the staff can never ask me for status, the files go stale on their own schedule. The dump protocol, designed July 8, is the answer: a push-only intake with exactly two channels, a fixed routing table, and a receipt.

• Channel 1 · liveI say "dump:" in any session, typed or dictated, and talk raw: statuses, decisions, ideas, vents, half sentences. The skill never critiques the format. Raw is the design.
• Channel 2 · emailI email myself with a subject starting "Dump" from anywhere. Every intake or chief-of-staff invocation first sweeps for unprocessed dump emails against a processed-dump log, so nothing is read twice or missed.

Each dump is parsed into typed nuggets, relative dates converted to absolute, and routed:

Four rules make it dependable. The dump is sovereign: where it contradicts a file, the file is corrected and the correction noted. Clarifying questions are batched once, three maximum, never dripped. The receipt is one line per nugget: what it was, where it went. And the dump informs but never launches work; I direct, it updates.

Scan the live folder architecture at every invocation, then route nuggets to their homes.

The close-out ritual at the end of every session is a skill called retire. Its job is to read the session, extract every reusable nugget, and route each one to its correct existing home. Feedback rules go to the memory shards. QA failures go to the error log. Process improvements go to the nearest runbook. New prospects go to the prospect graph. Ephemeral content gets dropped.

Two design decisions matter. First, retire does not write a session dump: a dated everything-that-happened file is not loadable in a future session, so the knowledge never gets reused. Routing into files that are already part of the load path is the whole point. Second, classification is driven by the live folder architecture, not a hardcoded taxonomy. Every invocation starts by scanning the actual folders to build a fresh routing map. If I added a partner subfolder last week, retire discovers it. There is no taxonomy file to update; the filesystem is the taxonomy.

Taxonomies cached in code rot. Taxonomies discovered from the filesystem do not. If you can scan, scan.

Retire works as a confirmable diff: it proposes a routing table with one row per nugget and waits for approval, with a second confirm on any write to a file that has readers beyond my session. At the end it writes a one-page breadcrumb manifest to the Brain's sessions folder showing what went where. The manifest is a pointer, not a copy.

The system compounds its own operating history.

Every Claude Code session leaves a JSONL transcript; 91 are indexed in the Brain. A 40-line Python distiller strips tool calls and system noise, which is more than 90 percent of the bytes, and keeps the asks and the prose. The weekly compounding pass reads new sessions and stages three kinds of candidates: proof points for the client evidence base, product candidates, and material for the next book. Each waits in a queue for approval before it merges anywhere.

This closes a loop the April version left open. The knowledge OS began as a way to give Claude my knowledge. It now also harvests what four months of working sessions produced, which would otherwise sit unread in multi-megabyte log files.

The big tempting build that I deliberately did not do.

Every few weeks I talk myself into the idea of turning my whole computer into a local NotebookLM: an 8-layer system that indexes every file, extracts entities, builds a graph layer, exposes a query UI, and makes the whole machine queryable. I scoped this build multiple times. I even named it: Personal Knowledge Atlas.

I deliberately did not build it. First, the curated graphs already are what an Atlas would produce, lossily; an indexer crawling the Brain would make a less precise copy of a thing I already have in high fidelity. Second, the querying problem is already solved: Claude Code reads any file I point it at. What I needed was better source selection, which the MANIFEST and its hook provide. Third, the unstructured material that could benefit from indexing is a small slice of the Desktop, queried rarely. A heavy system for rare queries is bad return on investment.

The reframe: a narrow indexer for the dumping-ground folders, plus a well-maintained MANIFEST, captures 90% of the value at 10% of the work. This is the most important meta-lesson from four months of building tooling around Claude Code. The impressive system is usually wrong. Measure friction in the transcripts, not in the feature list, and build only what the friction tells you to build.

Build anti-Atlases. The small thing that works beats the big thing that impresses.