company-brain — скилл для Claude Code: база знаний команды

---
name: company-brain
description: Your team's shared, AI-ready knowledge base — people, companies, meetings, SOPs, and decisions structured so an agent can answer on your team's behalf. Team-scope sibling to second-brain — personal notes go there, not here. Modes — capture, compile (wiki pages + INDEX.md), query (trust-weighted, saved to outputs/), review (verify / deprecate / supersede stale captures), lint, connect, search. Structured raw dirs (people/, companies/, meetings/, sops/, decisions/, customer-language/, sales-objections/). Every capture stamps author, timestamp, and trust status. Optional sync from call transcripts, Slack/email exports, CRM. Vault at ${COMPANY_BRAIN_VAULT:-$HOME/Documents/CompanyBrain}/. Triggers on "/company-brain," "/cb," "capture this into the team brain," "log this meeting," "save this SOP," "compile the company wiki," "query the team brain," "what does the team know about X," "review the company brain," "lint the company brain," "who's the internal expert on X."
metadata:
  version: 0.4.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:

```markdown
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):

```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 schema doc (`CLAUDE.md` / `AGENTS.md`) 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 the vault's schema doc — `<vault>/CLAUDE.md` or `<vault>/AGENTS.md`, whichever exists (if both, read both) — for the authoritative team schema. If present, trust it over `references/schema.md` — the team's vault is the source of truth.
3. If neither exists, 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.
   - If the target dir doesn't exist yet, create it with this capture. New vaults start with only one pilot workflow's dirs (see `references/vault-config.md` → "Start narrow").

2. **Add multi-author metadata** (top of file):
   ```markdown
   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
  ```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/<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: 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: <date>."* Save the summary to `outputs/<YYYY-MM-DD>-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-<channel>-<date>.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.
- **Start narrow, earn the right to expand.** Seed one revenue-adjacent workflow's dirs, pilot with one or two people, and widen only once queries are getting answered and review is holding. See `references/rollout.md`.
- **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.