--- name: Company Brain slug: company-brain category: AI Engineering description: Company Brain structures team knowledge about people, companies, meetings, SOPs, decisions, and customer language so Claude can answer questions and compile a wiki. Use it to capture, query, review, lint, connect, or search shared context. github: "https://github.com/coreyhaines31/makerskills/tree/main/skills/company-brain" stars: 680 forks: 55 install: "npx degit https://github.com/coreyhaines31/makerskills/tree/main/skills/company-brain ~/.claude/skills/company-brain" installs_to: ~/.claude/skills/company-brain source_path: skills/company-brain/SKILL.md collection_size: 20 category_size: 2451 collection_url: "https://dirskills.com/collections/coreyhaines31/makerskills" added: 2026-08-24T05:16:16.044Z last_synced: 2026-08-24T05:16:16.044Z canonical_url: "https://dirskills.com/skills/company-brain" --- # Company Brain Company Brain structures team knowledge about people, companies, meetings, SOPs, decisions, and customer language so Claude can answer questions and compile a wiki. Use it to capture, query, review, lint, connect, or search shared context. **Install:** ```bash npx degit https://github.com/coreyhaines31/makerskills/tree/main/skills/company-brain ~/.claude/skills/company-brain ``` ## README # /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--.md`. Auto-sync source. | | `sops/` | Standard operating procedures. Named: `-.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: ```markdown source: author: 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): ```markdown 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 `/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 `/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 ` / "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 ` / "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--.md` - Person's LinkedIn / bio / contact context → `people/.md` - Company profile / prospect / client → `companies/.md` - Documented process / how-we-do-X → `sops/-.md` - Decision made by leadership / team → `decisions/YYYY-MM-DD-.md` - Verbatim customer quote → `customer-language/.md` (append to existing themed file if one exists) - Question asked in a call → `recurring-questions/.md` (append counter if repeat) - Sales objection heard → `sales-objections/.md` (append variant if repeat) - If ambiguous, ask. 2. **Add multi-author metadata** (top of file): ```markdown source: author: 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 ```markdown ## 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/-.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: `: - **verify** → `trust: verified` - **deprecate** → `trust: deprecated` (wrong or obsolete; kept for history) - **supersede** → `trust: superseded` + `superseded_by: [[target]]` (ask for the replacement) - **skip** → leave as-is, resurfaces next review 3. **Batch-apply the frontmatter updates** — don't rewrite file bodies, only the metadata block. 4. **Flag downstream effects**: if a deprecated/superseded file feeds existing wiki pages, list those pages and offer to recompile them now. 5. **Close with a summary**: *"12 reviewed: 8 verified, 3 deprecated, 1 superseded. 2 wiki pages recompiled. Next review suggested: ."* Save the summary to `outputs/-review.md` so the cull itself has an audit trail. **Cadence**: weekly for active vaults; pair with `loopify` to schedule it so the cull actually happens instead of depending on someone remembering. A vault where reviews lapse >1 month shows up in lint (check 13). ### lint Same seven checks as second-brain PLUS: 8. **Stale people/companies** — `people/` or `companies/` file with no update in >6 months for active accounts 9. **Recurring-questions above threshold** — questions asked 5+ times without a wiki page or SOP 10. **Objections without responses** — `sales-objections/` files with no linked response in `sops/` or `wiki/` 11. **SOP freshness** — SOPs not touched in >12 months (may be stale as the business evolves) 12. **Author load imbalance** — one contributor doing >80% of captures (usually signals the vault is one-person-dependent — bad for team continuity) 13. **Review backlog** — >20 files sitting at `trust: unreviewed`, or no review pass (no `outputs/*-review.md`) in >1 month. Points at `/cb review`. ### connect Same as second-brain plus **cross-category link suggestions** — e.g., `sales-objections/pricing-too-high.md` should link to `customer-language/willingness-to-pay.md` and `sops/discovery-call-cadence.md` if they exist. ### search Same. Grep across all structured-raw dirs + `wiki/`. ## Optional: auto-sync sources Team vaults benefit from automated capture. See `references/auto-sync-sources.md` for the setup patterns: | Source | What it captures | Setup | |---|---|---| | **Fathom / Gong / Granola** | Call/meeting transcripts | Webhook → append to `meetings/` | | **Slack export** | Team discussions worth preserving | Manual or scheduled export → `raw/slack--.md` | | **Email (Front / Missive / Superhuman)** | Customer-facing threads worth preserving | Forward-to-address → append to `people/` or `companies/` | | **CRM (HubSpot / Attio / Pipedrive)** | Deal state, contact info | Periodic sync → `companies/` + `people/` | Auto-sync is optional — most teams start with manual capture and add automation as the vault matures. Pair with `loopify` to schedule periodic sync jobs. ## Multi-writer git sync (team members + remote agents) A team vault is multi-writer by definition, and git is the coordination layer. Back the vault with a hosted remote (GitHub/GitLab); the remote then doubles as a **capture API for agents without filesystem access** — cloud agents, scheduled sync jobs, teammates' machines. Anything that can reach the git host's API (directly, or through an MCP integration layer like [Executor](https://executor.sh)) can read the wiki and commit captures into the structured raw dirs. The discipline that keeps writers from diverging: 1. **Every local session pulls before writing**: `git pull --rebase --autostash` before vault work, push after committing. With multiple humans *and* agents committing, local copies go stale fast. 2. **Obsidian users**: the community **Git** plugin with auto-pull on an interval (~10 min) + pull-on-startup, auto-commit **off** — commits should stay semantic (one per capture/compile), not "vault backup" noise. Every team member's machine needs this, not just one. 3. **Remote agents and auto-sync jobs commit append-mostly**: new files in the structured dirs, descriptive commit messages, author stamped in the capture frontmatter (the multi-author trust model depends on it). Distinct-file appends make conflicts rare; rebase absorbs the rest. Verify the loop once per machine when onboarding: remote commit via API → local pull → file appears. ## Composes with - **`second-brain`** — sibling. Use `second-brain` for your personal wiki; `company-brain` for the team's. A person can maintain both simultaneously with separate vault paths. - **`skillify`** — use to author new skills that read from the company brain (e.g., a `weekly-team-brief` skill that queries `company-brain` every Monday). - **`loopify`** — schedule auto-sync jobs (Fathom pull daily, Slack export weekly, review pass weekly, INDEX lint monthly). - **`toolify`** — wire up integrations that feed the company brain (Fathom webhook receiver, Attio API, etc.). - **`deep-research`** — when `query` finds gaps, route external. Save deep-research results into `raw/` for future compilation. - **`decide`** — `decisions/` folder complements `decide`'s structured archive. `decide` records the *evaluation*; `decisions/` records the *narrative + outcome + review notes*. - **`pm`** — team task management sits in `Projects/` (reserved from company-brain). `pm` owns Projects/; company-brain reads it for context but doesn't modify. - **`jab-hook`** — `customer-language/` fuels social copy that resonates with actual prospect language. - A blog-drafting skill (yours or a companion plugin) — pulls from `customer-language/`, `recurring-questions/`, and `sops/` for authoritative blog drafts. ## Sibling implementations (reference) Same lineage as `second-brain`: - **[Gbrain](https://github.com/garrytan/gbrain)** — Garry Tan's team-scale brain (146K pages, 24K people entities). Postgres/PGLite backed with graph traversal + scheduled maintenance. When a team's company-brain outgrows markdown-only, Gbrain is the upgrade path. - **[Hermes' `llm-wiki`](https://hermes.team)** — reference for the 3-folder pattern. - **Notion AI / Glean / Mem** — commercial "Company OS" tools. Company-brain is the Claude-native, markdown-first alternative — cheaper, more portable, better for teams that already live in Obsidian / Git-backed docs. ## Notes on quality - **Structured raw > flat raw at team scale.** Second-brain's type-prefix works for one person; teams need dedicated dirs for people/companies/meetings/etc. so multi-author search stays fast. - **Multi-author attribution is non-negotiable.** Every file stamps `author:` and `captured:`. Wiki pages cite by source + author. - **Sensitivity is respected end-to-end.** Query mode refuses to include content above the invoker's level. Wiki pages inherit the highest sensitivity of any source. - **Never delete raw files.** Same rule as second-brain — the structured dirs are the source of truth. When info is wrong or stale, **deprecate, don't delete** — `trust: deprecated` removes it from context while preserving history. - **Capture freely, weight deliberately.** The trust enum means dumping information in is safe — nothing unreviewed poisons answers at full weight, and `/cb review` is the regular cull that promotes or retires it. - **Never modify** `Projects/`, `Team/`, `Templates/`, `Drafts/` during company-brain operations. - **Auto-sync is optional.** Start manual; automate as the vault matures. Don't burn cycles on Fathom webhooks before the team is capturing meetings regularly by hand. - **One person shouldn't be the whole vault.** If lint flags author-load imbalance >80%, the team is one bus-factor away from losing the brain. Broaden contribution.