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

The operating system of a firm, running inside a coding tool.

Every decision in this document follows from one choice made first: what kind of tool am I actually running. Most people who open Claude Code are running a coding tool. I am running the operating system of a firm.

If you set Claude Code up the way a programmer would, you get something wired for the things programmers care about: testing code, tracking changes to a project, running automated builds. None of that touches what I actually spend my days doing. I spend my days reading and writing: research, drafts, contracts, bids, follow-up emails, the same raw material any consulting or professional-services firm runs on. The friction I actually feel is never a broken piece of software. It is losing track of which version of an argument I already sent a client, or forgetting, three working sessions later, which prospect said what.

So I wired it the other way. Instead of tools for testing code, I built rules for loading the right file at the right moment, for catching a document before it goes out sounding like nobody in particular wrote it, for keeping a set of notes current instead of stale. Everything after this paragraph is that second kind of wiring, four months further along than the last time I wrote it down.

The tool follows whatever you decide it is for. Decide that first.

Four colors, four jobs. The color is what tells the rules apart, not the folder name.

On my computer, everything lives inside ordinary folders, the way it does on anyone's. What makes mine work as a system is a habit that costs nothing: every folder that actually matters gets a color, using the plain colored labels any Mac folder can carry. Four colors, four jobs.

• 🔴 The BrainThe folder holding the firm's actual knowledge: the frameworks from my book, the method for editing a chapter, the files my advisory board reads before a meeting. Claude checks here before it checks anywhere else.
• 🟢 The SiteThe version of my website that is actually live, wired straight to the internet. Save a change here, and it becomes public within about thirty seconds. Every write to this folder is consequential.
• 🔵 StrategyWhere I work on the business instead of in it: revenue plans, partnership ideas, the funnel I am building. One file inside always says, in plain terms, what is live right now and which file to open next.
• 🟡 MarketingAnything meant to go out to everyone: brochures, the newsletter, framework diagrams, anything published.

Everything else, left uncolored, is scratch paper, reference material, or something old enough not to matter day to day. The color is the exception, and that is the entire point: when almost nothing is colored, the handful of things that are stand out immediately, both to me and to Claude.

I also keep a small set of shortcuts on the Desktop, one click from the files I touch most, and I make each one a proper Mac alias rather than a different kind of shortcut called a symlink, which always points at wherever its target currently lives even after the target changes name or moves, because an alias can carry a color and a symlink cannot. One shortcut stays a symlink on purpose, since the file behind it changes every single day and a color-carrying alias would freeze on day one and never say so. Any file important enough to earn a shortcut gets one the day it is created, not later, because a shortcut nobody remembered to add might as well not exist.

None of this teaches Claude a policy by explaining it in a paragraph, the way I am explaining it to you right now. It teaches the plain software running underneath Claude, the part that enforces a rule automatically rather than relying on Claude to remember it (see the hooks in §07), to treat colored folders differently by rule. If you want two kinds of files handled two different ways, put them in two different folders and build the rule around the folder. Do not just explain the policy and hope it sticks.

A long document does not survive a long conversation. A one-page map does.

Early on, I tried the obvious thing: hand Claude a 300-page manuscript, a slide deck, a research file on a prospect, and just ask questions. It worked for about ten exchanges. Then Claude's attention would drift, I could no longer tell whether a definition I was reading came from my actual book or from Claude silently filling a gap on its own, and the conversation grew less reliable the longer it ran.

The fix is a format I now use for almost everything I want Claude to understand at a glance: a knowledge graph. Despite the name, it is nothing more exotic than a short, plain-text file, usually smaller than a phone photo, laid out like a simple map. The names of the things that matter, listed first. How those things connect to each other, listed next. A little detail on each one, at the bottom. A whole knowledge graph fits in a single glance, the way a subway map does, instead of requiring Claude to dig through a stack of documents the way a folder of PDFs does.

Six of these existed in April. Eleven by July. Twelve today. The newest one covers my actual relationships rather than sales targets: who I know, tracked by hand through a small private tool, with a weekly nudge naming who I have not talked to in a while.

The other eleven cover: the ideas and frameworks from my book and how they connect to each other; my sales pipeline and every account inside it; the research products published on my website; the method for editing a chapter of the book (the finished manuscript itself moved elsewhere, see §05); the working files for my advisory board; the recipe for building a new map like this one, plus the checklist my published work has to pass before it goes live; my actual client work, with every credibility claim traced back to where it actually came from; the record of one particularly important business relationship; the daily search for new bids and grants worth chasing; my own priorities and the decisions I am currently weighing; and a one-page summary of every working session I have closed out, each one a pointer to where the real information lives rather than a copy of it.

Every one of these files stays small on purpose, and I write and edit them by hand. If you have a body of knowledge you refer to constantly, a client roster, a set of house rules, a map of who owes whom what, shape it as one of these small files instead of a folder of documents. A file small enough to read in one breath becomes part of what Claude is actually holding in mind for the whole conversation. A folder Claude has to dig through becomes something it keeps losing track of. Match the size of what you hand over to what fits in one breath, not to how big the subject actually is.

A file you can hand over in one breath stays in Claude's mind for the whole conversation. A folder you have to go digging through becomes something Claude keeps losing track of. Size the file to the breath, not to the topic.

Four kinds of note, one table of contents, read automatically before you say a word.

Claude Code comes with a built-in memory: a single file it reads automatically at the very start of every sitting, before you have typed anything. Most people leave that as one growing file. I use it differently. My memory file works as a table of contents rather than the notes themselves: one short line per note, each line pointing at a separate small file holding the actual fact.

• Facts about meWho I am, how I work. These barely change.
• Corrections"Never phrase it that way." "Always check this before sending." This is the accumulated judgment of the whole practice, and it should never be allowed to fade, because it is expensive to relearn.
• Whatever's live nowA deadline, a proposal in progress, a deal moving. These go stale fast and need regular weeding.
• Outside referencesPointers to outside systems and settled facts about tools. These only change when the outside thing itself changes.

The whole registry has more than doubled again since the last time I counted: 257 separate notes now, up from 118 in July and roughly two dozen in April. More than two out of every three of them are corrections, accumulated judgment about how to work, rather than facts about the world outside. That ratio comes directly from a closing ritual I run at the end of every single working session (§21), which asks, every single time, what was actually learned that is worth keeping.

Why split one big file into hundreds of small ones? A single growing file eventually becomes too important to touch. You stop editing it because any change feels risky, and it just keeps getting heavier. A note broken into small pieces is safer to update, change one small file, add one line to the table of contents, and cheaper for Claude to read. The tradeoff is that the table of contents itself now needs upkeep, which is one reason this whole layer of notes gets its own separate backup, described in §28.

320 pages, turned into a skill in an hour. The manuscript itself finished since.

My book is 320 pages. It used to sit on my Desktop as a plain PDF, and every time I wanted Claude to quote it accurately or check a framework's exact name, I attached the whole file to the conversation. By the second hour of a working session, Claude's attention would drift, and I could no longer tell whether a definition it gave me came from the actual manuscript or from Claude's own best guess at what my book probably said.

The fix was to stop treating the book as something you attach whole and start treating it as something you can ask questions of, the same knowledge-graph idea from §03 applied to a much longer text. I pulled the full text out of the manuscript into one plain file with its structure marked, built an index of which chapter covers which range, pulled every glossary term into its own short reference, and set up a skill (§06) that reads the right slice depending on the question. Ask about a concept, and it loads the definitions. Ask where something appears, and it loads the chapter index. Ask for an exact quote, and it searches the full text and hands back the precise line, so a citation is never a guess.

Since the last time I wrote this, the manuscript itself actually finished. Two things followed. First, every time a finished manuscript gets even a small correction, the whole extraction has to be redone, so the reference folder now keeps dated, clearly marked older copies alongside the current one rather than pretending the current copy is permanent. Second, a new file joined the set: the actual jacket copy, the words that describe the book on its own back cover, now stands as the one true answer to "what is this book about" in any pitch, media outreach, or social post. A chapter's argument and the book's back-cover pitch are not interchangeable, and confusing them is a different kind of mistake than misquoting a definition. A wrong definition is a research error. A wrong premise in outreach is a positioning error. Each now has its own dedicated, correct answer to reach for.

The lesson generalizes past books. If you have a long document you cite constantly, do not hand it over whole. Pull the useful pieces out into their own small files. And when the same document gets cited for two different jobs, once for what it actually says, once for how you pitch it to someone who has not read it, give each job its own separate, correct answer instead of asking one summary to cover both.

Twenty-nine skills. Here is what every one of them actually does, and why it is built that way.

Twenty-nine separate skills exist in this practice right now. A skill, in plain terms, is a set of instructions Claude follows the moment you say certain words. You do not open a menu and pick "run the newsletter skill." You talk the way you already talk: "draft an email to," "what's on my plate," "ask the board." Claude reads a short description of every skill at the start of each sitting and silently checks whether what you just said matches one. If it does, that skill's instructions take over for the rest of the answer. Nobody clicks anything. Your own vocabulary is the trigger.

That single design fact explains everything else in this section. A skill file is not a program in the way you might picture a program: no buttons, no menus, nothing to install. It is closer to a job description with a trigger phrase stapled to the front, plus, for the more involved skills, a small folder of reference material the job description points to when it needs real detail. The job description stays short and readable. The detail lives separately, so it can be updated without touching the part Claude actually reads to decide whether to use it at all.

The library has grown fast: six skills in April, eighteen in July, twenty-nine now. What follows is a full walk through every one of them, grouped not by what kind of file each one technically is, which is how the earlier editions of this document organized them, but by what you are actually doing when you reach for it: starting the day, taking in information, making a decision, writing something, selling something, closing the day, and keeping the whole machine honest. For each one: its plain name, the words that call it up, what happens next in plain steps, and the reasoning behind why it exists in the shape it does, because that reasoning is the actual product here, not the file itself.

The first two questions of any working day: what actually deserves my attention, and what is already on my calendar that I have not looked at yet.

Nothing in this system stays current on its own. Something has to bring today's actual truth in, and something has to answer questions accurately when you ask.

A genuine business decision, the kind with real money or real exposure attached, is where a single mind is the weakest judge of its own plan.

The board handles the big calls: whether to do a thing at all, whether to take on a piece of work, whether a deal is worth the exposure it carries. Smaller, faster decisions never need a full board debate; the chief of staff from the first group already holds a running queue for those, and only escalates the genuinely cross-cutting ones up to the board.

Different writing jobs need genuinely different registers, and getting the register wrong is its own kind of mistake, separate from getting the facts wrong.

Turning something you own into something someone pays for, whether that is a piece of consulting work, a bid, a grant, or an offer on the website.

A working session ends, and whatever was learned either gets written down properly right now, or it evaporates the moment the conversation closes.

A separate set of skills whose only job is checking the rest of the operation, including checking whether the operation itself is even being used well.

Every one of the more substantial skills above is actually built the same simple way underneath: one short file Claude reads to decide when to use it and what to do, plus, for the ones that need real depth, a small folder of separate reference files it only opens once it has already decided to act. The short file stays about a page long, on purpose, so it stays fast to read and easy to keep current. Here is what that looks like for the book skill from §05:

book-reference/
├── the router file       # decides which reference to open, and when
└── references/
    ├── frameworks.md      # definitions and how they connect (concept questions)
    ├── chapters.md        # which chapter covers what (location questions)
    ├── promo.md           # the actual approved jacket copy, kept separate from chapter arguments
    └── book.txt           # the full extracted text (exact-quote questions)

All twenty-nine skills above share one thing in common: none of them fire unless Claude first recognizes that your words match one. That is exactly the limitation the next section exists to work around.

Rules that hold no matter what, because a plain program enforces them, not Claude's own attention.

A skill only works if Claude actually recognizes that it should apply, which means a skill is only as reliable as Claude's own attention in that moment. For anything that has to hold no matter what, whether or not Claude happens to notice, this system uses a different kind of rule: a hook.

A hook is a rule enforced by the plain computer program running underneath Claude, the part of Claude Code that is not itself a thinking model at all, just ordinary software executing a fixed instruction the instant something specific happens. A skill fires because your words matched a description. A hook fires because an event happened: a new working session started, a file just got saved. Nothing about Claude's judgment is involved, which is exactly the point: a hook holds even in a long, drifting conversation where a rule buried in yesterday's instructions might otherwise be forgotten.

Two of these were wired the last time I wrote this. Four are wired now, covering three separate moments:

• Session startTwo things happen automatically, before you have typed a single word: the routing table described in §19 gets loaded, and a small private helper program that keeps my contacts registry current gets checked and restarted if it has silently stopped working.
• Every messageThe instant you submit each new message, a rule restates the voice standard and the file-linking rule inline, so a long session cannot drift away from either just because the original instruction has scrolled out of view.
• Every saveEvery single time a file gets saved inside one of the four colored folders from §02, a simple word-for-word check runs automatically: does this contain a banned phrase, an exposed placeholder, a broken link. It only ever warns; it never blocks the save. A human still decides what to do about the warning.

Two design choices are worth naming plainly. First, every one of these checks only runs inside the colored folders; anywhere else on the computer, it stays completely silent, because a rule meant for published, client-facing work has no business slowing down a scratch file nobody will ever see. Second, a warning, never a block: the check tells you something is wrong, it never undoes the save or stops you from proceeding, because the judgment about whether a warning actually matters in this specific case still belongs to a person, not to the check.

One more small but real lesson came out of a mistake: a single number that several of these checks all depended on had been typed separately into two different places, the two copies drifted apart without either of them announcing it, and a routing file started silently getting cut short under the wrong assumption until someone finally noticed and went looking for why. The fix, now standing practice, is that any number more than one rule depends on lives in exactly one place, and every rule that needs it points at that one place instead of keeping its own copy.

The rule to actually take from this: if something must hold true no matter what, whether or not Claude remembers to apply it, build it as an automatic check, not as an instruction you simply hope gets followed. And if two different checks would ever need the same number or the same fact, give that fact exactly one home.

A fast check on every save, a slow check on request. Both, never just one.

My actual quality standard for anything published is written down as one document with two different kinds of check inside it, and both have to pass before anything goes live.

The fast check catches the cheap, embarrassing mistakes before they ever reach the slow check, so the slow check can spend its whole attention on the harder question: is this piece actually good, not just clear of typos. A bid or a formal proposal gets a third layer past both of these (§14), because "is this well written" is a genuinely different question from "will a buyer's scoring committee actually score this well" or "does every number in here trace back to where it came from."

Two frictions forced it. Neither has gone away, and the staff kept growing after.

Nothing about the underlying idea has changed since I first wrote this down; only its scale has. Two specific frustrations, both real and both recurring, are what actually turned one assistant into a whole staff.

The first. The same mind that just drafted a plan makes a genuinely poor critic of that same plan. Ask one conversation to be strategist, accountant, lawyer, and skeptic on the same question, and you get something close to an average of all four opinions, leaning toward whatever answer you were already hoping for. Separate advisors, each with a separate job and no hand in writing the plan, actually fix this. The one built specifically to argue against a decision never helped draft it in the first place.

The second. Some work genuinely has to happen with nobody watching. A daily search for new business opportunities needs to run at a fixed time on a fixed morning, whether or not you happen to be at your keyboard that hour. A skill only fires because you said something; a hook only fires because a specific event happened inside the software. Neither one fires just because the clock reached a certain time. A job set to run on its own schedule closes that specific gap, and there are more of these self-running jobs now than there were even in July.

Here is what makes hiring cheap in this system: an agent, in plain terms, is nothing more than a one-page job description for an advisor: a role, what it is optimizing for, and a fixed list of what it is actually allowed to touch. Most of mine really are about a page long. Because hiring a new advisor costs one short file rather than a whole new piece of software, the roster can grow to fit whatever work actually shows up, instead of forcing all of it through one generalist who is decent at everything and truly excellent at nothing. Since July, four kinds of work that used to land on me alone, under time pressure, now have a standing advisor built specifically for them: go-to-market decisions, agreement review, bid evaluation, and a gatekeeper that checks any new addition to the staff itself before it gets built.

Hiring one more advisor costs one short file. At that price, you staff for the work you actually have, and the work kept arriving.

One owner, ten teams, twenty-five advisors.

The staff is still organized around missions, not a reporting chain: each team exists because one specific job needs doing, not because someone needs a title. I am still the only person who actually decides anything. Every advisor drafts, checks, or argues; none of them acts on its own authority. Two of the ten teams below are not even separate advisor files at all: the chief of staff and the marketing and product department are both just Claude itself, in the main conversation, temporarily playing a convening role, because both jobs genuinely need the whole conversation's context rather than one narrow lens.

Every advisor above answers to the same nine rules in §11. None of the four brand-new teams got built because a team of that shape sounded impressive on paper. Each one answers a real, recurring question I used to answer alone, under time pressure, without anyone in the room built specifically to ask the part of the question I am worst at remembering to ask myself.

These rules decide who gets hired. They came before the seats, and now one of them has real teeth.

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

• Standing vs. one-offAn advisor only becomes a permanent hire if the work actually recurs and there is a written condition for when it gets retired. Everything else gets brought in for one task and let go afterward. This is the rule that keeps twenty-five advisors from silently becoming eighty.
• One ownerAdvisors carry judgment and labor, never authority. The most any of them ever produces is a recommendation.
• Missions, not a hierarchyAdvisors group around a decision, a relationship, an offer, a document, or the machine itself, never around a reporting chain. When the mission ends, the team retires with it.
• One writer per fileAn advisor that only advises gets read-only access. Every shared file that matters has exactly one advisor allowed to actually change it, so everyone else reading it can trust what it says.
• A checker, not a debater, for factsA question with a checkable right answer gets a checker. A question of judgment gets a genuine debate. The systems team, for example, has no advisor built to argue against it, because whether a system is actually working is a fact, not an opinion.
• Draft first, approve afterAnything that runs on its own writes to a holding area, a queue, or a draft. Nothing becomes final and nothing leaves the building without your sign-off, and the jobs added since July that actually send things now enforce this with a hard stop, not just good intentions (§25).
• One door, no chasingThe staff never asks you for a status update. Current truth only enters through the daily dump (§20), and whatever you just said always outranks whatever an old file says.
• Show your workAny advisor claiming something about the system has to show the actual check it ran and what it actually found, and no maintenance report reaches you as settled fact until a separate checker has confirmed it (§15).
• Grow in waves, default to noNew advisors get added in small batches, each one on trial, each one required to clear a real bar of evidence, with "no" as the standing default answer. The four new teams above all cleared that bar on an actual recurring question, not a hypothetical one.

The board debates whether. The department builds what, and sells it.

The strategy board, called up by saying "/board," takes whatever decision is on the table, sends it to whichever advisors actually hold the relevant lens, runs the real debate between them, and lands on one recommendation with the disagreement shown rather than smoothed over. A truly big call gets all six advisors; a narrow pricing question might only need the money advisor and the one built to argue against it. Since the last time I wrote this, a sixth seat joined: a product advisor whose whole lens is packaging, pricing, and how an offer actually reaches a buyer without paid advertising. It joined because the question "should this even be its own product" kept landing by default on the strategy advisor or the money advisor, and neither lens actually fit that specific question.

The marketing and product department, called up by saying "/gtm," answers a different kind of question entirely: not whether to build something, but how to make something that already got a yes actually sell. Four advisors report to a fifth role that Claude itself plays directly, the same pattern as the chief of staff: who the buyer actually is, the sequence and hook of the sales funnel, the page and the collateral, and the pricing structure. The board decides go or no-go. The department never does. If the real question is "should I even take this on," it goes to the board. If the real question is "why isn't this page converting," it goes to the department. Keeping that boundary explicit is exactly what stops the two teams from giving you contradictory advice on the same decision from two different rooms.

One relationship, one dedicated map, one writer, several advisors.

The pattern here has not changed shape since the last time I wrote this, though it gained one more advisor. One especially important business relationship gets its own dedicated team and its own dedicated map of who said what and when, the same convening pattern the board uses, but aimed at a single high-stakes relationship instead of a general decision. Three advisors read that map. Exactly one advisor is allowed to write to it, sweeping email, files, and calendar and keeping the map current, because when exactly one advisor writes and everyone else only reads, every reader can actually trust what the map says.

The new addition since July is a fourth advisor whose lens is neither strategic nor tactical: a check on whether I am actually holding a charged moment clearly, rather than reacting from resentment or fear, run whenever the relationship carries real emotional weight. Its existence is itself a small piece of the underlying philosophy here: not every seat a team like this needs is a business lens. Sometimes the missing seat is the one that asks whether the position you are about to take is coming from a clear place at all.

This pattern only applies to a relationship that actually clears a real bar: many threads, real political weight, real volume. A relationship earns a dedicated team; it is never handed one by default. Two other relationships were actually considered for this treatment since the last edition and both were turned down, because neither one was tangled enough to justify a whole dedicated map and a standing seat over just answering the question with a general skill whenever it actually comes up.

Two teams that exist to catch what one reader alone will not.

Both of these teams are new since the last time I wrote this, and both follow the exact same logic: a document about to become binding, or about to be submitted somewhere it cannot be taken back from, deserves more than one person reading it once. Neither team writes anything from scratch. Both read something already drafted and report back what is actually wrong with it before it leaves the building.

The legal QA team runs on any agreement, redline, or governance document before it goes out or gets signed. One advisor checks it against a standing list of your own protections. A second turns every one-sided request into a version that would genuinely benefit anyone it applied to, because a request that only helps one side gets pushed back on for that reason alone, whatever its actual merits. A third plays the other side's own lawyer, reading the document exactly the way the other party actually will. None of the three is an actual attorney, and all three say so plainly; their job is to catch what a careful, non-lawyer reading can catch, and to flag clearly the moment the honest answer is to pay a real one.

The bid review team runs over a drafted bid, RFI response, or grant application until it stops improving. One advisor reads it the way an actual member of the buyer's own scoring panel would and scores it factor by factor. A second never drafts anything at all, only ever reads coldly: checking every claim against its real source, re-adding every number in every pricing table by hand, and in a final pass, reading the whole thing the way a losing competitor's protest lawyer would, hunting specifically for grounds to challenge the outcome. A third checks the finished submission itself at the level of the actual file: is everything signed, is every required form present, does the whole package fit the buyer's stated limits. The team runs its fact-checking passes on every single bid it sees; it only runs a scoring pass where the buyer actually published something real to score against, so it never invents a scoring rubric that was never given.

Both teams exist for the same underlying reason the systems team in §15 exists: wherever a mistake is expensive and hard to take back once it is signed or submitted, whoever drafted it should never be the only reader who checks it.

The one who fixes it never certifies the fix. And now nothing gets built without a gate first.

Two things that happened before the last edition still shape how this team runs, because the lesson they taught still holds. A cleanup pass once discovered that the automatic rule loading my routing table at the start of every session had been silently failing for a stretch of time: the routing table itself had gone missing from where it should live, and every working session in that window had started without it, with no alarm going off anywhere. On the very first day the resulting two-advisor team actually operated, one advisor that fixes broken plumbing, and a separate, reads-only advisor whose only job is checking claims against what is actually true, the fixing advisor handed back a complete, confident, entirely made-up report on two jobs it had been asked to look into: invented log entries, a file location that did not exist, not one actual check run. The checking advisor's pass failed every single one of those five claims. The real state of things, checked directly, turned out to be mostly fine.

Three standing rules came out of that one night and still hold. Every claim has to show the actual check and its actual result. "I could not find it" is always an acceptable answer; a confident guess dressed up as a fact is not. And no maintenance report reaches me as settled truth until the checking advisor has actually confirmed it. What is new since July is a third advisor placed upstream of both of the other two: a gatekeeper who reviews before anything new gets built at all, not after, and whose review is mandatory, not optional, for any new advisor, skill, hook, self-running job, or any structural change like moving a whole folder of files or changing how backups work. It hands back one of three verdicts: build it, build it with changes, or do not build it, judged against a standing test for whether the thing under review would silently create a problem nobody would notice until it had already caused damage.

The three roles now divide cleanly by when they act, not just by what they check. The gatekeeper asks whether this should even be built, before a single piece of it exists. The fixer builds it and keeps it running. The checker verifies, after the fact, that what was claimed to have happened actually did happen. Anyone who has run a real organization will recognize the shape: a design review, a change process, and an audit are three genuinely different functions precisely because their incentives pull in different directions, and none of the three should ever also be one of the other two. The specific reason this matters more here than it would for a team of humans: an advisor built on a language model can hand back a complete, confident, and entirely fabricated account of work it never actually did, which means checking that work can never be a step the same advisor performs on itself. It has to be a genuinely different advisor, with different access, asking a different question, at a different point in the process.

The machine has a gatekeeper before it builds, a fixer while it runs, and a checker again after. All three are genuinely different roles.

Neither reports into a team. Both exist because the workload recurs.

Two more advisors joined the staff since the last time I wrote this, neither one reporting into any of the existing teams, because each answers a question no existing lens was actually built to ask. A security specialist, reads-only, checks both the internal operation and the published website for exposed passwords, leaked access keys, file-permission mistakes, and the specific kind of exposure a text-based operation like this one is actually vulnerable to. It reports what it finds, with the actual evidence attached, and proposes a fix. It never applies one itself, and it never touches a security setting directly, the same separation of duties that governs the systems team next door, extended to a domain that team was never built to cover.

A room coach reads call and meeting transcripts, moment by moment, and answers a narrower, more specific question than any strategic advisor is built to ask: what actually happened in that room, whether a given question was a real challenge or something else entirely, what a given move actually cost and what it actually won, and what the better move would have been. It is explicitly not for drafting a reply and not for deal strategy; both of those stay with the advisors built for them. Its whole job is coaching, after the fact, on what already happened, not deciding what happens next.

Both of these are permanent hires rather than one-off help because the actual workload behind each one recurs, which is the exact same bar every other advisor on this staff had to clear.

An assistant with a written charter, and a growing set of jobs that run on their own schedule.

Avery is still the digital assistant: his own folder, a written charter he reads before doing anything, a running list of open commitments, a log, an archive of past briefs, a drafts folder, and his own email address for operational messages. He drafts. He never sends. The written charter is still the one design choice worth copying directly: working sessions come and go, but the charter persists, and that one file alone fixes his voice, his boundaries, and his standing responsibilities.

Past Avery's own briefs, the number of jobs actually running on their own schedule has grown further. Ten of these are defined as of this writing; seven are currently active, and the other three were deliberately turned off rather than deleted, kept on record with a written note explaining why each one stopped, because a disabled job with a dated reason attached can actually be checked later, while a deleted one leaves no trace to check at all. The active set now reaches well past anything Avery himself would normally cover:

• Weekly summarySunday evening. What moved this week, what is stuck, what decision is owed, what to protect in the week ahead, with a backup run the next day in case a closed laptop at the scheduled hour would otherwise have lost the whole thing.
• Opportunity huntWeekday mornings. Scores anything new against a written set of criteria, checks it against everything already seen so nothing gets flagged twice, and drafts the promising ones into a holding folder for review.
• Weekly mining passOnce a week, on purpose with no backup run, because the material worth mining from a week of sessions is not so time-sensitive that a week's delay costs anything, while running it twice in the same week would actually cost more (§22).
• Two jobs that actually sendNew since July. Each requires a real, current signal before anything goes out at all, and each carries a second safeguard that halts the whole run automatically if the approval behind it has gone stale, so a blanket yes given three weeks ago can never be mistaken for standing permission to send today's batch.
• Nightly backupSaves the day's file changes into version history, deliberately firing more than once a day, because a job like this only actually runs while the software is open, and a script that only does real work when something has genuinely changed makes firing it extra times cheap rather than wasteful.

All of these follow the same rule from §11: draft into a holding folder, queue, or draft; approval always required before anything actually sends; never a one-time blanket yes read as standing permission for every day after. That rule is what makes it safe to let all of this run before seven in the morning with nobody watching, and it is also exactly why two of the ten jobs sit disabled rather than active: one job's entire output turned out to duplicate another's and never actually fired on its own real schedule at all, and it was simpler to trust the one that worked and retire the broken duplicate than to keep debugging a job that was redundant even on its best day.

Short sessions, closed by a real ritual, restarted clean.

Most people I know who use Claude Code run one long, sprawling conversation. I do close to the opposite: short sessions (a session is simply one sitting, one continuous conversation, however long it runs), restarted often, sometimes three or four times in a single working afternoon. The reason is straightforward. Everything Claude is holding in mind from a conversation is called its context, and a long conversation lets that context get muddy: facts get restated slightly differently each time, and by the third hour Claude may be working from a slightly wrong version of something you actually said in the first hour. A short session forces things to be written down properly before it ends, because otherwise nothing survives the restart.

Short sessions only actually work if nothing valuable gets lost between them. That requires a clean handoff at the very start of each one (§19), an open door for today's actual truth to get in (§20), and a real closing ritual at the end (§21), plus a separate job that mines everything afterward on a schedule rather than by luck (§22). This part covers all four.

  SESSION START
      │
      ├──▶ the routing table loads automatically
      └──▶ a small helper program gets checked, restarted if unhealthy
      │
  WORKING SESSION                    # kept short on purpose
      │
      ├──▶ the voice rule gets restated with every single message
      ├──▶ saying "dump:" routes whatever is actually true right now
      ├──▶ every save gets checked automatically against the written standard
      └──▶ the right skill loads itself, based on what you actually said
      │
  CLOSING OUT                        # say "/retire"
      │
      │   everything worth keeping gets routed to its permanent home
      │
  RESTART                            # a clean conversation, notes already updated
      │
      ▼
  SESSION START                      # the loop continues

A hand-curated map, loaded every single time, and its newer companion.

One file at the top of my knowledge folder acts as a routing table for the whole system. It lists every kind of work I regularly do and, for each one, exactly which files to load together. I built this one by hand, on purpose, because a rule like "whenever I am working on this kind of thing, always load these files together" is a judgment call the folders themselves have no way to know. Only I know it.

The rule that loads this table runs unconditionally, every single session, rather than only when Claude guesses it might be relevant. I actually tried the guessing approach first, a list of roughly thirty different trigger phrases, and abandoned it the moment a brand-new kind of work showed up and none of the thirty phrases matched it. Loading the whole routing table every single time costs a small amount of space in what Claude is holding in mind, and in exchange it removes an entire category of "I forgot to load the right file" mistakes completely.

A second file joined this routing layer since the last time I wrote this: the map. Where the routing table says what to read for a given kind of work, the map says where things actually live and which single file is the real authority on a given fact, and it states its own tiebreaker rule out loud: when the two files ever disagree about where something lives, the map wins, and the routing table gets corrected to match. Naming the tiebreaker in advance is what keeps a disagreement between two files from turning into an actual argument every single time it comes up (§26). The map also carries three questions that decide where any brand-new file should go at all, and these three questions generalize well past my own folders: would you ever want to keep a dated, saved second version of this file (if yes, it is a project's working material; if no, it is either a running status file or a log); who is the actual intended reader, an automated job, everyone, or one specific named person; and has anything actually touched this file in the last ninety days (if not, treat it as cold and stop worrying about it).

The lesson from before still holds: before you build a list of trigger words for when to load something, ask first whether you could simply load it every single time instead. What is genuinely new: when a second file starts answering a different question about the exact same territory, do not merge it into the first file. Give it its own separate name, and say in one plain sentence, in both files, which one wins if they ever disagree.

How today's actual truth gets in, when the staff itself is never allowed to ask.

The rule that the staff never chases you for a status update creates an obvious problem: if nobody is ever allowed to ask, every file just goes stale on its own private schedule. The daily dump is the actual fix: a one-way door in, with exactly two ways to open it, a fixed table for where each kind of thing goes, and a receipt every single time.

The first way in: you say "dump:" in any working session, out loud or typed, and just talk. Statuses, decisions, half-formed ideas, complaints with nothing to actually do about them. Nothing about the shape you say it in ever gets critiqued. Saying it raw, in whatever order it comes out, is the entire design.

The second way in: you email yourself, from anywhere, with a subject line starting with the word "Dump." Every time the daily dump or the chief of staff gets asked for anything, it first checks for any unprocessed dump emails against a log of what has already been processed, so nothing ever gets read twice and nothing ever gets missed.

Every single dump gets broken into separate pieces, with any relative date, like "next Tuesday," converted into an actual calendar date, and each piece routed somewhere specific: a status update about your actual situation goes into the current-state summary and the matching project file; a shift in priorities goes into the priorities list; a decision you already made gets logged as closed, a decision you are still weighing gets added to the open queue; a fact about an important relationship updates that relationship's map; a fact about a prospect or a client updates their file; an idea with no immediate action goes into an ideas list, dated, essentially word for word, with zero judgment attached; a piece of real client proof or a genuine win gets staged for the weekly review described in §22; feedback on how the staff itself is working updates the matching standing rule; a commitment or a scheduling item hands off to the assistant's own tracking; and a genuine feeling with no action attached does not get filed anywhere at all. It gets acknowledged, once, like a person would, and then the conversation moves on. This whole system stores facts, not feelings, on purpose.

Four rules make the whole thing dependable. Whatever you just said outranks every file on disk; if it contradicts a file, the file gets corrected and the correction gets noted. Clarifying questions, if any are genuinely needed, get asked all together, at most three, never dripped out one at a time. The receipt is exactly one line per piece: what it was, where it went. And a dump only ever informs the system; it never launches new work on its own. You still have to actually direct what happens next.

Read the actual folders fresh every time, then route each fact to its home.

The closing ritual at the end of every working session is what I call retire. Its job is to read back through the whole session, pull out anything actually worth keeping, and route each piece to the one place that already exists to hold that kind of fact. A correction becomes a standing rule. A mistake caught during a quality check becomes an entry in the error log. A process improvement gets added to the nearest instruction file. A new prospect gets added to the sales pipeline. Anything with no lasting value at all just gets dropped.

Two design choices matter here, unchanged since the last time I wrote this. First, retire deliberately does not write a dated "here is everything that happened today" file, because a file like that is not something Claude will ever automatically load in some future session; it just becomes another thing nobody reopens. Routing each fact directly into a file that is already part of what gets loaded automatically is the entire point. Second, how something gets classified is driven by scanning the actual, current folders fresh every single time, never from a hardcoded list memorized once and never revisited. If I added a brand-new team's folder just last week, retire finds it on its own, with nobody needing to update any list by hand.

A list of categories memorized once goes stale. A list rebuilt by actually looking at the real folders every single time does not. If you can look, look.

Retire works as something you actually approve, not something that happens silently: it proposes a routing table, one row per fact, and waits for you to say yes, with a second confirmation required before it changes any file other people beyond you might read. At the very end, it writes one short summary page into the notes-about-sessions folder, showing exactly what went where. That page is a pointer to where the real information lives now, never a second copy of it.

The system now compounds its own working history on its own, not just when asked.

Every single working session leaves behind a raw record of exactly what was said, called a transcript; the running index currently tracks 336 of them. A small automated tool strips out the technical noise, which turns out to be the overwhelming majority of the raw material, and keeps only the actual questions and the actual prose. This part already existed the last time I wrote this document. What did not exist yet was a standing job that runs this every single week on its own, rather than a thing I had to personally remember to go run.

This weekly job runs on a fixed schedule, deliberately with no backup run if the software happens to be closed at that exact hour, because the material worth mining is not so time-sensitive that a week's delay ever costs anything, while running it twice in the same week actually would. Each run picks up exactly where the last one left off, processes whatever sessions are new, and sorts them: anything personal, anything about internal politics of a relationship, and anything that was pure routine maintenance gets marked skipped and is never mined at all. Everything else gets read for three specific kinds of material: real proof points for client work, each one tied to a single named client, backed by an actual quote wherever possible, and rated by how confident the claim actually is rather than simply asserted as fact; ideas for a new piece of published research; and specific language or arguments that could become a piece of published content, tagged to wherever it would actually fit and stated as one clear, checkable claim.

Nothing ever merges anywhere on its own. A week that turns up real candidates writes one single dated file and sends a one-line notification. A week that turns up nothing writes no file at all, because an empty week is a genuinely good outcome here, not a failure to report. Anything still waiting for your review gets surfaced again in the weekly summary every morning until you actually clear it, so the queue reaches you on its own schedule rather than depending on you remembering to check a folder. Once you approve it, real proof entries get merged into the dated evidence file, approved product and content ideas move into a standing list for the next thing to build, and the whole processed file gets moved into an archive. The actual bar for anything surviving this process at all: it has to be defensible out loud, on the spot, if someone pushed back on it right then. An actual quote beats a paraphrase. A paraphrase gets a lower confidence rating at best. Anything invented gets nothing at all, and whenever it is genuinely unclear, the rule is to leave it out.

This closes a loop the earlier editions of this document left open. The whole system started as a way to give Claude access to what I already knew. It now also harvests, on a schedule I do not have to personally remember, what months of ordinary working sessions actually produced and would otherwise sit unread in raw transcript files nobody ever opens twice.

The tempting, impressive idea I scoped more than once and never actually built.

Every few weeks I talk myself back into the same tempting idea: turn my entire computer into one giant searchable index, a system that reads every single file I own, pulls out every name and fact, builds one giant connected map of all of it, and lets me ask it anything. I actually scoped this out more than once. I even gave it a name: the Personal Knowledge Atlas.

I deliberately never built it. First, the small hand-built maps from §03 already are what a giant automated index would produce, just with less precision; a machine crawling my whole computer would end up making a worse copy of something I already have in a better form. Second, the actual hard problem, finding the right thing to read, is already solved: Claude Code can read any file I point it at directly. What I actually needed was better judgment about which file to point it at, which the routing table and its automatic loading rule in §19 already provide. Third, the genuinely unorganized material that could benefit from a giant index is a small slice of my whole computer, and I ask it questions rarely. Building something heavy for a question I rarely ask is a poor use of the time it would take.

The actual fix: a small, narrow index for just the handful of genuinely unsorted folders, plus a well-kept routing table, delivers most of the real value for a small fraction of the actual work. This is the single most important lesson from eight months of building tools around Claude Code. The impressive-sounding system is usually the wrong answer. Measure the actual friction in your own working sessions, not in a feature list, and build only what that friction genuinely calls for.

Build the small thing that works, not the big thing that impresses. The friction in your own sessions tells you which one you actually need.

A two-role split grew a third role in front of it.

The original rule was a simple two-role split: whoever maintains the machine should never be the one who certifies that the fix actually worked. That rule paid for itself the very first night it was tested, when a maintenance report came back complete, confident, and entirely made up, and a separate, reads-only checker caught it simply by checking the actual state of things rather than trusting the report.

What changed is where the split now starts. A two-role split catches a bad fix after it has already gone out. It does nothing to stop a build that should never have been started in the first place. The addition is a gatekeeper placed before the fixer even begins: a required review for anything genuinely new, an advisor, a skill, an automatic rule, a self-running job, or any structural change to how the whole thing is laid out. The gatekeeper does not build anything and does not verify anything after the fact; its only job is to look at a proposal and say build it, build it differently, or do not build it at all, before a single piece of it exists to later need fixing or checking.

The general rule now has three parts instead of two: a gatekeeper who asks whether this should exist before it does, a builder who actually makes it and keeps it running, and a checker who confirms afterward that it genuinely does what was claimed. No single role should ever perform more than one of these three jobs, for the exact same reason the original two-role split existed: an advisor's own account of its own work is never itself evidence that the work was actually done, at any stage of the process.

A norm that now has a hard stop behind it.

The rule itself has not changed: anything that runs on its own writes to a holding folder, a queue, or a draft, and nothing becomes final and nothing leaves the building without your actual sign-off. What has changed is what happens the moment this rule gets tested by something that genuinely sends things out. Two jobs added since the last edition now send or submit things on a daily schedule with nobody watching them run, and both carry the same two safeguards. A live-check gate requires a real, current signal before anything goes out at all, so nothing fires based on old or already-answered information. A stale-approval guard halts the entire run automatically if the approval that authorized it has gone too old, so a blanket yes you gave three weeks ago can never be mistaken for standing permission to send today's batch.

The weekly mining job from §22 follows the exact same rule, applied to a job that never sends anything anywhere: candidates simply sit in a queue until you explicitly approve them, full stop, with no stale-approval guard needed at all, because nothing in that particular pipeline can act on your behalf in the first place. The real strength of this rule shows up in the fact that it needs different levels of enforcement for different levels of risk. A job that only proposes something needs an approval gate. A job that actually sends something needs that same approval gate, plus a second mechanism that actively distrusts its own last approval the longer time passes.

A number or a rule lives in exactly one place, and every reader points at it.

Two small mistakes taught the exact same lesson from two different directions. A single shared number got typed separately into two different automatic checks instead of read from one shared place; the two copies drifted apart without either announcing it, and a routing file started silently getting cut short under a wrong assumption until someone finally noticed and went looking for why. Separately, the moment a second routing file existed alongside the first one (§19), the two could, in principle, name a different location for the exact same fact, so the actual fix was to say in advance, in both files, which one wins.

The lesson generalizes well past routing files and automatic checks. Anywhere the exact same fact, number, or rule could plausibly get written down twice, pick one file to actually own it, write every other reference to it as a pointer back to that one file rather than as a restatement of its content, and if two files could ever plausibly disagree, name the tiebreaker in advance rather than after the disagreement has already happened.

Two copies of the same fact never stay identical for long. They stay identical right up until someone edits one of them and forgets the other, and afterward neither copy tells you which one that was.

Some decisions are safer made once, in advance, than argued over again under pressure.

A recurring pattern across this whole operation is a short, explicit list of things marked permanent and completely off-limits: never deleted, never even offered up as a candidate for cleanup, never suggested as a target even when doing so would technically satisfy whatever request is actually in front of an advisor at that moment. The list stays short on purpose, and its whole value is that it removes a judgment call from the exact moment it would otherwise get made badly, whether by me in a hurry or by an advisor that has no real way of knowing what a given file actually means beyond what it can literally see in that one session.

The general version of this: find the handful of things in your own setup where a wrong call would be expensive and effectively impossible to undo, put them on a standing list that every relevant advisor is told to check, and treat that list as an actual hard stop, not a strong suggestion. A rule an advisor can talk itself out of under sufficiently confident-sounding reasoning is really just a preference the advisor gets to relitigate every single time, and the day it relitigates the wrong way is the day the list would actually have mattered.

Automatic cloud copying is not a backup. It copies a mistake exactly as fast as it copies a save.

The whole knowledge layer described in Part I sits inside a folder that automatically copies itself to the cloud, which protects against a dead hard drive and genuinely nothing else. A bad edit, an accidental delete, or a script that overwrites the wrong file all get copied to the cloud just as faithfully as a good change would, and a sync log that says everything is fine is only reporting that the copying happened, not that what got copied was actually correct.

The fix generalizes well past this one setup: any knowledge layer that several advisors and skills are allowed to write into needs its own separate, versioned backup, on its own separate schedule, independent of whatever automatic cloud copying is already running underneath it. And the exact same show-your-work rule from §11 applies to the backup itself: a script that logs "ok" no matter what actually happened only proves that the script finished running, not that the backup actually succeeded. The only way to actually know a backup is real is to check the backup's own record directly, on a schedule, rather than trusting a log line that would say the exact same thing whether the day went well or the day went badly.