mcpbeat Sign in

Brain:init Skill for Claude

Initialize a project_brain.db in the current project folder. Creates the database, project record, then scans existing files (CLAUDE.local.md, memory files, docs, emails) to bootstrap the brain with knowledge. Smart enough to handle re-runs — skips what already exists and only processes new/changed files.

2k tokens
context cost
the whole folder, loaded on every use
1
files
instructions only
0
copies elsewhere
how many repositories repackaged it
196
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/coco-research/coco --skill brain:init

The instruction itself

15 sections, as written by the author

/brain:init --- Initialize Project Brain

Sets up a new project_brain.db in the current working directory and bootstraps it from existing project knowledge.

Procedure

Step 1: Check existing state

Run:

python3 ~/.claude/skills/brain/scripts/brain/brain_cli.py info
  • If no DB exists → proceed to Step 2 (full init)
  • If DB exists with project(s) → skip to Step 3 (scan only). Tell user: "Brain already initialized. Running scan for new/changed files..."

Step 2: Create the database and project record

Run:

python3 ~/.claude/skills/brain/scripts/brain/brain_cli.py init

Ask the user:

  • Project name (e.g., "My Project A", "My Project B")
  • Slug (short URL-safe identifier, e.g., "my-project-a", "my-project-b")
  • Description (one-liner)

Then run:

python3 ~/.claude/skills/brain/scripts/brain/brain_cli.py add-project "{name}" --slug {slug} --desc "{description}"

If the project has sub-scopes (like ProjectA-Phase1 and ProjectA-Phase2 under one umbrella), ask if the user wants multiple project records.

Step 3: Scan the project folder

Run the scanner to discover what's available:

python3 ~/.claude/skills/brain/scripts/brain/brain_cli.py scan

This returns a JSON report with:

  • manifest_diff: new/changed/unchanged file counts, whether this is the first scan
  • files_to_process: paths of new or changed files
  • knowledge_sources: which CLAUDE.local.md, memory files, docs, and emails were found

Show the user a summary:

FOLDER SCAN
===========
First scan:     yes/no
Files found:    NN total (NN new, NN changed, NN unchanged)

Knowledge sources detected:
  CLAUDE.local.md:  found / not found
  CLAUDE.md:        found / not found
  Memory files:     N files (list names)
  Documents:        N files in docs/
  Emails:           N files in emails/
  Reference docs:   N files

If nothing to process (all unchanged): "Everything up to date. No new knowledge to extract." → done.

Step 4: Extract knowledge from sources (Claude-driven)

Process sources in priority order. For each source, read the file, extract structured knowledge, and collect proposed writes. Do NOT write to the brain yet — collect everything first.

Priority 1: CLAUDE.local.md

If found, read the full file. Extract:

  • Sections like "Key Decisions"decisions (with date, decision text, decided_by if mentioned)
  • People mentioned by nameperson entities (with metadata like role, email, team if mentioned)
  • Systems/tools mentionedsystem entities (e.g., Snowflake, Postgres, Datadog)
  • Teams mentionedteam entities
  • Folder structure sectionsdocument entities for key docs
  • Recent Changes entriesevents (with date, type, title)
Priority 2: Memory files (~/.claude/projects/.../memory/*.md)

Each memory file has frontmatter (name, description, type) and content. Read each file:

  • project type memoriesdecisions or context to enrich existing entities
  • feedback type memories → skip (these are Claude behavior guidance, not project knowledge)
  • reference type memoriessystem or document entities with metadata
Priority 3: Document inventory

For each file in docs/, emails/, and Reference Doc/:

  • Create a document entity with metadata: {"path": "relative/path", "type": "doc|email|reference", "size": N}
  • Use the filename (cleaned) as the entity name
  • Do NOT read the full content of every file — just register them in the inventory
Priority 4: CLAUDE.md (project-level, if exists)

Same extraction as CLAUDE.local.md but lower priority (may overlap).

Step 5: Present extraction summary

Show proposed writes:

BRAIN BOOTSTRAP SUMMARY
========================
Project: {name} ({slug})

From CLAUDE.local.md:
  Entities:    N (list: name [type])
  Decisions:   N (list: short text)
  Events:      N (list: title)

From memory files:
  Decisions:   N (list: short text)
  Entities:    N (list: name [type])

Document inventory:
  Documents:   N (list: filename [doc|email|reference])

Total proposed writes: NN

Ask: "Write all to brain? [Y/n/adjust]"

Step 6: Execute writes

On confirmation, write in this order using Python:

import sys
sys.path.insert(0, '$HOME/.claude/skills/brain/scripts')
from brain.schema import get_db
from brain.operations import *
  • Entities — use upsert_entity (idempotent, safe to re-run)
  • Relationships — use create_relationship (also idempotent)
  • Decisions — use create_decision (check for duplicates by matching decision text before inserting)
  • Events — use create_event (check for duplicates by matching title + date)
  • Document entities — use upsert_entity with type="document"

After all writes, sync to MemPalace and brain.json:

from brain.memory_bridge import full_sync
full_sync("project_brain.db", project_slug)

After writes complete, update the manifest:

python3 ~/.claude/skills/brain/scripts/brain/brain_cli.py scan-update

Step 7: Report

BRAIN INITIALIZED
=================
DB:            {path}/project_brain.db
Project:       {name} ({slug})
Schema:        v1 (11 tables)

Bootstrapped from existing knowledge:
  Entities:      +N (total: N)
  Decisions:     +N (total: N)
  Events:        +N (total: N)
  Documents:     +N (total: N)
  Relationships: +N (total: N)

Manifest updated: N files tracked

Next: Run /brain-update at end of session, or /brain-rescan when files change.

Step 8: Generate knowledge articles

After completing brain writes (Step 6) and confirming the manifest is updated (Step 6

scan-update), initialize the knowledge engine for this project.

First, register the project with the knowledge engine:

import sys, os
sys.path.insert(0, os.path.expanduser("~/.coco/knowledge"))
from engine import KnowledgeEngine

engine = KnowledgeEngine()
engine.register_project("{slug}", os.path.abspath("project_brain.db"))

This is required before the cron can harvest the project. (FIX M1: register_project

must be called before running any cron phases.)

Then, bootstrap article generation:

engine.full_refresh("{slug}")

Or equivalently via CLI:

python3 ~/.coco/knowledge/cron.py --run --project {slug} --phases 2,3,5

This runs:

  • Phase 2 (harvest evidence from the brain DB you just populated + infer relationships)
  • Phase 3 (generate articles for all entities — first run will generate all)
  • Phase 5 (FTS5 index the new articles)

Show the user:

KNOWLEDGE ENGINE
================
Articles generated:  N
FTS5 indexed:        N
Estimated cost:      $0.XXX

Articles written to: ~/.coco/knowledge/articles/
Search with: /brain-wiki search "{project_name}"

Skip this step silently if:

  • ~/.coco/knowledge/ does not exist (knowledge engine not installed)
  • The cron.py call fails for any reason (non-blocking — brain init still succeeds)

Important Rules

  • Dedup before writing. Always check what exists in the DB before proposing new writes. Use upsert_entity which handles this automatically for entities.
  • Don't read every file. For doc inventory, just register the file — don't parse 130KB HTML files to extract content. That's what /brain-update is for (conversation-driven).
  • Date everything. Decisions and events need dates. Parse from the source if available, fall back to file modification date, then today.
  • Memory files are structured. They have frontmatter — use the type field to decide what to extract.
  • Manifest tracks scan state. Always run scan-update after writes so the next scan is incremental.

Other skills for the same job

different authors, same section of the catalogue
Patch Release Check
by ClickHouse
vendor

Check whether ClickHouse's supported versions (last 3 majors + latest LTS) have recent stable patch releases, diagnose why the scheduled AutoReleases pipeline failed, and identify which releases must be created manually. Use when asked "are the patch releases up to date", "why did autorelease fail", "which releases are missing", "did a release get skipped", during the bi-weekly release-health check, or when investigating create_release.yml / auto_releases.yml failures. Reproduces the full investigation: supported versions from SECURITY.md, per-version staleness, classification of the last N days of AutoReleases/CreateRelease failures (version-bump-PR guard vs missing release-maker runner vs other), the Slack cross-check that reveals the blocking PR, and gated remediation (close a stale robot bump PR, dispatch CreateRelease for a missing version).

9k tokens scripts
Hackernews Intel
by Varnan-Tech

Monitors Hacker News for user-configured keywords, deduplicates against a local SQLite cache, and sends Slack alerts for new matching posts. Use when asked to monitor Hacker News for mentions, track keywords on HN, get alerts when something is posted about a topic on Hacker News, or set up HN keyword monitoring. Trigger when a user mentions Hacker News alerts, HN monitoring, keyword tracking on HN, or wants to know when a topic appears on Hacker News.

6k tokens scripts
Icp Deep Scanner
by OneWave-AI

Deep-scan any tools you connect (CRM, email, support, reviews, analytics, billing, database) to produce a data-grounded Ideal Customer Profile and a reusable persona library. Read-only by default. Use when you need to define or refresh your ICP, build buyer personas from real data instead of guesses, or generate the persona inputs that the customer-panel-of-experts and prospect-panel-simulator skills consume.

2k tokens
Background Job Orchestrator
by curiositech

Expert in background job processing with Bull/BullMQ (Redis), Celery, and cloud queues. Implements retries, scheduling, priority queues, and worker management. Use for async task processing, email campaigns, report generation, batch operations. Activate on "background job", "async task", "queue", "worker", "BullMQ", "Celery". NOT for real-time WebSocket communication, synchronous API calls, or simple setTimeout operations.

7k tokens scripts
Dt Obs Tracing
by Dynatrace

>- Distributed traces, spans, service dependencies, and request flow analysis. Use when investigating span-level details, failures, performance bottlenecks, or trace correlation. "distributed trace", "span details", "HTTP status codes in traces", "database query spans", "messaging spans", "gRPC calls", "Lambda cold starts", "trace ID lookup", "exception analysis", "correlate logs and traces", "request attributes". Do NOT use for explaining existing queries, product documentation or configuration questions, service-level RED metrics (use dt-obs-services), log searching (use dt-obs-logs), or problem analysis (use dt-obs-problems).

17k tokens
Clerk Webhooks
by clerk
vendor

Clerk webhooks for real-time events and data syncing. Verify with verifyWebhook from the framework-specific package. Handle user, session, organization, billing, and payment events. Build event-driven features like database sync, notifications, and integrations.

6k tokens
Backend Agent
by ComeOnOliver

Handles backend/API/database work for Unite-Hub. Implements Next.js API routes, Supabase database operations, RLS policies, authentication, and third-party integrations (Gmail, Stripe).

9k tokens
Things Mac
by ComeOnOliver

Manage Things 3 via the `things` CLI on macOS (add/update projects+todos via URL scheme; read/search/list from the local Things database). Use when a user asks OpenClaw to add a task to Things, list inbox/today/upcoming, search tasks, or inspect projects/areas/tags.

888 tokens

How to use it

Copy the folder

Take coco-research/brain:init from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.