--- name: mb-setup description: "Bootstrap a new business repo with Main Branch structure, or migrate an existing single-offer repo to multi-offer. Use when: (1) New user needs Claude Code environment configured (2) User says \"set up\", \"get started\", \"initialize\", \"bootstrap\", \"create my repo\", \"new business\" (3) User is new to Main Branch and needs full onboarding (4) Migrating existing business context into the Main Branch structure (5) User wants to add a second offer to an existing repo. Creates Chrome extension setup, two-repo model, business repo with full structure. Gathers bounded context until core files are useful. Applies business setup patterns. Teaches concepts during setup." loops: [sense, decide, ship] --- # Repo Setup Get a new user fully configured with Claude Code and their business repo. Use `mb onboard status --json` and `mb onboard plan` as the durable progress contract; do not keep onboarding state only in chat prose. For provider setup, use `mb connect plan` and `mb connect doctor --json` as the durable readiness contract. Explain providers as business capabilities, not developer config, and end with exact commands. --- ## Before We Begin **Need help?** Type `/mb-help` + your question anytime. If conversation compacts (gets summarized), `/mb-help` reloads fresh context. --- ## Workflow ### CRITICAL: Write Boundaries in Sandboxed Environments Some tools (especially workspace-isolated apps, like Conductor workspaces) may only allow direct file writes inside the current workspace folder. If you see: > "Cannot edit files outside allowed directories" In a regular terminal `claude` session, this is less common because Claude can often request permission and continue. In restricted workspace tools, limits are usually stricter. Do **not** silently switch strategies. Ask the user first, in beginner language: > "This app is only letting me edit files in this one workspace folder. > > Since this is first-time setup, switching workspaces mid-chat can be confusing. The easiest options are: > 1. Continue here and I use terminal commands to create/update files in your target repo path > 2. Stop here, open Terminal in the target repo folder, run `claude`, then run `/mb-setup` again > > If you already have a workspace open for that repo, we can use that too. Which option do you want?" For first-time setup, do not default to "switch workspace now." Prefer option 1 or 2 unless the user already has the target repo workspace ready. ### Pull Latest Engine Updates and Detect CWD (FIRST) **Repair Main Branch wiring + detect CWD before context gathering.** Three cases: CWD is the business repo (happy path), CWD is the engine repo (migration), or CWD is neither (ask user). See **[references/cwd-detection.md](references/cwd-detection.md)** for the full repair path and all three cases (Case 1 happy path, Case 2 engine migration, Case 3 ask). This must happen BEFORE any context gathering — if conversation compacts later, the essential config is already saved. --- ### 0. Check Chrome Extension (Optional, Helpful for Skool) **Before gathering context, mention the Chrome extension:** > "The Claude in Chrome extension lets me read your sales pages, Skool community, and web content directly. It's optional but helpful. > > To check if it's installed: open Chrome, go to `chrome://extensions`, and look for 'Claude'. If you don't have it: https://claude.ai/chrome" **If not installed or user declines:** Proceed with URL fetching, Playwright, or manual screenshots. The extension is convenient but not required. ### 1. Confirm Git + Working Directory ```bash git status # Verify we're in a git repo pwd # Confirm working directory ``` If not a git repo: ```bash git init ``` ### 1a. Check Optional Tools (Inform, Don't Block) **Local transcription (for mining your own recordings):** ```bash which mlx_whisper 2>/dev/null || which whisper-cli 2>/dev/null; which ffmpeg ``` If missing, note for later: > "Optional: For transcribing your own videos/voice memos, you'll want a whisper variant. `pip3 install mlx-whisper` is fastest on Apple Silicon. We can set that up later with `/mb-think`." Don't block setup on this. Continue and mention it at the end. ### 2. Ask Business Type > What type of business is this? | Type | Setup Pattern | |------|---------------| | **Community/Skool** | Classroom, membership, funnel | | **E-commerce** | Products, fulfillment, materials | | **Coaching/Services** | Offers, delivery, packages | | **Agency** | Services, clients, processes | | **Other** | Core only, no extra operating folders | **IMPORTANT:** If user has a Skool community, choose **Community/Skool** even if they also do coaching, courses, or services outside Skool. The community is the hub — other offerings feed into it. Read `.claude/reference/business-primitives/setup-patterns.md` in the Main Branch engine for the current setup patterns. Read `.claude/reference/business-primitives/slug-conventions.md` before naming offer folders, pushes, bets, or topology entries. ### 2.5: Offer Structure After business type, determine offer structure: > "How many distinct products or services do you sell?" **If one:** "Single offer — clean and simple. All your details go in `core/`. Most people start here." **If multiple:** "Multiple offers under one brand. You share the same soul and voice, but each offer has its own specifics." - Ask: "What stable noun should name each offer? Use lowercase kebab-case slugs like `community`, `newsletter`, or `done-for-you`; do not rename later without a decision." - Ask: "How do these relate? Is there a natural progression — like a free tier that feeds into a paid one?" (This builds `product-ladder.md`) - Store offer names for Step 4 folder creation - Note: The multi-offer rules live at `.claude/reference/business-primitives/offer-bet-push-proof.md` in the Main Branch engine; read it if the user has multiple offers **Multi-business check (brief, not interrogating):** > "Are any other business repos relevant right now? If you run completely separate brands, they each get their own repo. We're setting up this one." This check is simple and non-intrusive. If they say yes, note it and move on — they can run `/mb-setup` again in the other repo later. ### 3. Gather Bounded Context Your job is to collect enough to create useful core files, not every fact possible. Users provide context in batches. Keep the first pass bounded by `mb onboard status --json` and its missing inputs. Before asking for data, run: ```bash mb onboard status --repo "$REPO_PATH" --json ``` If business type, team size, success stage, or desired outcome are missing, ask briefly and save them: ```bash mb onboard plan --repo "$REPO_PATH" --team-size solo --success-stage working ``` Do not ask for full finances, credentials, raw customer/member exports, or exhaustive operations details during first-pass onboarding. See **[references/context-gathering.md](references/context-gathering.md)** for: - URL fetching fallback chain (WebFetch → Chrome → Playwright → manual) - Business-type specific checklists (Skool, E-commerce, Coaching) - Completeness criteria **Opening prompt:** > Share the essentials for the core files: what you sell, who it helps, why > it works, proof you can share, and a few voice samples. > > **Pro tip:** You can drag screenshots directly into this terminal window and I'll read them. If you have a Skool community, screenshot your about page, classroom, pricing — drag them all in. Fastest way to get me up to speed. > > Paste text, share file paths, give me URLs to fetch, or drag in images. I'll sort it all into the right files. **After each batch, assess gaps:** > "Got it. I still need [X, Y, Z] to complete your core files. Can you share those?" **Only say "we have enough" when you can fill:** - offer.md (price, mechanism, deliverables, guarantee) - audience.md (who, pains, desires, objections) - voice.md (tone, phrases, personality) - testimonials.md (3-5 with specific outcomes) - core/operations/ (business-type specific structure) ### 4. Create Folder Structure ```bash # Always create: mkdir -p core core/offers core/finance core/brand core/proof/angles core/operations mkdir -p research decisions bets log pushes documents ``` Do not create a canonical `reference/` folder in new repos. If an old repo already has `reference/core` or `reference/offers`, treat those paths as legacy compatibility aliases and write user context once under `core/` or `core/offers/`. **Multi-offer only (if user has multiple offers from Step 2.5):** ```bash # Create offer folders for each offer for offer in [offer-names]; do mkdir -p "core/offers/$offer" done # Ask before persisting active-offer state. Offer choice can stay session-scoped. # Do not write .vip/local.yaml as the active-offer mechanism. # Keep the choice session-scoped unless a future mb command exposes an explicit # session-state contract and the operator confirms persistence. # Create product-ladder.md placeholder at core/product-ladder.md touch core/product-ladder.md ``` Full structure (single-offer): ``` {business-name}/ ├── CLAUDE.md # Always loaded - business brain ├── README.md # Human-readable overview ├── .env # Secrets (gitignored) ├── .gitignore # Include .env │ ├── core/ # Evergreen business brain │ ├── soul.md # Why you exist │ ├── offer.md # What you sell / brand thesis │ ├── audience.md # Who buys │ ├── voice.md # How you sound │ ├── content-strategy.md # Content pillars, platforms, cadence │ ├── proof/ │ │ ├── testimonials.md │ │ └── angles/ # Proven messaging entry points │ ├── brand/ # Visual identity and brand systems │ ├── operations/ # Business-type specific operating context │ ├── finance/ # Ledger and tax artifacts │ └── offers/ # Per-offer specifics when multi-offer │ ├── research/ # Dated investigations │ └── YYYY-MM-DD-topic-[source].md │ ├── decisions/ # Dated choices with rationale │ └── YYYY-MM-DD-topic.md │ ├── bets/ # Operating bets with target, deadline, and result │ └── YYYY-MM-DD-topic.md │ ├── log/ # Running activity log │ └── pushes/ # Coordinated pushes and their artifacts └── YYYY-MM-DD-push-name/ ``` Full structure (multi-offer — adds offer folders and `product-ladder.md`): ``` {business-name}/ ├── ... # Same as above, plus: ├── core/ │ ├── product-ladder.md # How offers relate │ └── offers/ # Offer-specific overrides │ ├── community/ │ │ └── offer.md # Offer-specific details │ └── course/ │ └── offer.md ``` ### 4a. API Key Environment, Config, and .gitignore See **[references/repo-scaffolding.md](references/repo-scaffolding.md)** for: - API key environment setup (`~/.config/vip/env.sh`) - Legacy `.vip` cleanup guidance - `.gitignore` creation Run these steps in order: create env.sh when needed, add shell source line when approved, and create `.gitignore`. Do not create `.vip/config.yaml` for new repos. ### 5. Sort Content into Files **The repo is a precision instrument, not a dumping ground.** Not everything the user provides makes it into core files. Filter for what helps LLMs produce great outputs. Use templates from `references/templates.md`. **Teach WHY each file matters as you create it.** Don't just scaffold — explain. This is the user's first encounter with the system. The act of writing these files IS the learning. See **[references/file-education.md](references/file-education.md)** for the educational blurbs to present before writing each core file (soul, offer, audience, voice, multi-offer additions), the priority order, and the visual style scaffolding questions. ### 6. Apply Business Setup Pattern Based on business type, create useful operating folders: **E-commerce:** `core/operations/products/`, `core/operations/fulfillment/` **Community:** `core/operations/classroom/`, `core/operations/membership/`, `core/operations/funnel/`, `core/content-strategy.md`, `core/operations/funnel/skool-surfaces.md` See `.claude/reference/business-primitives/setup-patterns.md` in the Main Branch engine for current setup patterns. Historical engine builds may still contain older compatibility notes under paths that use the word "domain"; treat those as migration notes only, not the current product model. ### 7. Draft CLAUDE.md See `references/claude-md-guide.md` for structure. **Key sections:** - One-line description - Engine reference (Main Branch) - Folder structure diagram - Business summary - Quick reference (audience, voice, offer) - Key decisions/research index - Reference tiers ### 8. Create README.md Simple human-readable overview: - What the business is - How to use the repo with Main Branch - Quick stats ### 9. Initial Commit ```bash git add -A git commit -m "$(cat <<'EOF' [init] Bootstrap business repo with Main Branch structure - Created core/ (soul, offer, audience, voice) - Created core/offers/ (per-offer specifics) - Created core/proof/ (testimonials, angles) - Created core/operations/ ([business-type] specific) - Drafted CLAUDE.md and README.md Co-Authored-By: Claude Opus 4.5 EOF )" ``` ### 10. Report Gaps | File | Status | |------|--------| | core/soul.md | [OK] Complete / [WARN] Missing [X] | | core/offer.md | [OK] Complete / [WARN] Missing [X] | | core/audience.md | [OK] Complete / [WARN] Missing [X] | | core/voice.md | [OK] Complete / [WARN] Missing [X] | | core/proof/testimonials.md | [OK] Has content / [FAIL] Empty | | core/proof/angles/ | [OK] [N] angles / [WARN] None yet | | core/operations/ | [OK] Populated / [WARN] Needs [X] | **Multi-offer additional checks (if applicable):** | File | Status | |------|--------| | core/offers/[name]/offer.md | [OK] Complete / [WARN] Thin (< 20 lines) / [FAIL] Missing | | core/product-ladder.md | [OK] Complete / [WARN] Placeholder | | active offer | [OK] Selected for session / [INFO] Not persisted | Ask user for missing pieces or note for later. --- ## Git Workflow Format: `[type] Brief description` with Co-Authored-By line. Types: `[init]`, `[add]`, `[update]`, `[fix]`, `[refactor]`, `[docs]`. See `references/git-workflow.md` for full guide. --- ## References - **CWD Detection:** `references/cwd-detection.md` — Check engine updates + Case 1/2/3 flows for detecting where the user is - **File Education:** `references/file-education.md` — What to teach the user about each core file, priority order, visual style scaffolding - **Context Gathering:** `references/context-gathering.md` — Checklists by business type, completeness criteria - **Templates:** `references/templates.md` — All file templates - **CLAUDE.md Guide:** `references/claude-md-guide.md` — How to draft a good CLAUDE.md - **Git Workflow:** `references/git-workflow.md` — Commit messages and CLI usage - **Repo Scaffolding:** `references/repo-scaffolding.md` — API keys, config.yaml, .gitignore - **Multi-Offer Migration:** `references/migration-multi-offer.md` — Single to multi-offer migration --- ## Recovering from Compaction If conversation compacts mid-setup: **For the user:** Type `/mb-setup` again and describe where you were: - "We're in the middle of gathering context for my Skool community" - "I was giving you screenshots, you hadn't created files yet" - "You created the folder structure but we haven't sorted content" **For Claude:** When resuming: 1. Check if business repo exists (look for `core/`, with legacy `reference/core/` fallback) 2. If exists, check which files are populated vs empty 3. Resume from the appropriate step based on what's done 4. Confirm with user: "I see [business-name] with [X] files. Looks like we're at step [N]. Continue?" --- ## Migration: Single-Offer to Multi-Offer When an existing user wants to add another offer (says "I want to add another offer", "I have a second product", or similar), follow the migration guide. See **[references/migration-multi-offer.md](references/migration-multi-offer.md)** for the complete migration flow: detection, naming, atomic execution, brand-level offer.md creation, product-ladder.md, and commit. --- ## After Setup: What's Next Once setup is complete, tell the user: > "Your business repo is ready! Here's what to do next: > > **Daily workflow:** > ``` > cd ~/Documents/GitHub/[business-name] > claude > /mb-start > ``` > Main Branch linkage is managed by setup (`settings.local.json` + compatibility bridge links) — no need to touch the Main Branch engine folder. > > **Key skills to try:** > - `/mb-think` — Research topics, make decisions, update reference > - `/mb-think` — Build your content strategy (pillars, platforms, cadence) — start here after core files are solid > - `/mb-ads` — Generate image ads, video scripts, or review for compliance > - `/mb-vsl` — Write video sales letters (Skool or B2B) > - `/mb-organic` — Create social content aligned to your content pillars > - `/mb-help` — Get answers anytime you're stuck > > **The core loop:** Use `/mb-think` regularly. Research → Decide → Codify. This is how your core files get smarter over time. > > **Remember:** Type `/mb-help` + your question anytime. It has comprehensive answers about Terminal basics, the two-repo model, skills, troubleshooting, and more." **If whisper-cpp was missing during setup:** > "One more thing: To transcribe your own videos and voice memos, install whisper-cpp: > ```bash > brew install whisper-cpp ffmpeg > mkdir -p ~/.whisper > curl -o ~/.whisper/ggml-base.en.bin -L \ > 'https://huggingface.co/ggerganov/whisper.cpp/resolve/main/ggml-base.en.bin' > ``` > Then `/mb-think` can mine your recordings directly." **If the user wants image generation:** > "Want to generate actual images for ads and content? See `references/nano-banana-setup.md` for Nano Banana setup (uses your existing Google API key)."