CLAUDE.md git:20260818.2d55cd9A

Immutable. This exact content is served forever at /api/v1/blob/49089de7b3c308c5.

# ai-brain-starter — Claude Instructions

## Public repo rules — NEVER HARDCODE PERSONAL CONTEXT

This is a **public repo** that strangers fork to build their own vaults. The whole point is that it must work for people who are NOT the maintainer and are NOT on the maintainer's team.

**Before writing or editing ANY file in this repo, scan for and remove:**
- Personal names (the maintainer, their co-founders, their team, their advisors, their family)
- Company names the maintainer is affiliated with
- Personal vault and folder paths — the maintainer's own vault name, their team-folder name, any emoji-prefixed folder specific to one person's structure. **Every folder in a user's vault is named by that user at install time.** Never hardcode one, not even as a fallback: read it from config, detect it structurally, or take it as an argument. A hardcoded folder name is dead code for everyone except the person who wrote it.
- Personal frameworks the maintainer invented (a bespoke rating scale, a private roster of named advisors)
- Specific cities, countries, or geographies that aren't universal
- Substack URLs and personal blog links other than what already exists in the README/SKILL.md welcome message
- Real meeting names, real decision content, real strategic context
- Anecdotes that name real people or real situations

**When you need to illustrate a pattern with an example, invent a fictional one.** Generic placeholders ("a Google Drive shared folder", "a team member", "a co-founder") are always preferred over real names. If a fictional example would be confusing without context, use a clearly-marked one (`# Example only — replace with your own`).

**Existing files that pre-date this rule may have personal references** (the README's Background section names the maintainer as legitimate authorship attribution; the LICENSE carries their copyright; the CHANGELOG narrates the actual history of the repo's development). Don't touch those — they're load-bearing context. The rule applies to **new** content you add.

**The narrative CHANGELOG is the one place narrative context is OK** because it's a historical record of what shipped when. But even there, prefer "the maintainer" or "a team member" over names when possible.

If you catch yourself writing "this is what [name] does," stop. Rewrite it as a generic pattern. The repo is for strangers, not for the maintainer's team.

## Git in large Obsidian vaults (users' vaults, not this repo)

Many users of this skill will have their Obsidian vault under git for local snapshots (the Phase 5 setup suggests it). Obsidian vaults commonly grow to 10,000+ files between journal entries, attachments, book notes, and plugin caches (`.smart-env/`, `.obsidian/workspace*`, etc.). Walking that full tree with `git add -A` or unscoped `git status` takes minutes of CPU, locks `.git/index.lock`, and wastes a lot of assistant context polling for progress.

**Rules when operating in a user's vault:**
1. Never run `git add -A`, `git add .`, or unscoped `git status`. Always pass explicit file paths you intend to stage.
2. If a vault has no git remote (`git remote -v` empty), never attempt `git push`. Vaults are commonly local-only snapshot repos.
3. When `git` is slow, check `wc -l <(git ls-files)` — if >10k files, you are in a vault repo; switch to targeted paths immediately.
4. The session-close template (`templates/rules/session-close.md` or the user's equivalent) must include the "targeted-paths only" pattern for any git snapshot step. If a new setup phase is introducing git automation, ship the rule with it.

These rules ship to every user's vault CLAUDE.md via Phase 4 / `templates/generated/claude-md-template.md`. Keep them generic (no personal paths) per the public-repo rule at the top of this file.

## Repo structure rules

**Before creating any new file or folder, always check what already exists:**

1. Run `ls` on the root to see top-level structure
2. Check `SKILL.md` (thin orchestrator) and `phases/` (one file per phase group)
3. Check `templates/generated/` for embedded templates extracted from phases

**The pattern:** `SKILL.md` is a thin router that tells Claude which phase file to read next. Each phase file lives in `phases/` and is under 10k tokens (one Read call). Large embedded templates (CLAUDE.md template, insights skill, obsidian rules, team-weekly skill) live in `templates/generated/` and are referenced by pointer from the phase files. Adding a new phase means creating a file in `phases/` and adding a row to the routing table in `SKILL.md`.

## Setup phase files (phases/)
- `phase-00-install.md` — install efficiency tools (brew, python, node, graphify, MCPs)
- `phase-01-welcome.md` — language detection, mode detection, welcome interview
- `phase-02-03-plugins-folders.md` — Obsidian plugins + folder structure
- `phase-04-claude-md.md` — build user's CLAUDE.md
- `phase-05-context-layer.md` — context notes, hooks, aggregator scripts
- `phase-06-09-tools-templates.md` — tool routing, imports, templates, skill verification
- `phase-10a-journaling.md` — daily journaling setup (interview, floor framework, skill)
- `phase-10b-panel-roster.md` — advisory panel roster + voice routing
- `phase-11-external-tools.md` — email/calendar/Slack/CRM, meeting tool wiring
- `phase-12-17-imports-rules.md` — book notes, health, taxonomy, backup, obsidian rules
- `phase-18-insights.md` — weekly/monthly insights + cron
- `phase-19-23-finish.md` — test drive, team vault, patterns, theme, second-brain-mapping install (23.5), first-week handoff with recommended uses (24)

## Generated templates (templates/generated/)
- `claude-md-template.md` — CLAUDE.md skeleton used by Phase 4
- `obsidian-rules-template.md` — Obsidian + efficiency rules appended by Phase 16
- `insights-skill-template.md` — insights SKILL.md generated by Phase 18
- `team-weekly-skill-template.md` — team-weekly SKILL.md generated by Phase 20

## Current standalone sub-skills (skills/)
- `skills/meeting-todos/SKILL.md` — extract action items from meeting notes
- `skills/patterns/SKILL.md` — Instinct Engine for pattern extraction
- `skills/graphify/SKILL.md` (+ scripts + RUNBOOK.md) — knowledge graph builder
- `skills/insights/SKILL.md` — weekly/monthly journal insights
- `skills/deconstruct/SKILL.md` — first-principles analysis
- `skills/daily-journal/SKILL.md` — daily journal interview
- `skills/repurpose-talk/SKILL.md` — turn talks into content pieces
- `skills/nano-banana/SKILL.md` — image generation via Gemini

## Reference docs (for users, not embedded in SKILL.md)
- `docs/POWER_TOOLS.md` — catalog of every third-party skill, MCP server, Obsidian plugin this setup uses, with attribution and install commands
- `docs/MEMORY_SYSTEM.md` — typed-memory pattern for persistent cross-session knowledge
- `templates/dataview-queries.md` — reusable Dataview query library
- `templates/Decision Log.md` — template for tracking decisions over time
- `scripts/build-journal-index.py` — index builder for `/insights`-style skills
- `skills/graphify/RUNBOOK.md` — production playbook for big graphify runs