company-brain

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

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

/company-brain — 团队共享的AI就绪知识库

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).

Company Brain（名词）：你的团队共享的AI就绪知识库——将人员、公司、会议、标准操作流程（SOP）和决策进行结构化处理，以便Claude可以代表你的团队回答问题。

它是个人范围的

second-brain

的团队范围姊妹工具。核心流程同样是编译→wiki→输出，但采用了不同的原始数据架构，专为多作者、销售导向、运营导向的团队使用场景优化。

同时，它也是Company Brain Setup产品化服务的运营核心（此前名为“Second Brain as a Service”，为匹配该工具更名为现名）。

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/

与second-brain相同，分为三层，但raw/层是结构化而非扁平化的：

raw/          →  wiki/         →  outputs/
(按类别结构化      (编译后互链        (生成的
存储)           的内容)           成果)

结构化raw/目录（每个都是存储库中的顶级文件夹）：

目录	存储内容
`people/`	带有上下文信息的联系人——类CRM系统。每个人对应一个markdown文件。
`companies/`	组织档案——最近接触点、商机规模、状态。每个公司对应一个文件。
`meetings/`	通话/会议记录+笔记。命名规则： `YYYY-MM-DD-<公司或主题>-<缩写>.md` 。支持自动同步来源。
`sops/`	标准操作流程。命名规则： `<团队>-<流程>.md` （例如： `sales-outbound-cadence.md` ）。
`decisions/`	决策记录（叙事形式； `decide` 工具的结构化形式与此不同）。
`customer-language/`	来自潜在客户/客户/用户的原话。用于支撑文案、标题、异议处理内容。
`recurring-questions/`	通话中被询问3次以上的问题。每个问题会转化为预答的SOP/FAQ/脚本。
`sales-objections/`	异议库+最佳回复。可整合为销售脚本。
`raw/`	遗留/未分类的捕获内容（备用存储桶，尽量少用）。

wiki/

、

outputs/

和

INDEX.md

的工作方式与second-brain一致。

保留目录（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.

每次捕获都会标记以下元数据：

markdown

source: <URL / 通话 / 邮件 / 手动输入>
author: <添加者——邮箱或账号>
captured: YYYY-MM-DD
trust: unreviewed

Wiki页面会在

## Sources

部分记录累计贡献（按源文件、按作者）。禁止覆盖内容——始终采用追加+署名的方式。

敏感度标记（可选但推荐）：

markdown

sensitivity: internal        # 所有团队成员均可查看
sensitivity: leadership      # 仅高管团队可查看
sensitivity: confidential    # 仅指定列表人员可查看（在文件中列出访问权限）

默认值：

internal

。查询模式会遵守敏感度规则——除非调用者在访问列表中，否则不会包含

confidential

内容。

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).

多作者规范的另一部分：并非所有捕获内容都具有同等的上下文权重。每个结构化原始文件都带有

trust:

字段。

（该字段命名为

trust

而非

status

，因为

companies/

和

decisions/

已使用

status:

表示生命周期——潜在客户/客户、已决定/已撤销——两者不能冲突。）

信任等级	含义	查询处理方式
`unreviewed`	已捕获但未经过人工确认（所有新捕获内容的默认值）	可使用，但会标记——依赖该内容的答案会注明置信度较低
`verified`	已通过人工审核并确认内容正确	赋予全部权重
`deprecated`	内容错误或过时——仅保留历史记录	绝不会作为上下文使用
`superseded`	已被更新内容替代——需添加 `superseded_by: [[目标文件]]`	绝不会作为上下文使用；查询会指向替代内容

刻意采用枚举值而非数值权重——团队只需维护四个选项的字段，无需管理0-1的浮点数。

弃用替代删除。“绝不删除原始文件”的规则依然有效：当内容被证明错误或过时，标记为

deprecated

（或

superseded

并添加指向替代内容的链接），而非删除。历史记录得以保留，上下文信息得到保护。

信任等级与敏感度相互独立——一个文件可以是

verified

confidential

，也可以是

unreviewed

internal

。

现有存储库：早于信任等级的文件会缺少

trust:

字段——将其视为

unreviewed

。如果存储库的

CLAUDE.md

架构早于信任等级，首次运行

/cb review

时会提议将信任规范添加到该文件中（存储库的CLAUDE.md始终是权威来源——仅扩展，不覆盖）。

Step 1 — Load vault config + schema

步骤1 — 加载存储库配置与架构

Read

references/vault-config.md

for the vault path (default:

${COMPANY_BRAIN_VAULT:-$HOME/Documents/CompanyBrain}/

)

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.
If no
```
<vault>/CLAUDE.md
```
, fall back to
```
references/schema.md
```
— the team schema starter kit.

读取

references/vault-config.md

获取存储库路径（默认值：

${COMPANY_BRAIN_VAULT:-$HOME/Documents/CompanyBrain}/

）

读取
```
<存储库>/CLAUDE.md
```
获取权威团队架构。如果存在，优先信任该文件而非
```
references/schema.md
```
——团队的存储库是事实来源。
如果没有
```
<存储库>/CLAUDE.md
```
，则回退到
```
references/schema.md
```
——团队架构入门套件。

Step 2 — Parse mode

步骤2 — 解析模式

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

调用指令	模式
`/cb capture` / `/company-brain capture` / "将此内容捕获到团队知识库"	捕获
`/cb compile` / "编译公司wiki"	编译
`/cb query <q>` / "团队对X了解多少"	查询
`/cb review` / "审核公司知识库" / "清理团队知识库"	审核
`/cb lint` / "检查公司知识库"	检查
`/cb connect` / "查找跨团队关联"	关联
`/cb search <term>` / "搜索公司知识库"	搜索

Step 3 — Run the mode

步骤3 — 运行对应模式

capture

捕获

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

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.

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

Save + report file path + one-line summary.

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

与second-brain的输入机制相同，但路由方式不同——根据内容类型选择结构化目录。

检测内容类型并路由到对应目录：
- 通话/会议记录 →
```
meetings/YYYY-MM-DD-<公司或主题>-<缩写>.md
```
- 个人LinkedIn资料/简历/联系上下文 →
```
people/<姓名缩写>.md
```
- 公司档案/潜在客户/客户 →
```
companies/<公司缩写>.md
```
- 已记录的流程/操作指南 →
```
sops/<团队>-<流程>.md
```
- 领导层/团队做出的决策 →
```
decisions/YYYY-MM-DD-<决策缩写>.md
```
- 客户原话 →
```
customer-language/<主题缩写>.md
```
  （如果已有对应主题文件，则追加内容）
- 通话中被询问的问题 →
```
recurring-questions/<问题缩写>.md
```
  （如果重复则追加计数）
- 销售异议 →
```
sales-objections/<异议缩写>.md
```
  （如果重复则追加变体）
- 如果内容类型不明确，询问用户确认。

添加多作者元数据（文件顶部）：

markdown

source: <URL / 与X在YYYY-MM-DD的通话 / 来自Y的邮件 / 等>
author: <捕获者>
captured: YYYY-MM-DD
trust: unreviewed      # 所有捕获内容初始状态为未审核——审核模式可提升其等级
sensitivity: internal  # 或leadership / confidential

保存并反馈文件路径+一行摘要。

此阶段不编译到wiki中——捕获是快速录入环节。

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.

与

second-brain

的编译模式核心流程相同——将未处理的结构化原始文件处理为wiki页面，更新INDEX.md，添加Sources部分。

与second-brain的差异：

多作者署名：Sources部分包含作者信息，而非仅文件名

markdown

## Sources
- `people/jane-doe.md`（由@alex添加，2026-06-30）——Acme公司CTO，于Q2评估我方

跨类别编译：关于“Acme Corp交易”的wiki页面可能会整合
```
companies/acme.md
```
、
```
meetings/2026-06-15-acme-discovery.md
```
、
```
sales-objections/acme-pricing.md
```
和
```
people/jane-doe.md
```
的内容——全部合并到一个wiki页面中。
敏感度继承：wiki页面会继承所有源文件中的最高敏感度。如果任何源文件是
```
confidential
```
，则wiki页面也为
```
confidential
```
。
信任过滤：
```
deprecated
```
和
```
superseded
```
的源文件会被排除在wiki页面之外。如果已被用于生成wiki页面的源文件后来被标记为弃用，重新编译会标记受影响的页面需要重新审核，并在Sources部分注明该文件的
```
reviewed
```
+
```
reviewed_by
```
标记：
```
- meetings/2026-06-15-x.md（于2026-07-01由@alex标记为弃用）
```
。主要基于
```
unreviewed
```
源文件构建的页面会在顶部显示
```
> ⚠ 主要来源未经过审核
```
的提示。
INDEX.md团队分类：
```
Sales
```
、
```
Customers
```
、
```
Ops
```
、
```
Product
```
、
```
Team & People
```
、
```
Decisions
```
、
```
Playbooks
```
。可根据需要扩展。

其他规则（每个概念对应一个页面、

[[wikilinks]]

链接、强制关联、质量优先于数量）与second-brain完全一致。

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.

与second-brain的查询模式相同，新增以下特性：

先进行敏感度检查：识别调用者；拒绝包含超出其敏感度等级的内容。
信任规则：优先使用
```
verified
```
内容而非
```
unreviewed
```
内容，优先使用最新内容而非旧内容。绝不会将
```
deprecated
```
或
```
superseded
```
内容作为上下文——最多将其作为引用指针：“（已弃用——请查看[[替代内容]]）”。当两个源内容冲突时，优先选择更新、等级更高的内容，并在答案中指出分歧。
置信度标记：如果答案主要依赖
```
unreviewed
```
源内容，会在开头注明：“置信度较低——4个来源中有3个未经过审核。运行
/cb review
以确认这些内容。”
作者感知的答案：引用内容时会注明贡献者：“根据[[Acme交易]]（来源：
meetings/2026-06-15-acme-discovery.md
，由@alex提供）……”
将外部信息缺口路由至
deep-research
，与second-brain相同。

将答案保存至

outputs/<YYYY-MM-DD>-<问题缩写>.md

，包含答案+参考的wiki页面+输出内容的敏感度等级。

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.

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."
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
```
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
Batch-apply the frontmatter updates — don't rewrite file bodies, only the metadata block.
Flag downstream effects: if a deprecated/superseded file feeds existing wiki pages, list those pages and offer to recompile them now.
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).

人工清理环节。这是团队防止“垃圾进垃圾出”的关键：所有内容都可以自由捕获（不会丢失），但只有经过审核的内容才能获得全部权重。

先进行敏感度检查——与查询模式规则相同：识别调用者，将超出其敏感度等级的文件排除在队列之外。反馈排除数量：“有3项内容超出你的敏感度等级已被跳过——需要领导层列表中的人员审核这些内容。”
构建分类队列：
- 所有结构化原始目录中的
```
trust: unreviewed
```
  文件（包括完全没有
```
trust:
```
  字段的文件），按最新优先排序
- 所有检查模式标记的问题（检查项1–12；检查项13与审核本身相关）
- 审核日期过期的文件（如果存在相关字段）：
```
decisions/
```
  中超过
```
review_by
```
  日期的文件、
```
sops/
```
  中超过
```
last_reviewed
```
  +
```
review_cadence
```
  的文件
逐个处理队列中的项目。对于每个文件，显示：一行摘要、来源、作者、捕获日期、引用该文件的wiki页面。提供四种处理选项——除“跳过”外，所有选项都会标记
```
reviewed: YYYY-MM-DD
```
+
```
reviewed_by: <账号>
```
：
- 验证 →
```
trust: verified
```
- 弃用 →
```
trust: deprecated
```
  （内容错误或过时；仅保留历史记录）
- 替代 →
```
trust: superseded
```
  +
```
superseded_by: [[目标文件]]
```
  （询问替代内容）
- 跳过 → 保持原样，下次审核时重新出现
批量更新前置元数据——不修改文件主体，仅更新元数据块。
标记下游影响：如果被弃用/替代的文件已被用于生成现有wiki页面，列出这些页面并提议立即重新编译。
结束时提供摘要：*“已审核12项：8项验证通过，3项弃用，1项替代。已重新编译2个wiki页面。建议下次审核日期：<日期>。”*将摘要保存至
```
outputs/<YYYY-MM-DD>-review.md
```
，以便清理操作本身有审计记录。

周期：活跃存储库每周一次；搭配

loopify

工具安排定期任务，确保清理操作按时进行，无需依赖人工记忆。如果存储库超过1个月未进行审核，检查模式会标记该问题（检查项13）。

lint

检查

Same seven checks as second-brain PLUS:

Stale people/companies —
```
people/
```
or
```
companies/
```
file with no update in >6 months for active accounts
Recurring-questions above threshold — questions asked 5+ times without a wiki page or SOP
Objections without responses —
```
sales-objections/
```
files with no linked response in
```
sops/
```
or
```
wiki/
```
SOP freshness — SOPs not touched in >12 months (may be stale as the business evolves)
Author load imbalance — one contributor doing >80% of captures (usually signals the vault is one-person-dependent — bad for team continuity)
Review backlog — >20 files sitting at
```
trust: unreviewed
```
, or no review pass (no
```
outputs/*-review.md
```
) in >1 month. Points at
```
/cb review
```
.

与second-brain的7项检查相比，新增以下检查项：

过时的人员/公司信息 ——
```
people/
```
或
```
companies/
```
中活跃账户超过6个月未更新的文件
高频重复问题 —— 被询问5次以上但未生成wiki页面或SOP的问题
无回复的异议 ——
```
sales-objections/
```
中未链接到
```
sops/
```
或
```
wiki/
```
中回复内容的文件
SOP时效性 —— 超过12个月未更新的SOP（可能因业务发展而过时）
作者负载失衡 —— 单个贡献者完成超过80%的捕获内容（通常表明存储库依赖单人，不利于团队连续性）
审核积压 —— 超过20个文件处于
```
trust: unreviewed
```
状态，或超过1个月未进行审核（无
```
outputs/*-review.md
```
文件）。指向
```
/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.

与second-brain相同，新增跨类别链接建议——例如，如果

customer-language/willingness-to-pay.md

和

sops/discovery-call-cadence.md

存在，

sales-objections/pricing-too-high.md

应链接到这两个文件。

search

搜索

Same. Grep across all structured-raw dirs +

wiki/

与second-brain相同。在所有结构化原始目录+

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.

团队存储库可受益于自动化捕获。查看

references/auto-sync-sources.md

获取设置模式：

来源	捕获内容	设置方式
Fathom / Gong / Granola	通话/会议记录	Webhook → 追加至 `meetings/`
Slack导出	值得保留的团队讨论内容	手动或定期导出 → `raw/slack-<频道>-<日期>.md`
邮件（Front / Missive / Superhuman）	值得保留的客户沟通线程	转发至指定地址 → 追加至 `people/` 或 `companies/`
CRM（HubSpot / Attio / Pipedrive）	交易状态、联系信息	定期同步 → `companies/` + `people/`

自动同步是可选功能——大多数团队从手动捕获开始，随着存储库成熟再添加自动化。搭配

loopify

工具安排定期同步任务。

Multi-writer git sync (team members + remote agents)

多作者Git同步（团队成员+远程代理）

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) can read the wiki and commit captures into the structured raw dirs.

The discipline that keeps writers from diverging:

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.
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.
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.

团队存储库本质上是多作者的，Git是协调层。将存储库托管到远程平台（GitHub/GitLab）；远程平台同时作为无文件系统访问权限的代理的捕获API——云代理、定期同步任务、团队成员的设备。任何可以访问Git平台API的工具（直接访问，或通过MCP集成层如Executor）都可以读取wiki内容并将捕获内容提交到结构化原始目录。

防止作者内容分歧的规范：

每次本地会话在写入前拉取：在操作存储库前执行
```
git pull --rebase --autostash
```
，提交后推送。由于多个人类和代理同时提交，本地副本会很快过时。
Obsidian用户：使用社区Git插件，设置定期自动拉取（约10分钟）+启动时拉取，关闭自动提交——提交应保持语义化（每次捕获/编译对应一次提交），而非“存储库备份”式的冗余提交。所有团队成员的设备都需要设置此配置，而非仅单人设置。
远程代理和自动同步任务以追加方式提交：在结构化目录中添加新文件，使用描述性提交信息，在捕获前置元数据中标记作者（多作者信任模型依赖此信息）。追加独立文件可减少冲突；变基操作可处理剩余冲突。

入职时在每台设备上验证一次流程：通过API远程提交→本地拉取→文件出现。

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.

second-brain
—— 姊妹工具。使用
```
second-brain
```
管理个人wiki；使用
```
company-brain
```
管理团队wiki。个人可通过不同存储库路径同时维护两者。
skillify
—— 用于编写可读取company-brain内容的新工具（例如，每周一查询
```
company-brain
```
的
```
weekly-team-brief
```
工具）。
loopify
—— 安排自动同步任务（每日拉取Fathom数据、每周导出Slack内容、每周审核、每月检查INDEX）。
toolify
—— 搭建向company-brain提供数据的集成（Fathom Webhook接收器、Attio API等）。
deep-research
—— 当
```
query
```
发现信息缺口时，路由至外部研究。将深度研究结果保存至
```
raw/
```
以便后续编译。
decide
——
```
decisions/
```
文件夹补充
```
decide
```
的结构化存档。
```
decide
```
记录评估过程；
```
decisions/
```
记录叙事内容+结果+审核笔记。
pm
—— 团队任务管理位于
```
Projects/
```
（company-brain保留目录）。
```
pm
```
负责Projects/；company-brain读取该目录内容作为上下文，但不会修改。
jab-hook
——
```
customer-language/
```
为符合潜在客户真实语言习惯的社交文案提供支撑。
博客草稿工具（自定义或配套插件）——从
```
customer-language/
```
、
```
recurring-questions/
```
和
```
sops/
```
中提取内容生成权威博客草稿。

Sibling implementations (reference)

姊妹实现（参考）

Same lineage as

second-brain

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
— 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.

与

second-brain

同属一个体系：

Gbrain —— Garry Tan的团队级知识库（146K页面，24K人员实体）。基于Postgres/PGLite，支持图遍历+定期维护。当团队的company-brain超出纯markdown的承载能力时，Gbrain是升级方向。
Hermes'
llm-wiki
—— 三文件夹模式的参考实现。
Notion AI / Glean / Mem —— 商业化“公司操作系统”工具。Company-brain是Claude原生、优先支持markdown的替代方案——成本更低、更易迁移，更适合已使用Obsidian / Git托管文档的团队。

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.

团队规模下，结构化原始内容优于扁平化原始内容。second-brain的类型前缀适合个人使用；团队需要专门的人员/公司/会议等目录，以便多作者搜索保持高效。
多作者署名必不可少。每个文件都标记
```
author:
```
和
```
captured:
```
。Wiki页面按来源+作者引用。
端到端遵守敏感度规则。查询模式拒绝包含超出调用者等级的内容。Wiki页面继承所有源文件中的最高敏感度。
绝不删除原始文件。与second-brain的规则相同——结构化目录是事实来源。当内容错误或过时，弃用而非删除——
```
trust: deprecated
```
会将其从上下文中移除，但保留历史记录。
自由捕获，审慎加权。信任枚举值意味着自由录入信息是安全的——未审核内容不会以全权重污染答案，
```
/cb review
```
是定期清理环节，用于提升或淘汰内容。
company-brain操作期间绝不修改
```
Projects/
```
、
```
Team/
```
、
```
Templates/
```
、
```
Drafts/
```
。
自动同步是可选功能。从手动开始；随着存储库成熟再添加自动化。在团队尚未习惯手动捕获会议内容前，不要浪费时间设置Fathom Webhook。
存储库不应依赖单人。如果检查模式标记作者负载失衡超过80%，团队面临因单人离职而丢失知识库的风险。应扩大贡献者范围。