/setup

name: setup
description: Bootstrap a second-brain structure inside a Baalda vault and run personalized onboarding. Creates all directories, system files, per-folder routing indexes and starter context, then interviews the user to personalize everything. Two modes — Solopreneurs/Professionals (default), Business/Teams. Use when the user says "set up my Baalda vault", "set up my second brain", "bootstrap", "initialize", "onboarding", or runs /setup.
disable-model-invocation: true

Baalda OS — Setup + Onboarding

USE WHEN the user runs `/setup` or asks to set up their Baalda vault, bootstrap the second brain, initialize the system, or turn a folder of notes into an AI-operated OS.

Baalda notes are plain `.md` files on disk, so everything this skill builds is just files and folders — no plugins to install, no import step. The moment you write them, the app indexes them, and if the vault is synced they appear for every teammate live.

Baalda ground rules (read once, obey throughout)

These are app invariants, not preferences. Breaking them corrupts note identity or the sync state.

1. **Run from the vault root.** The vault root is the folder the user opened in Baalda. Everything below writes relative to it. If the current directory isn't that folder, stop and ask. 2. **`.context/` is off-limits.** Baalda keeps its SQLite index, CRDT store and `config.json` in `<vault>/.context/`. Never read, write, walk, move, index, or `git add` it. Same for `.git`. 3. **Write files, don't shell out to move them.** Creating and editing `.md` files with normal tools is fully supported — the watcher picks the change up in ~150ms and merges it as a CRDT operation, so an AI edit and a human keystroke coexist instead of clobbering. 4. **Never `mv` or `rm` a note that is already synced.** A note's identity is a `doc_id`, not its path. An external move looks like *delete + create* to the app: the note gets a **new** `doc_id`, and its history, backlinks and share settings do not follow. Rename and move synced notes **in the app**, or through the `move_note` / `move_folder` tools if this session is connected over Baalda's MCP endpoint. During first-time setup on a brand-new vault there is nothing to fork yet, so the `mkdir`s below are safe. 5. **Attachments live in `attachments/`.** Images and files the user drops into a note land there. Leave that folder alone; it is not part of the note pipeline. 6. **Markdown Baalda understands:** YAML frontmatter, `[[wikilinks]]` (backlinks + graph view are derived from them), `#tags`, and standard CommonMark. Prefer wikilinks over relative paths so links survive a later move.

---

This is a three-phase process:

• **Phase 0**: Mode Selection — Ask which OS variant to create
• **Phase A**: Bootstrap — Create the directory structure and system files for the selected mode
• **Phase B**: Onboarding — Interview the user and personalize everything

Pre-flight Check

First confirm **where** you are. Print the current directory and check for `.context/`:

pwd && ls -a | grep -E '^\.context$' || echo "no .context/ — not yet opened in Baalda"

• **`.context/` exists** → this folder is a Baalda vault. Good, continue.
• **No `.context/`** → the folder has never been opened in Baalda. That's fine: build the OS here

anyway, and at the end tell the user to open this exact folder in Baalda (**Open vault**), which creates `.context/` and indexes everything you just wrote. Do not create `.context/` yourself.

Then check if `claude.md` or `CLAUDE.md` exists **only** in the current working directory (do NOT search subdirectories or parent directories — check only the exact CWD path).

• **If it exists**: The vault is already set up. Ask the user:
• "This vault is already set up. Would you like to:"
• **Re-run the interview** — Keep existing structure, update memory files based on new answers
• **Full reset** — Delete everything and start fresh (confirm twice before proceeding)
• **Cancel** — Do nothing
• **If it does NOT exist**: Proceed with full setup (Phase 0 + Phase A + Phase B)

---

Phase 0: Mode Selection

Ask the user to pick a mode using AskUserQuestion with these exact `label` and `description` values:

• Question: `What type of vault do you want?`
• Option 1 label: `Solopreneurs/Professionals` — description: `Blends work and personal. Best for solo founders, freelancers, consultants.`
• Option 2 label: `Business/Teams` — description: `Org structure with departments, processes, stakeholders. Best for teams and companies.`

**CRITICAL**: You MUST pass both `label` AND `description` for each option in AskUserQuestion. The `description` field is what explains each mode to the user. Never leave `description` empty.

Mode mapping:

• Solopreneurs/Professionals → `os-mode: professional`
• Business/Teams → `os-mode: business`

Accept any clear signal: "solo", "professional", "freelancer", "business", "org", "team", etc.

If the user skips or says "I don't know", use **Solopreneurs/Professionals** (professional mode).

Store the selected mode. It will be written to `CLAUDE.md` frontmatter as `os-mode: professional | business`.

---

Phase A: Bootstrap

Create the directory structure and write all system files for the selected mode.

Resolving reference file paths

Every `references/<file>.md` mentioned below lives in the `references/` subdirectory next to **this SKILL.md** — not in the user's working directory. Two conventions matter:

• **Read paths** (`references/foo.md`) → resolve relative to this SKILL.md's directory.
• **Write paths** (`./Foo/CLAUDE.md`) → resolve relative to the user's current working directory (the vault root).

If the Read tool can't open a `references/...` path directly (some harnesses mount the skill at a path that differs between Read and Bash), run a quick discovery step **once** before Step A.2:

# Find the references directory; cache the result for the rest of Phase A.
find