/company-brainify

name: company-brainify
version: 1.0.0
description: >
  Extract a sanitized shared team/company brain from a personal brain.
  Strips internal ratings, compensation, performance assessments, retention
  and political dynamics from pages, takes, and facts across the full scan
  scope (people, companies, meetings, dailies, cross-references — not just
  people/), verifies with grep + retrieval passes, and purges sensitive git
  history behind the data-loss-gate confirmation card. Also runs as a
  report-only re-audit on an existing shared brain.
triggers:
  - "company brain"
  - "team brain"
  - "brainify"
  - "sanitize the brain"
  - "share my brain with the team"
  - "strip sensitive data from the brain"
  - "scrub employee data"
  - "audit the shared brain"
  - "make the brain safe to share"
mutating: true
writes_pages: true
writes_to:
  - people/
  - companies/
  - meetings/
  - daily/
  - projects/
  - analysis/
upstream: company-brainify@fc834ee
# Brain-first in its native form: Phase-1 discovery runs through gbrain
# retrieval (query/search/takes search/recall), and every edit is grounded
# in a full read of the actual page. writes_to lists the scan scope the
# skill edits IN PLACE — it does not create new pages there, except the
# deletion-log entry under daily/ required by data-loss-gate Step 4.
brain_first: true

company-brainify — Personal → Team-Brain Sanitization

> **Convention:** see [conventions/brain-first.md](../conventions/brain-first.md) — > discovery runs through the brain's own retrieval, not filesystem guesswork. > The grep pipelines below TRIAGE; `gbrain query` finds what keyword patterns miss. > > **Convention:** see [conventions/test-before-bulk.md](../conventions/test-before-bulk.md) — > sanitize 3-5 files, read the output yourself, then ramp. A bad bulk > sanitization pass is worse than none: it looks done and isn't. > > **Convention:** see [conventions/regex-discipline.md](../conventions/regex-discipline.md) — > "is this sensitive?" is a judgment call, so the model decides per file. The > grep patterns are earned triage/verification tools, never the judge. > > **Convention:** see [_brain-filing-rules.md](../_brain-filing-rules.md) — > edits stay in the page's existing directory; the deletion log files > date-keyed under `daily/`.

The Problem

Personal brains accumulate everything — company knowledge, meeting notes, internal assessments, compensation details, management strategy, candid opinions about the people you work with. When you stand up a shared team brain from that personal brain (see `docs/architecture/brains-and-sources.md` for the team-mount topology), all of that has to go. The knowledge is valuable; the sensitive metadata is a liability.

Clean working-tree files alone are NOT enough: git history still carries every pre-sanitization version, and gbrain takes/facts carry evaluative claims outside the page prose. This skill handles all three surfaces — pages, takes/facts, and history.

When to Use

Connecting or indexing an existing company repository without editing it is not sanitization. For “connect our company brain” or “import an existing company brain,” use the migrate (host-side) company workflow. On the trusted brain host, start with `gbrain sources inspect <path> --profile company-brain`; follow `docs/guides/company-brain-ingestion.md` for destination preview and approval. Do not strip metadata or purge history merely to make an existing repository searchable.

• Standing up a shared company brain from a founder/exec's personal brain
• Auditing an existing shared brain for sensitive content that shouldn't be there
• Onboarding new team members to a brain repo that must be verified clean first
• Periodic hygiene pass on a shared brain that re-accumulates sensitive data

What Gets Removed

Always strip (non-negotiable)

| Category | Examples | |----------|----------| | **Internal scores/ratings** | `score:`, `rating:`, `skill:`, or any vertical-specific `*_score:` frontmatter field; any numeric rating of a person | | **Compensation** | Salary, equity, carry, option grants, comp changes, retention packages | | **Performance assessments** | Strengths/weaknesses sections about employees, "at risk" flags, underperformance mentions, "picking up slack" references | | **Departure/retention** | Who's considering leaving, who was convinced to stay, departure rumors, retention conversations | | **Management strategy** | How-to-manage-someone sections, "the hard conversation" notes, scope/title management plans | | **Internal political dynamics** | Who doesn't like whom, who's nervous about whom, adversarial relationships, power dynamics | | **Personal PII** | Phone numbers, personal email addresses, home addresses, family or medical details, personal legal matters, personal-life details | | **Takes/facts** | Any take or fact referencing the above categories — performance, comp, retention, weakness, management risk. Fact rows are DELETED from the page's Facts fence, never merely expired with `gbrain forget` |

Always keep

| Category | Examples | |----------|----------| | **Professional identity** | Name, role, title, work email, LinkedIn | | **What they're building** | Current projects, product work, technical contributions | | **Career arc** | Prior companies, education, professional background (public info) | | **Professional beliefs** | Their views on technology, strategy, product philosophy | | **Timeline of work** | Meeting attendance, project milestones, launches (factual, not evaluative) | | **Skills/expertise** | Technical capabilities, domain knowledge |

Scan Scope — Wider Than people/

Sensitive content leaks far beyond people pages. The scan scope is:

• `people/` — the primary surface (frontmatter fields, assessment sections)
• `meetings/` — transcripts and minutes with candid assessments
• `daily/` — daily notes referencing comp/performance/retention conversations
• `companies/`, `projects/`, `analysis/` — cro