{"id":"company-brain","name":"company-brain","summary":"チームの共有されたAI対応の知識ベース—人、会社、会議、SOP、意思決定が、Claudeがチームの代わりに質問に答えられるように構成されています。","body":"# /company-brain — Team-shared AI-ready knowledge base\n\n**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.\n\nTeam-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.\n\nAlso the operational backbone for the **Company Brain Setup** productized service (was previously called \"Second Brain as a Service\"; renamed to match the skill).\n\n## Mental model\n\nThree layers, same as second-brain — but the raw/ layer is *structured*, not flat:\n\n```\nraw/          →  wiki/         →  outputs/\n(structured      (compiled        (generated\n by category)     interlinked)     artifacts)\n```\n\n**Structured raw/ dirs** (each is its own top-level folder in the vault):\n\n| Dir | What lives here |\n|---|---|\n| `people/` | Contacts with context — CRM-lite. One markdown file per person. |\n| `companies/` | Org profiles — last touchpoint, opportunity size, status. One file per company. |\n| `meetings/` | Call/meeting transcripts + notes. Naming: `YYYY-MM-DD-<company-or-topic>-<slug>.md`. Auto-sync source. |\n| `sops/` | Standard operating procedures. Named: `<team>-<process>.md` (e.g., `sales-outbound-cadence.md`). |\n| `decisions/` | Decision records (narrative form; `decide` skill's structured form is different). |\n| `customer-language/` | Verbatim phrases from prospects/customers/users. Fuels copy, headlines, objections. |\n| `recurring-questions/` | Questions asked 3+ times across calls. Each becomes a pre-answered SOP/FAQ/script. |\n| `sales-objections/` | Library of objections + best responses. Assembled into sales scripts. |\n| `raw/` | Legacy / uncategorized captures (fallback bucket, minimize use). |\n\n`wiki/`, `outputs/`, and `INDEX.md` work the same as second-brain.\n\n**Reserved dirs** (never modified by company-brain): `Projects/`, `Team/`, `Templates/`, `Drafts/`.\n\n## Multi-author discipline\n\nEvery capture stamps:\n\n```markdown\nsource: <URL / call / email / manual entry>\nauthor: <who added this — email or handle>\ncaptured: YYYY-MM-DD\ntrust: unreviewed\n```\n\nWiki pages track cumulative contributions in the `## Sources` section (per source file, per author). No overwriting — always append + attribute.\n\n**Sensitivity tagging** (optional but recommended):\n\n```markdown\nsensitivity: internal        # any team member can read\nsensitivity: leadership      # exec team only\nsensitivity: confidential    # named list only (list access in the file)\n```\n\nDefault: `internal`. Query mode respects sensitivity — refuses to include `confidential` content unless the invoker is on the access list.\n\n## Trust levels\n\nThe other half of multi-author discipline: not everything captured deserves equal weight as context. Every structured-raw file carries a `trust:` field.\n\n(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.)\n\n| Trust | Meaning | Query treatment |\n|---|---|---|\n| `unreviewed` | Captured but no human has confirmed it (default for every new capture) | Usable, but flagged — answers leaning on it note lower confidence |\n| `verified` | A human reviewed it and confirmed it's right | Full weight |\n| `deprecated` | Wrong or obsolete — kept for history only | Never used as context |\n| `superseded` | Replaced by something newer — add `superseded_by: [[target]]` | Never used as context; queries point to the replacement |\n\nDeliberately an enum, not a numeric weight — teams keep a four-value field current; nobody maintains a 0–1 float.\n\n**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.\n\nTrust is orthogonal to sensitivity — a file can be `verified` + `confidential`, or `unreviewed` + `internal`.\n\n**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).\n\n## Step 1 — Load vault config + schema\n\n1. Read `references/vault-config.md` for the vault path (default: `${COMPANY_BRAIN_VAULT:-$HOME/Documents/CompanyBrain}/`)\n2. 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.\n3. If no `<vault>/CLAUDE.md`, fall back to `references/schema.md` — the team schema starter kit.\n\n## Step 2 — Parse mode\n\n| Invocation | Mode |\n|---|---|\n| `/cb capture` / `/company-brain capture` / \"capture this into the team brain\" | **capture** |\n| `/cb compile` / \"compile the company wiki\" | **compile** |\n| `/cb query <q>` / \"what does the team know about X\" | **query** |\n| `/cb review` / \"review the company brain\" / \"cull the team brain\" | **review** |\n| `/cb lint` / \"lint the company brain\" | **lint** |\n| `/cb connect` / \"find cross-team connections\" | **connect** |\n| `/cb search <term>` / \"search the company brain\" | **search** |\n\n## Step 3 — Run the mode\n\n### capture\n\n**Same intake mechanics as second-brain, but the routing is different — pick the structured dir based on content type.**\n\n1. **Detect content type + route to the right dir**:\n   - Call/meeting transcript → `meetings/YYYY-MM-DD-<company-or-topic>-<slug>.md`\n   - Person's LinkedIn / bio / contact context → `people/<name-slug>.md`\n   - Company profile / prospect / client → `companies/<company-slug>.md`\n   - Documented process / how-we-do-X → `sops/<team>-<process>.md`\n   - Decision made by leadership / team → `decisions/YYYY-MM-DD-<decision-slug>.md`\n   - Verbatim customer quote → `customer-language/<theme-slug>.md` (append to existing themed file if one exists)\n   - Question asked in a call → `recurring-questions/<question-slug>.md` (append counter if repeat)\n   - Sales objection heard → `sales-objections/<objection-slug>.md` (append variant if repeat)\n   - If ambiguous, ask.\n\n2. **Add multi-author metadata** (top of file):\n   ```markdown\n   source: <URL / call with X on YYYY-MM-DD / email from Y / etc.>\n   author: <who captured this>\n   captured: YYYY-MM-DD\n   trust: unreviewed      # every capture starts unreviewed — review mode promotes it\n   sensitivity: internal  # or leadership / confidential\n   ```\n\n3. **Save + report** file path + one-line summary.\n\nDon't compile into the wiki here — capture is fast intake.\n\n### compile\n\nSame core pattern as `second-brain`'s compile mode — process unprocessed structured-raw files into wiki pages, update INDEX.md, add Sources sections.\n\n**Differences from second-brain:**\n\n- **Multi-author attribution**: Sources section includes author, not just filename\n  ```markdown\n  ## Sources\n  - `people/jane-doe.md` (added by @alex, 2026-06-30) — CTO of Acme, evaluated us Q2\n  ```\n- **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.\n- **Sensitivity inheritance**: wiki pages inherit the highest sensitivity of any source. If any source is `confidential`, the wiki page is `confidential`.\n- **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.\n- **INDEX.md categories** for teams: `Sales`, `Customers`, `Ops`, `Product`, `Team & People`, `Decisions`, `Playbooks`. Extend as needed.\n\nEverything else (one-page-per-concept, `[[wikilinks]]`, Connections mandatory, quality > quantity) is identical.\n\n### query\n\nSame as second-brain query, plus:\n\n- **Sensitivity check first**: identify the invoker; refuse to include content above their sensitivity level.\n- **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.\n- **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.\"*\n- **Author-aware answers**: when citing, include who contributed the info: *\"Per [[Acme Deal]] (source: `meetings/2026-06-15-acme-discovery.md` by @alex)...\"*\n- **Route external gaps to `deep-research`**, same as second-brain.\n\nSave to `outputs/<YYYY-MM-DD>-<question-slug>.md` with the answer + wiki pages consulted + sensitivity level of the output.\n\n### review\n\n**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.\n\n0. **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.\"*\n\n1. **Build the triage queue**:\n   - All `trust: unreviewed` files across the structured-raw dirs (including files with no `trust:` field at all), newest first\n   - Everything lint flags (checks 1–12; check 13 is about review itself)\n   - Files whose review dates have lapsed, where those fields exist: `decisions/` files past `review_by`, `sops/` files past `last_reviewed` + `review_cadence`\n\n2. **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>`:\n   - **verify** → `trust: verified`\n   - **deprecate** → `trust: deprecated` (wrong or obsolete; kept for history)\n   - **supersede** → `trust: superseded` + `superseded_by: [[target]]` (ask for the replacement)\n   - **skip** → leave as-is, resurfaces next review\n\n3. **Batch-apply the frontmatter updates** — don't rewrite file bodies, only the metadata block.\n\n4. **Flag downstream effects**: if a deprecated/superseded file feeds existing wiki pages, list those pages and offer to recompile them now.\n\n5. **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.\n\n**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).\n\n### lint\n\nSame seven checks as second-brain PLUS:\n\n8. **Stale people/companies** — `people/` or `companies/` file with no update in >6 months for active accounts\n9. **Recurring-questions above threshold** — questions asked 5+ times without a wiki page or SOP\n10. **Objections without responses** — `sales-objections/` files with no linked response in `sops/` or `wiki/`\n11. **SOP freshness** — SOPs not touched in >12 months (may be stale as the business evolves)\n12. **Author load imbalance** — one contributor doing >80% of captures (usually signals the vault is one-person-dependent — bad for team continuity)\n13. **Review backlog** — >20 files sitting at `trust: unreviewed`, or no review pass (no `outputs/*-review.md`) in >1 month. Points at `/cb review`.\n\n### connect\n\nSame 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.\n\n### search\n\nSame. Grep across all structured-raw dirs + `wiki/`.\n\n## Optional: auto-sync sources\n\nTeam vaults benefit from automated capture. See `references/auto-sync-sources.md` for the setup patterns:\n\n| Source | What it captures | Setup |\n|---|---|---|\n| **Fathom / Gong / Granola** | Call/meeting transcripts | Webhook → append to `meetings/` |\n| **Slack export** | Team discussions worth preserving | Manual or scheduled export → `raw/slack-<channel>-<date>.md` |\n| **Email (Front / Missive / Superhuman)** | Customer-facing threads worth preserving | Forward-to-address → append to `people/` or `companies/` |\n| **CRM (HubSpot / Attio / Pipedrive)** | Deal state, contact info | Periodic sync → `companies/` + `people/` |\n\nAuto-sync is optional — most teams start with manual capture and add automation as the vault matures. Pair with `loopify` to schedule periodic sync jobs.\n\n## Multi-writer git sync (team members + remote agents)\n\nA 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.\n\nThe discipline that keeps writers from diverging:\n\n1. **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.\n2. **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.\n3. **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.\n\nVerify the loop once per machine when onboarding: remote commit via API → local pull → file appears.\n\n## Composes with\n\n- **`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.\n- **`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).\n- **`loopify`** — schedule auto-sync jobs (Fathom pull daily, Slack export weekly, review pass weekly, INDEX lint monthly).\n- **`toolify`** — wire up integrations that feed the company brain (Fathom webhook receiver, Attio API, etc.).\n- **`deep-research`** — when `query` finds gaps, route external. Save deep-research results into `raw/` for future compilation.\n- **`decide`** — `decisions/` folder complements `decide`'s structured archive. `decide` records the *evaluation*; `decisions/` records the *narrative + outcome + review notes*.\n- **`pm`** — team task management sits in `Projects/` (reserved from company-brain). `pm` owns Projects/; company-brain reads it for context but doesn't modify.\n- **`jab-hook`** — `customer-language/` fuels social copy that resonates with actual prospect language.\n- A blog-drafting skill (yours or a companion plugin) — pulls from `customer-language/`, `recurring-questions/`, and `sops/` for authoritative blog drafts.\n\n## Sibling implementations (reference)\n\nSame lineage as `second-brain`:\n\n- **[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.\n- **[Hermes' `llm-wiki`](https://hermes.team)** — reference for the 3-folder pattern.\n- **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.\n\n## Notes on quality\n\n- **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.\n- **Multi-author attribution is non-negotiable.** Every file stamps `author:` and `captured:`. Wiki pages cite by source + author.\n- **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.\n- **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.\n- **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.\n- **Never modify** `Projects/`, `Team/`, `Templates/`, `Drafts/` during company-brain operations.\n- **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.\n- **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.","author":"@coreyhaines31","ownerProfile":null,"authorContacts":null,"sourceUrl":"https://github.com/coreyhaines31/makerskills/tree/main/skills/company-brain","license":"MIT","category":"coding","lang":"en","tokens":4464,"stars":0,"calls30d":2,"claimed":false,"visibility":"public","origin":"crawler","version":"0.1.0","createdAt":"2026-08-22","updatedAt":"2026-08-22","files":[{"path":"references/auto-sync-sources.md","size":4825,"sha256":"71a69ea2d3c5e1031f5bd0c69295b176579b87094d59ed4e30cde0b02fd88195"},{"path":"references/schema.md","size":8352,"sha256":"fbd7d8f7c6bacb09e632628669d7cab1f2d1251bbc084d8e4192759015b2aed7"},{"path":"references/vault-config.md","size":3148,"sha256":"46fa29440478262926a0de00b923b4127754db6224da452905ca6c29ebeb31ca"}],"requires":{"mcp":[],"tools":[]},"safety":{"flags":[],"scannedAt":"2026-08-22","hasScripts":false,"networkEndpoints":["executor.sh","hermes.team"]}}