---

name: company-brain description: Your team's shared, AI-ready knowledge base — people, companies, meetings, SOPs, and decisions structured so Claude can answer questions on your team's behalf. Team-scope sibling to second-brain (which is personal-scope). Seven modes — capture (drop something into the right structured dir), compile (process into wiki pages, update INDEX.md), query (answer from the corpus with trust weighting, save to outputs/), review (triage queue — verify / deprecate / supersede unreviewed and stale captures so wrong info never becomes context), lint (orphans / stale / contradictions / gaps), connect (suggest new wikilinks), search (quick lookup). Structured raw dirs (people/, companies/, meetings/, sops/, decisions/, customer-language/, recurring-questions/, sales-objections/) instead of second-brain's flat type-prefixed raw/. Multi-author aware — every capture stamps author + timestamp + trust status. Optional auto-sync from Fathom/Gong/Granola call transcripts, Slack/email exports, CRM. Defaults to a vault at ${COMPANY_BRAIN_VAULT:-$HOME/Documents/CompanyBrain}/. Triggers on "/company-brain," "/cb," "capture this into the team brain," "log this meeting," "add this person to the team brain," "save this SOP," "compile the company wiki," "query the team brain," "what does the team know about X," "review the company brain," "cull the team brain," "lint the company brain," "who's the internal expert on X." metadata: version: 0.3.0

/company-brain — Team-shared AI-ready knowledge base

Company Brain (n.): Your team's shared, AI-ready knowledge base — people, companies, meetings, SOPs, and decisions structured so Claude can answer questions on your team's behalf.

Team-scope sibling to second-brain (personal-scope). Same core compile → wiki → outputs pattern; different raw schema optimized for multi-author, sales-heavy, ops-heavy team use.

Also the operational backbone for the Company Brain Setup productized service (was previously called "Second Brain as a Service"; renamed to match the skill).

Mental model

Three layers, same as second-brain — but the raw/ layer is structured, not flat:

raw/          →  wiki/         →  outputs/
(structured      (compiled        (generated
 by category)     interlinked)     artifacts)

Structured raw/ dirs (each is its own top-level folder in the vault):

| Dir | What lives here | |---|---| | people/ | Contacts with context — CRM-lite. One markdown file per person. | | companies/ | Org profiles — last touchpoint, opportunity size, status. One file per company. | | meetings/ | Call/meeting transcripts + notes. Naming: YYYY-MM-DD-<company-or-topic>-<slug>.md. Auto-sync source. | | sops/ | Standard operating procedures. Named: <team>-<process>.md (e.g., sales-outbound-cadence.md). | | decisions/ | Decision records (narrative form; decide skill's structured form is different). | | customer-language/ | Verbatim phrases from prospects/customers/users. Fuels copy, headlines, objections. | | recurring-questions/ | Questions asked 3+ times across calls. Each becomes a pre-answered SOP/FAQ/script. | | sales-objections/ | Library of objections + best responses. Assembled into sales scripts. | | raw/ | Legacy / uncategorized captures (fallback bucket, minimize use). |

wiki/, outputs/, and INDEX.md work the same as second-brain.

Reserved dirs (never modified by company-brain): Projects/, Team/, Templates/, Drafts/.

Multi-author discipline

Every capture stamps:

source: <URL / call / email / manual entry>
author: <who added this — email or handle>
captured: YYYY-MM-DD
trust: unreviewed

Wiki pages track cumulative contributions in the ## Sources section (per source file, per author). No overwriting — always append + attribute.

Sensitivity tagging (optional but recommended):

sensitivity: internal        # any team member can read
sensitivity: leadership      # exec team only
sensitivity: confidential    # named list only (list access in the file)

Default: internal. Query mode respects sensitivity — refuses to include confidential content unless the invoker is on the access list.

Trust levels

The other half of multi-author discipline: not everything captured deserves equal weight as context. Every structured-raw file carries a trust: field.

(The field is named trust, not status, because companies/ and decisions/ already use status: for lifecycle — prospect/customer, decided/reversed — and the two must not collide.)

| Trust | Meaning | Query treatment | |---|---|---| | unreviewed | Captured but no human has confirmed it (default for every new capture) | Usable, but flagged — answers leaning on it note lower confidence | | verified | A human reviewed it and confirmed it's right | Full weight | | deprecated | Wrong or obsolete — kept for history only | Never used as context | | superseded | Replaced by something newer — add superseded_by: [[target]] | Never used as context; queries point to the replacement |

Deliberately an enum, not a numeric weight — teams keep a four-value field current; nobody maintains a 0–1 float.

Deprecation replaces deletion. The "never delete raw files" rule stays intact: when info turns out wrong or stale, mark it deprecated (or superseded with a pointer) instead of removing it. History is preserved; context is protected.

Trust is orthogonal to sensitivity — a file can be verified + confidential, or unreviewed + internal.

Existing vaults: files predating trust levels simply lack the trust: field — treat them as unreviewed. If the vault's CLAUDE.md schema predates trust levels, offer to add the trust spec to it on the first /cb review run (the vault's CLAUDE.md stays authoritative — extend it, don't override it).

Step 1 — Load vault config + schema

1. Read references/vault-config.md for the vault path (default: ${COMPANY_BRAIN_VAULT:-$HOME/Documents/CompanyBrain}/)
2. Read <vault>/CLAUDE.md for the authoritative team schema. If present, trust it over references/schema.md — the team's vault is the source of truth.
3. If no <vault>/CLAUDE.md, fall back to references/schema.md — the team schema starter kit.

Step 2 — Parse mode

| Invocation | Mode | |---|---| | /cb capture / /company-brain capture / "capture this into the team brain" | capture | | /cb compile / "compile the company wiki" | compile | | /cb query <q> / "what does the team know about X" | query | | /cb review / "review the company brain" / "cull the team brain" | review | | /cb lint / "lint the company brain" | lint | | /cb connect / "find cross-team connections" | connect | | /cb search <term> / "search the company brain" | search |

Step 3 — Run the mode

capture

Same intake mechanics as second-brain, but the routing is different — pick the structured dir based on content type.

1. Detect content type + route to the right dir:

   • Call/meeting transcript → meetings/YYYY-MM-DD-<company-or-topic>-<slug>.md
   • Person's LinkedIn / bio / contact context → people/<name-slug>.md
   • Company profile / prospect / client → companies/<company-slug>.md
   • Documented process / how-we-do-X → sops/<team>-<process>.md
   • Decision made by leadership / team → decisions/YYYY-MM-DD-<decision-slug>.md
   • Verbatim customer quote → customer-language/<theme-slug>.md (append to existing themed file if one exists)
   • Question asked in a call → recurring-questions/<question-slug>.md (append counter if repeat)
   • Sales objection heard → sales-objections/<objection-slug>.md (append variant if repeat)
   • If ambiguous, ask.

2. Add multi-author metadata (top of file):

   source: <URL / call with X on YYYY-MM-DD / email from Y / etc.>
   author: <who captured this>
   captured: YYYY-MM-DD
   trust: unreviewed      # every capture starts unreviewed — review mode promotes it
   sensitivity: internal  # or leadership / confidential
   

3. Save + report file path + one-line summary.

Don't compile into the wiki here — capture is fast intake.

compile

Same core pattern as second-brain's compile mode — process unprocessed structured-raw files into wiki pages, update INDEX.md, add Sources sections.

Differences from second-brain:

• Multi-author attribution: Sources section includes author, not just filename

  ## Sources
  - `people/jane-doe.md` (added by @alex, 2026-06-30) — CTO of Acme, evaluated us Q2
  

• Cross-category compilation: a wiki page on "Acme Corp deal" might pull from companies/acme.md, meetings/2026-06-15-acme-discovery.md, sales-objections/acme-pricing.md, and people/jane-doe.md — all into one wiki page.
• Sensitivity inheritance: wiki pages inherit the highest sensitivity of any source. If any source is confidential, the wiki page is confidential.
• Trust filtering: deprecated and superseded sources are excluded from wiki pages. If a source that already fed a wiki page later gets deprecated, recompile flags the affected pages for re-review and drops the source, noting it in Sources using the file's reviewed + reviewed_by stamps: - meetings/2026-06-15-x.md (deprecated 2026-07-01 by @alex). Pages built mostly from unreviewed sources get a > ⚠ Mostly unreviewed sources callout at the top.
• INDEX.md categories for teams: Sales, Customers, Ops, Product, Team & People, Decisions, Playbooks. Extend as needed.

Everything else (one-page-per-concept, [[wikilinks]], Connections mandatory, quality > quantity) is identical.

query

Same as second-brain query, plus:

• Sensitivity check first: identify the invoker; refuse to include content above their sensitivity level.
• Trust rules: prefer verified over unreviewed, and recent over old. Never use deprecated or superseded content as context — at most cite it as a pointer: "(deprecated — see [[replacement]])". When two sources conflict, prefer the newer + higher-status one AND surface the disagreement in the answer.
• Confidence flag: if the answer leans mostly on unreviewed sources, say so up front: "Low confidence — 3 of 4 sources are unreviewed. Run /cb review to firm these up."
• Author-aware answers: when citing, include who contributed the info: "Per [[Acme Deal]] (source: meetings/2026-06-15-acme-discovery.md by @alex)..."
• Route external gaps to deep-research, same as second-brain.

Save to outputs/<YYYY-MM-DD>-<question-slug>.md with the answer + wiki pages consulted + sensitivity level of the output.

review

The human culling pass. This is how a team keeps garbage-in from becoming garbage-context: everything gets captured freely (nothing is lost), but only reviewed info earns full weight.

0. Sensitivity check first — same rule as query mode: identify the invoker and exclude files above their sensitivity level from the queue. Report the exclusion count: "3 items above your sensitivity level were skipped — someone on the leadership list needs to review those."

1. Build the triage queue:

   • All trust: unreviewed files across the structured-raw dirs (including files with no trust: field at all), newest first
   • Everything lint flags (checks 1–12; check 13 is about review itself)
   • Files whose review dates have lapsed, where those fields exist: decisions/ files past review_by, sops/ files past last_reviewed + review_cadence

2. Walk the queue one item at a time. For each file show: one-line summary, source, author, captured date, and which wiki pages cite it. Offer four dispositions — every disposition except skip stamps reviewed: YYYY-MM-DD + reviewed_by: <handle>:

   • verify → trust: verified
   • deprecate → trust: deprecated (wrong or obsolete; kept for history)
   • supersede → `trust: