Concretely: the brain is a git repository of markdown files. A status file (what is happening NOW), an orientation file (what lives where), a lessons file (rules born from mistakes), a patterns file (confirmed wins), and a memory folder (one fact per file, with structured front matter so they can be typed and searched). The AI's session hooks inject the freshest slices of this at session start. A semantic search tool retrieves the rest on demand, so nothing needs to be loaded wholesale. At session end, a review pass writes new lessons. Overnight, scheduled jobs synthesize the day and refresh a daily brief that the next session start injects. Plain text plus git means everything is versioned, portable, diffable, and owned by you.

At the start of every session, read STATUS.md before doing anything.
At the end of every session, write what changed to the session log,
and add any mistake worth preventing to lessons.md as a one-line rule.

Why this works: it installs the read ritual and the write ritual in three lines. Everything else in this playbook is an elaboration of these three sentences.

Markdown gets structure without lock-in: headings become sections the AI can target, front matter carries machine-readable fields on top of human-readable text, and links between files build a knowledge graph for free. Git adds three system properties that matter at scale: an audit trail for every rule the system writes into itself (who or what wrote it, and when), a sync mechanism between machines with no server to run, and cheap branches for experiments. The production system also mirrors the same folder into an Obsidian vault, so a human can browse and edit the AI's memory visually. Same files, two readers.

mkdir my-brain && cd my-brain
git init
mkdir brain memory docs docs/session-logs
touch CLAUDE.md brain/STATUS.md brain/lessons.md brain/patterns.md

Why this works: the folder IS the product. Every advanced feature in this playbook lives inside this structure; nothing needs to be migrated later.

Mechanically it is a scheduled script (cron on any machine) that gathers inputs (recent logs, status files, key metrics), runs one AI call with the auditor prompt, and writes an HTML report to a reports folder. A second small script distills the report into the daily brief. The important engineering choice is the freshness gate: the brief only surfaces if it is younger than 48 hours. A stale brief is treated as "the job did not run", never shown as if it were today's thinking. Stale intelligence presented as fresh is worse than none.

You are an objective external auditor reviewing this operation.
You have the day's session logs, the status file, and recent
decisions below. Be direct and specific.
1. What is being missed, neglected, or assumed correct that
   deserves scrutiny?
2. What pattern in the last 7 days would worry an outsider?
3. What single question, if answered honestly, would change
   priorities tomorrow?
Write it as a short report. No praise. No hedging.

Why this works: "no praise, no hedging" plus the outsider frame breaks the AI out of assistant politeness. You want the auditor, not the cheerleader.

Dreaming is strictly read-only: it studies git history, session artifacts, and reports, and it writes only its own report. It never edits code or rules directly; anything executable it discovers becomes a proposed task for a daytime session. Evidence is gathered cheap-first (git log and status before any file reads), the time window is stated explicitly in the report, and every lesson must cite the evidence that produced it. Lessons without receipts are opinions.

Window: the last 24 hours. Evidence: git log, session logs,
and reports from that window (read-only; change nothing).
Write a morning report with exactly these sections:
## What Happened   - 3-6 bullets, each naming its evidence
## Lessons Worth Carrying Forward   - each lesson cites the
   specific event that taught it
## Research Questions for Tomorrow   - 3 questions that, if
   answered, would most improve the next 7 days
Be concrete. A lesson without evidence is an opinion; cut it.

Why this works: the fixed three-section shape makes reports comparable across weeks, and the evidence rule keeps the dream honest. This prompt is the single highest-leverage automation in the whole system.

Technically it is a local Node server rendering vanilla JS modules, one file per screen. Three architectural rules do most of the work. A registry: every module registers in one place; an unregistered module simply never renders, which makes "what exists" a queryable fact instead of folklore. A data registry: every outside data feed is declared once with its source, schedule, and freshness rule; coverage is enforced (a feed that is not classified is a failing build). Guides from facts: module documentation is regenerated nightly from the code itself (endpoints, data files, neighbors), so the docs cannot rot. None of this needs a framework; the discipline is the architecture.

// sections.js - THE single source of truth for what exists
const SECTIONS = {
  money:   { title: 'MONEY',   modules: ['cashboard', 'runway'] },
  command: { title: 'COMMAND', modules: ['today', 'action-hub'] },
  system:  { title: 'SYSTEM',  modules: ['feeds', 'nightly'] },
};
// render loop: only what is registered can appear
// adding a module = one line here + one file in modules/
// a module not in this object DOES NOT EXIST

Why this works: every "mystery screen" and orphaned feature in a growing system traces back to registration being optional. Make the registry the only door.

The mechanism is a single JSON state file tracking each item across audit runs: first-seen date, last-seen date, status. Every audit run reconciles: an item seen again keeps aging (its DAY N badge is first-seen based), an item that stops appearing is marked auto-resolved, and a genuinely new item starts at day one (badges suppress for the first two days so the queue is not noisy with things that fix themselves). Writes are atomic (write temp file, then rename), because a state file that every audit touches will eventually be corrupted by a crash mid-write if you write in place.

{
  "items": {
    "feed-freshness:example-source": {
      "firstSeen": "2026-08-01",
      "lastSeen":  "2026-08-09",
      "status": "open",          // open | resolved | auto-resolved
      "title": "Example source has not synced in 8 days"
    }
  }
}

Why this works: age is computed, never entered. The badge that says DAY 9 is arithmetic on firstSeen, so the system cannot lie to itself about how long something has been ignored.

The guide brackets stages by role and headcount, not revenue, and that is the detail most people get wrong when they build this. It publishes no revenue numbers at all. Ours places on three axes and says which one won: headcount and the role the owner actually plays (primary), a revenue band (a proposal, yours to edit), and the free quiz result if there is one. When the axes disagree the module says so on the screen and takes the lower stage, because a stage you have not earned hands you the wrong constraint, and the wrong constraint costs a quarter.

Confidence ages. A placement is a claim with a date on it. Past 45 days it renders STALE rather than confident. Same honesty rule as everywhere else in this system: stale beats hidden, and both beat a confident wrong answer.

Where it actually bites: the morning action picker refuses any action that matches a stage anti-priority, and names the one it hit. That is the whole difference between a poster and a module. A poster tells you your stage. A module stops you doing stage six work in stage three.

The rule that keeps it honest: the free guide details three stages, the one you are in, the one before and the one after. The other seven are names only. Every section the guide does not cover is written as "name only, no guide content" and left empty. Nothing fills those in from imagination, including the AI.

Place my business on the scaling roadmap. Ask these one at a
time, and never guess an answer:
1. How many people work here, counting you, part-timers and
   contractors?
2. What job do you actually do most days: doing the work,
   training people, managing people, or managing managers?
3. What did the business bring in last month, total?
4. Have you taken the free Scaling Roadmap quiz? What stage?
5. In one sentence, what feels most broken right now?
Place me by headcount and role FIRST, the revenue band second,
the quiz third. If they disagree, say which said what and take
the LOWER stage. Write roadmap/stage.md with today's date and
the confidence. If my stage is one the guide does not detail,
write "name only, no guide content" and invent nothing. Finish
by telling me my stage, its constraint, how I graduate, and
what is off the table until then.

Why this works: five questions, three axes, and a written rule for what to do when they disagree. The rule is the part that makes it repeatable. Without it, every re-run drifts toward whichever number looked best that month.

Ours is a dashboard screen that reads live revenue evidence and reconciles it against the stage placement from Module one, then names the constraint, the next moves, and the anti-priorities. The part worth copying is its honesty states: when the evidence is thin it shows an UNVERIFIED badge instead of a confident guess, when two evidence sources disagree it says so on the screen, and a trajectory only renders once it has three months of history. A constraint finder that guesses confidently is worse than none, because you will reorganize your quarter around it.

Needle math: leads x close rate x average sale should roughly equal revenue. When the interview numbers do not reconcile, that gap is usually the first finding: the business does not know one of its own four numbers, and the constraint verdict says which one to go measure.

Interview me, one question at a time, and write the results to
roadmap/constraint.md. Never guess a number; ask me.
1. What was revenue last month, roughly?
2. How many leads (real inquiries) came in last month?
3. Of the people you quoted or pitched, what share bought?
4. What does the average sale come to?
5. How many hours a week do you personally work in the
   business, and what eats most of them?
Then: do the arithmetic out loud (leads x close rate x average
sale, next to stated revenue; if they disagree, ask why). Name
the constraint in ONE sentence, citing my numbers. Pick one:
not enough leads / not closing enough / price too low / cannot
deliver more / the owner is the bottleneck. Write the file with
three next moves and at least one anti-priority. Finish by
reading me the verdict and the first move.

Why this works: the forced-choice list keeps the verdict falsifiable, and the anti-priority line is the part you will thank yourself for in week three.

Ours is a multi-tab workspace that walks the book's framework end to end and adds an AI scan: it scores the current offer, keeps score history so changes are measurable, and files its critique next to the score. The transferable pattern is smaller than the workspace: keep the worksheet in the brain, next to your numbers. When the offer file and the constraint file live in the same folder, the morning action picker can connect them ("close rate is the weak number and the buyer-certainty rating is your lowest: today's move is on the offer").

Needle math: [LEADS] x [CLOSE %] x [$ AVG SALE] = revenue. Now raise close rate ten points and run it again. That difference is what the offer worksheet is competing for each month.

Read playbooks/offers.md and roadmap/constraint.md.
1. Which of the four ratings is lowest, and does the constraint
   verdict agree that this is where revenue is leaking?
2. Propose ONE change to the offer that attacks the lowest
   rating. Small enough to test this month. Name what number
   should move (close rate, average sale) and by roughly how much.
3. Update the Next Move line of playbooks/offers.md.
Do not propose a rebrand, a new service, or a website. One
change, one number, one month.

Why this works: the banned list at the end is doing the heavy lifting. Offer work dies by turning into a redesign project.

Ours walks the full structure (attraction offers, upsells, downsells, continuity, and a 30-day check on each) as dashboard tabs with an AI analysis lane. The transferable heart is one comparison: what a new customer is worth in the first 30 days versus what it costs to win one. When worth is not comfortably above cost, paid growth is off the table and the empty rows are the only lever that fixes it without more leads. The worksheet forces that comparison onto one page where the morning picker can see it.

Needle math: a new customer is worth [$X] in 30 days; winning one costs [$Y]. If X is less than three times Y, the next move probably lives in this file, not in ads.

Read playbooks/money-models.md and roadmap/constraint.md.
1. Which empty row would add revenue soonest, given what we
   already deliver? (An add-on we already do informally counts.)
2. Draft the second question: the exact sentence we would say
   right after a customer buys, offering that row. Plain words,
   no pressure, priced.
3. Estimate: if 3 in 10 customers said yes, what does that add
   per month? Show the arithmetic.
4. Update the Next Move line of the file.

Why this works: "the exact sentence" is the unlock. An upsell that exists as a concept never gets offered; a sentence gets said tomorrow morning.

Ours walks the book's framework as tabs with charts and an AI analysis lane. The part that transfers to a file-based build is the weekly commitment wired to the session log: the number of outreach touches or content pieces you committed to is checked at close-out like any other done-when, so lead generation stops being a mood and becomes a row in the log. When the constraint verdict says "not enough leads", the action picker reads this file first and its picks get very repetitive on purpose: volume, tracked, until the constraint moves.

Needle math: if leads doubled next month and nothing else changed, revenue would be about [$Z]. If that number does not excite you, leads are not your constraint, and this file can wait.

Read playbooks/leads.md and this week's session logs.
1. Committed volume this week vs actual (touches made, content
   shipped). State both numbers plainly.
2. Leads that arrived this week, by channel. Update the table.
3. If actual volume was under committed volume two Fridays in a
   row, tomorrow's action is pre-decided: do the volume first,
   before any other work. Write that into the Action Hub.

Why this works: the two-Fridays rule removes the negotiation. The system does not get angry, it just schedules the reps.

Ours runs the full pipeline against Alex Hormozi's published books and free public content: a backfill queue tracks what is ingested, a live board shows pipeline status, the corpus is indexed into its own search namespace, and a distilled playbook regenerates as material lands, organized into pillars with "how the thinking evolved" notes. The two-file version above is the same machine at day-one scale, and it is not a toy: the library-cites-only rule and the your-words-only rule are the entire integrity model, and they fit in two markdown files.

Needle math: count the hours you spent last month re-looking-up things you had already learned. Multiply by what your hour bills at. That is the monthly rent you pay for not having a playbook file.

Question: [the live business question]
1. Search MY history: lessons, memories, session logs.
2. Search THE PLAYBOOK: knowledge/playbook.md and its library.
3. Answer in three parts:
   - what our own history says (cite the files)
   - what the playbook says (cite the library rows)
   - your recommendation where they agree or conflict.
If they conflict, say so plainly. Do not average them into mush.

Why this works: separating "our history" from "the playbook" prevents generic advice wearing your company's name, which is the standard failure of every knowledge base.

Ours is a local web server that reads the same brain files plus integration caches, renders module views, and refreshes feeds on schedules. Two disciplines from it are worth stealing at any size. First, the module registry: a module renders only if it is registered in one central list, so the registry is the honest inventory of what the dashboard claims to show, and a half-built view can never quietly appear. Second, views never write: the server renders files, it does not become a second place where truth lives. The day you edit the dashboard instead of the source file is the day the two disagree, and screens win arguments against files by being prettier, not by being right.

Read: brain/STATUS.md, brain/daily-brief.md, roadmap/constraint.md,
actions/action-hub.md, knowledge/playbook.md, knowledge/library.md.

Write dashboard/dashboard.html: ONE self-contained file. Dark
background, large type, no internet requests, opens from disk.

Layout, top to bottom:
1. RIGHT NOW: the one action from the hub, biggest thing on the
   screen, with its why beside it.
2. THE CONSTRAINT: the verdict sentence, its date, and the
   anti-priorities in smaller gray text.
3. THE NUMBERS: revenue, leads, close rate, average sale as four
   large tiles. Show an up or down arrow ONLY when the file holds
   two dated values to compare. Never guess a direction.
4. THE BRIEF: today's morning brief, or its stale warning.
5. THE QUEUE: the action board, small, at the bottom.

Rules:
- Every tile shows its source file name and that file's date.
- A source missing or older than 48 hours renders as a gray tile
  stamped STALE. Never blank, never yesterday's number dressed
  as today's.
- No number appears on this screen that does not exist in a file.

Why this works: the STALE rule is the whole game. A dashboard that hides staleness is a prettier way to lie to yourself, and you will trust it exactly until the first morning it burns you.

This works because the memory format was designed for it: markdown files with a small front matter block and [[wiki-links]] between related facts. The division of labor is strict. The AI is the writer; Obsidian is the reader. Browse, search, and add links freely, but the front matter shape (name, description, type) is law, because the librarian parses it. Be careful with plugins that rewrite front matter or rename files: they fight your AI for ownership and the AI loses quietly. The local graph on a single memory is the underrated view: open it on any fact and you see everything the brain knows around it, which is exactly the question you ask before a decision.

Audit the brain's link graph.
1. List every file in memory/ with zero [[links]] in or out.
2. For each orphan, propose one of: the existing memory it should
   link to (add the [[link]] in both files), or deletion, with
   the reason.
3. List every [[link]] that points at a memory that does not
   exist: either write that missing memory now or remove the link.
Show me the proposed changes as a list first. Apply only what I
approve.

Why this works: a link graph only stays useful if orphans are a maintained population of zero. Ten minutes a week keeps the graph telling the truth about what the brain can actually retrieve.

We run this as a scheduled inference pass over the same one folder everything else uses. A dedicated tool such as Graphify does it with the same AI CLI you already have: it walks the corpus, infers communities, hubs, and edges, and writes the results as dated data files that the dashboard and the System Map render. A plain prompt does the same job on day one; the tool is the graduated form, exactly like every other processor in this system. Three rules keep it honest. First, it proposes, you approve: an inferred link is a hypothesis until a human accepts it, and once accepted it gets written into the memory files themselves, so the second brain absorbs what the third brain found. Second, it degrades to skip: if the pass fails, nothing downstream dies, because the third brain is a lens on the corpus, never a dependency of it. Third, its output is data with dates, so it obeys the same staleness rules as every dashboard tile. One byproduct earns its keep alone: ghost links, the [[links]] that point at notes that do not exist yet, sorted by how many notes want them. That list is literally your brain telling you the next note worth writing.

Read every file in memory/, brain/, and knowledge/. The graph
only shows links somebody wrote. Find the connections nobody
wrote. Propose:
1. COMMUNITIES: cluster the notes by what they are actually
   about, named in plain words. A cluster you cannot name is
   two topics pretending to be one.
2. HUBS: the five notes the most other notes depend on. When
   anything big changes, these get reviewed first.
3. INFERRED LINKS: pairs of notes about the same client, tool,
   or decision that never [[link]] each other. Quote the line
   in each note that proves the connection.
4. CONTRADICTIONS: two notes that cannot both be true. Name
   the pair; I decide which one is right.
For every proposal I approve: add the [[links]] to the memory
files themselves, then write dashboard/third-brain.html, a
one-page dark report of the clusters, hubs, and today's date.
The third brain proposes. Only I approve. Never add a link,
merge a note, or resolve a contradiction on your own.

Why this works: approval is the safety and the flywheel at once. Every accepted proposal becomes a real [[link]] in a real file, so next month's graph view, graph audit, and librarian all retrieve what the inference pass found. The third brain feeds the second, and the second is what every agent reads.

The two failures this standard catches are the ones that actually happen. The confident orphan: a module reading a copy or a cache that nothing updates anymore, rendering beautifully forever. The read-proof exposes it, because the quoted value carries the source's date. The read-only tourist: a module that renders the brain but never feeds it. Its write-proof section stays empty, and on the page that emptiness prints in red as a verdict, not a blank. Two disciplines from our own builds: proof pages are generated from the module's own configuration, never hand-written, or they rot into marketing. And every proof page carries the date of its last disconnect test: rename a source, watch the page go red, put it back. A check that has never been seen to fail is not yet a check.

Generate a proof page for module [NAME].
Write dashboard/proof-[NAME].html, one self-contained file, dark,
no internet requests.
1. READS: list every source file this module renders. For each,
   quote one real value read from it right now, plus the file's
   modified date.
2. WRITES: show the last 3 lines this module added to the brain
   (memory rows, log lines, hub updates), each with its timestamp.
   If there are none, print in red: READ-ONLY: this module does
   not feed the brain.
3. STATUS: green only if every read is younger than 48 hours AND
   a write exists from the last 7 days. Otherwise red, naming
   which side went quiet.
4. At the bottom, the disconnect test log: the date it was last
   run, what was renamed, what went red.
Never fabricate a value, a timestamp, or a pass.

Why this works: the READ-ONLY line in red converts a silent design flaw into a visible debt. Modules that only take from the brain and never give back are the first ones to drift from reality.

Ours renders a live graph on the dashboard server, and three laws from building it transfer at every size. Edges are derived, never drawn: the map builds itself from evidence (the Read lines inside prompts, the paths each job writes, the scheduler's entries), because a hand-maintained map starts lying within a week. One verdict pipeline: the same freshness rule the dashboard tiles use decides edge colors, computed once and consumed everywhere, because two staleness rules produce two truths and a Tuesday argument. The coverage ratchet: every file in the repo is either on the map or explicitly marked ignored, and an unknown file is a failing check, not a mystery. That last one is what keeps the map complete as the system grows; new files cannot hide.

Build the system map. Write dashboard/system-map.html: one
self-contained file, dark, no internet requests.
1. NODES: scan brain/, memory/, docs/session-logs/, prompts/,
   knowledge/, playbooks/, roadmap/, actions/, dashboard/.
   Every file is a node, grouped in columns by folder.
2. EDGES, derived only, never invented:
   - a prompt that says "Read: X" gets an edge X to that prompt.
   - a prompt that writes file Y gets an edge to Y.
   - scheduled jobs connect to the prompts they run.
3. COLOR each edge by its target's modified date: green under
   48 hours, amber under 7 days, red beyond.
4. DISCONNECTED panel: every node with no edges, every edge red
   for more than 7 days, and any [[link]] pointing at a file
   that does not exist.
5. Keep it readable without zooming: columns, straight lines,
   a legend, and the generated date in large type.
The map is a rendering. When it shows a problem, fix files and
prompts, then rerun me. Never edit the map to look healthier.

Why this works: deriving edges from the Read lines means the map and the machinery can never drift apart; the same text that instructs the AI is the text that draws the wire.

Ours wires every scheduled job into Sentry with an errors-only policy, and the kill switch is deliberately trivial: the reporting address lives in one .env line, and deleting that line turns reporting off without touching code. Slack runs through an incoming webhook with a two-lane contract: the digest lane (informational, batched, twice a day at most) and the act-now lane (rare by definition; an act-now that fires weekly is mislabeled). The rule that keeps the channel alive: a notification that does not change what you do next gets cut, because alert fatigue kills the whole channel by week two. And the deepest lesson, paid for in silence: alert on missing success, not just on errors. A job that dies silently throws nothing. Watch the time since the last successful run, and alarm when it passes twice the schedule interval.

# Slack: last line of the night job. The webhook URL lives in
# .env, never inside a script, never in git.
curl -s -X POST -H 'Content-type: application/json' \
  --data "{\"text\":\"Brief ready. Constraint: [X]. Today's
  move: [Y].\"}" "$SLACK_WEBHOOK_URL"

# Sentry: top of every scheduled script (Node shown).
const Sentry = require('@sentry/node');
if (process.env.SENTRY_DSN) {
  Sentry.init({ dsn: process.env.SENTRY_DSN });
}
# No SENTRY_DSN in .env means reporting is off.
# That one line is the kill switch.

# The watchdog rule, wherever your checks live:
# alert when (now - last SUCCESSFUL run) > 2x the schedule.
# Errors are loud. Silent death is what actually kills
# second brains.

Why this works: the two-lane contract is doing the quiet work. The day your act-now lane fires and you drop everything without hesitating, you will know the digest lane earned that trust by staying boring.

The trap this caught, first run. Ours scored six out of thirty. Not because the notes were missing. Because the search index had not been rebuilt after a few hundred new notes landed, and a stale index does not complain. It answers every question, confidently, out of the half of the vault it knows about. After a rebuild the identical thirty questions scored twenty. Same notes, same questions, same engine. The only change was that the index had caught up.

Score every engine separately, never just the total. Ours falls back through three of them. The top one was scoring five while the two beneath it scored twenty, which is the exact opposite of how a fallback ladder is supposed to behave. A single overall number would have hidden that completely, because the lower rungs were quietly covering for the broken top rung.

Two out of three is a real score, not a failure. Some of the misses will be questions where no note exists yet. Record those separately. They are a writing problem, not a search problem, and fixing search will never move them.

Help me measure whether my brain can still find things.
1. Read my session logs and memory files. Propose 30 questions
   I have actually asked or would plausibly ask, spread across
   clients, tools, decisions and past mistakes. Not trivia.
2. For each one, name the ONE note that should come back.
   If no note answers it, mark it NO NOTE EXISTS and keep it.
3. Write brain/golden-set.md: the question, the expected note,
   and a blank score column.
4. Run every question through my search. Score a hit only if
   the expected note is in the top five. Run each search engine
   SEPARATELY and record a score per engine.
5. Write today's date and the scores at the top of the file.
   Report the misses grouped into: index problem, ranking
   problem, or no note exists.
Do not change anything about how search works today. This run
is the baseline that every later change gets judged against.

Why this works: it turns retrieval from a feeling into a number, and it costs one hour. Everything else in this tab is optional until this number exists, because without it you cannot tell an improvement from a regression.

Pattern matching, not a model. This is the one people over build. There is no embedding step and no AI call anywhere in it. You have a list of known names; you scan for them; you write an edge with a type on it (mentions, depends on, supersedes, blocks). Run it after every write, or nightly if that is simpler.

The closed vocabulary is the whole trick, and it is why this works better in a business vault than in a general one. A public note-taking tool has to guess what an entity is. You do not have to guess. Your client list is a folder. Your tool names are in your config. Your module names are your filenames. Feed those in as the dictionary and precision is close to perfect for free.

What it is worth: hand typed links tend to land in the low single digits per hundred notes, because typing brackets is a chore nobody does under deadline. Extraction turns the same vault into a real graph without anyone changing how they write. The payoff is the first time you ask what touches a thing and get back eleven notes, nine of which you had forgotten.

Build the link graph for my brain without me typing links.
1. Assemble my closed vocabulary from what already exists:
   client folder names, project names, tool and integration
   names, module names, file paths. This is the dictionary.
   Do not invent entries for it.
2. Scan every note for exact matches. For each hit write one
   edge: source note, entity, edge type (mentions, depends-on,
   supersedes, blocks), and the line it was found on.
3. Write them to brain/edges.ndjson, one JSON object per line,
   rebuilt from scratch each run so it never holds stale edges.
4. Report: total edges, the top 10 most connected entities, and
   any note with ZERO edges. A note connected to nothing is
   either mis-worded or does not belong.
Use pattern matching only. No AI calls in this job, ever. If
you cannot match it literally, it is not an edge.

Why this works: the graph builds itself out of words you were already writing, so it never depends on discipline. The rule that keeps it honest is the last line: a literal match or nothing. A guessed edge is worse than a missing one, because you will believe it.

Use the cheap model here, never your main one. The job is summarizing text that was just handed over, which is the easiest thing a language model does. Paying top rates for it is how a good idea turns into a bill.

Measure the loss and say it out loud. Ours loses roughly one answer in five against reading the notes directly, and that number is why it stays opt in rather than becoming the default. Fast reads get answer mode. Questions where being wrong costs a day still get the notes. Anyone who ships a compression layer without measuring what it drops has just added a confident liar to their stack.

The line about what it does not know is the point. A summary that only tells you what it found sounds complete whether it is or not. One honest sentence naming the gap is what makes the whole feature trustworthy, and it is the first thing to check if you are judging whether yours works.

Question: [the question]
1. Search the brain and take the top 5 notes.
2. Answer in 4 to 6 lines, in plain words, using ONLY what is
   in those notes. No outside knowledge, no filling gaps.
3. List the note filenames you used.
4. Add one line: WHAT I DO NOT KNOW. Name what the question
   asked for that the notes did not cover. If they covered
   everything, say so plainly. Never leave this line out.
5. If the notes disagree with each other, say that instead of
   picking a side or averaging them into mush.
Use the cheapest model available for this job.

Why this works: step 4 is the whole feature. Steps 1 to 3 are a summarizer, and summarizers are everywhere. A summarizer that reliably names its own blind spot is the thing you can actually build a habit on.

Most pairs are not contradictions. They are supersessions. The old note was true then, the new one is true now, and nothing is wrong with either. This distinction is what makes the whole feature affordable. Call every one of them a conflict and the flag rate is so low against so many pairs that judging them is a week of work nobody will do. Give SUPERSEDED its own heading and the same pass produces a handful you can read with coffee.

Sample, do not compare everything. Every pair of notes is an enormous number of comparisons and almost all of them are unrelated. Compare only pairs that share an entity (which the graph from mechanism two just gave you for free) and have a real gap between their dates. That is where staleness actually lives.

Ship it dark and hand check the first twenty. Ours is built and deliberately switched off behind a flag file until the first twenty flags have been read by a human. A false contradiction is worse than no contradiction detection at all, because after two bad flags you stop reading the section, and then it may as well not exist.

It never resolves anything by itself. Which note is right is a judgment about your business. The machine finds the disagreement. You settle it.

Find where my brain argues with itself.
1. Take pairs of notes that share an entity and were written
   at least 30 days apart. Sample, do not compare everything.
2. For each pair ask: do these disagree about a fact?
   Sort every hit into exactly one bucket:
   - SUPERSEDED: both were true, the newer one replaced it.
     This is the common case. Say what changed and when.
   - CONTRADICTION: they cannot both have been true. Rare.
     Say precisely what conflicts.
   - AGREES: drop it silently.
3. Write the hits into the daily brief under two headings,
   SUPERSEDED first. Name both files and both dates.
4. Change NOTHING. Do not edit, merge or delete a note. You
   are reporting a disagreement, not settling it.
Use the cheapest model. Keep this job off until I have read
the first 20 flags by hand and told you they are worth having.

Why this works: two buckets instead of one is the difference between a feature that ships and a feature that is theoretically correct and permanently switched off. Almost everything it finds is a supersession, and a supersession is genuinely useful to see.

In Claude Code a skill is a markdown file with a small front matter block (name, description) living in a skills directory (project-level or global). The description tells the AI when the skill applies; the body is the procedure. Invocation is by name or automatic when the task matches. Two disciplines keep a skills library healthy: skills state their inputs and outputs explicitly (a fresh session must be able to run one without asking questions), and skills reference files by role ("the status file") with the actual path stated once at the top, so renames do not rot the whole library.

---
name: session-log
description: Run at the end of every session. Writes the log,
  updates status, captures lessons.
---
# Session close-out
1. Write docs/session-logs/[today].md with three headings:
   Completed / Left open / Start next with.
2. Update brain/STATUS.md: move finished items out of NOW,
   promote the top of NEXT.
3. Ask: "any mistake this session worth a rule?" If yes,
   append it to brain/lessons.md (max 3, dated, 2 sentences).
4. Ask: "any approach that worked well?" If yes, append to
   brain/patterns.md with when-to-apply.
5. Commit everything: git add -A && git commit -m "session log [today]"

Why this works: the close-out is the loop's most skipped step when it lives in memory, and the most reliable step when it lives in a file the AI executes line by line.

The pipeline is four stages, each an archetype you already know. Ingest (integrator): pull transcripts and text from public sources on a schedule. Index: chunk and embed into the same semantic search the brain uses, tagged by source. Surface (display): render as one-idea cards, each linked to its source passage. Apply (agent lane): a scheduled or on-demand AI pass that takes a live business question, retrieves the relevant frameworks, and drafts an answer for human review. Keep ingested knowledge in its own namespace so a retrieval can be scoped to "my history", "the playbooks", or both.

Question from the operator: [the live question]
Retrieved from OUR history: [top brain-search results]
Retrieved from THE PLAYBOOKS: [top knowledge-base results]
Answer in three parts:
1. What our own history says (cite the memories)
2. What the published frameworks say (cite the sources)
3. Your recommendation where they agree or conflict
Plain language. If the frameworks conflict with our history,
say so explicitly; do not average them into mush.

Why this works: separating "our history" from "the frameworks" prevents the most common failure of knowledge bases: generic advice wearing your company's name.