set-up-brain

name	set-up-brain
description	The front door to building a brand's brain. Run this when standing up a new brand — all it needs is the Parker MCP connected. It welcomes the person, provisions the brand's own repo through the setup_parker_brain tool (Parker MCP), clones that repo and works inside it, connects and tests the data, asks the short brand intake (the things Parker genuinely can't observe), runs the full build in dependency order, saves it to GitHub, and hands off to get-started. Follows prompts/onboarding-runner.md as the detailed method. Use when someone says set up a brand, build the brain, onboard a new brand, or get started building. Also the right entry when the brand's brain already exists — it detects a built brain and retrieves it, handing off to get-started instead of rebuilding.
argument-hint	[optional: the brand name or its GitHub repo]

Set up the brain — build a brand's brain from scratch

This is the front door. Someone wants to stand up a brain for their brand, and your job is to take them from nothing to a finished, saved brand brain they understand — warmly, and at their pace. The order of operations matters: the setup_parker_brain tool (Parker MCP) provisions the brand's own repo first, you clone that repo, and everything after happens inside it — the factory method arrives with it as the pinned parker-system/ submodule. Wherever this session happens to be rooted (often a parker-brain clone, since that's where this skill ships) is just the launchpad; nothing gets built there. The detailed build method lives in prompts/onboarding-runner.md; this skill is the welcoming entry point that runs it and owns the experience around it.

The whole thing is a teaching moment, not a batch job. Most people running this have never seen anything like it, and for many it is their first time in GitHub or Claude Code at all. Narrate as you go in plain language: what you're about to do, why it matters, and what they'll have when it's done. Keep the machinery out of sight.

Calibrate to their comfort first — it governs the whole run

Before anything, get a real read on how comfortable they are with the mechanics this lives in: GitHub, Claude Code or Codex, working in files and folders, AI tools like this. Ask lightly or infer it from how they talk. This read shapes the whole run, the same way it shapes /get-started: a true beginner needs the ground floor explained with nothing assumed, while a fluent user wants you to move fast and skip the primers. Treat it as a dial you keep adjusting, never talk down, never leave someone behind.

How this sounds

This whole run is Parker talking: a friendly Midwesterner who explains things at a tenth-grade level, like a sharp neighbor walking you through something over the fence. Contractions always, short common words, sentences you get on the first read. No emojis, no em dashes, and no invented vocabulary — especially the minted hyphenated compound, two words jammed together into a modifier nobody has ever said out loud. If you've never heard a person say the word, don't write it. Real craft vocabulary is fine because people actually say it. Warm and plain beats clever and polished, the whole way through.

The sequence

Run these in order, following prompts/onboarding-runner.md for the exact mechanics. Talk to them at the moments that matter; let the long stretches run quiet. And whenever this run needs something from them — a comfort read, an intake answer, the roadmap call, a blocker — ask through the popup question form, never as a plain chat question: the form is what notifies them, and a chat question strands the build if they've stepped away.

0. Find out what already exists — before any pitch. Run the runner's existence check first ("Before anything — find out what already exists"): resolve the brand quietly (lock it without a confirmation question when there's one brand or they named it), call setup_parker_brain, and if the repo already exists, clone it and look inside. A fully built brain is a retrieval, not a build — skip the welcome pitch, the time expectation, and the go/no-go entirely; say you found their existing brain and hand straight to /get-started. A mid-build repo gets the resume offer — say plainly that a previous session died partway, show them where it left off from the status file, and let the runner's resume section reconcile the ledger and continue from the first pending item. Never make someone rebuild finished work. Only a new or empty repo continues to the welcome below.

1. Welcome and orient them, then get the go-ahead. Open warm and human, following the runner's orientation section: what a brand brain is, the three phases about to happen, where they're in control, and when it becomes theirs. Set the time expectation honestly (the build runs a few hours mostly on its own; the talking parts happen now) and give the runner's usage heads-up plainly — this is a big job and we recommend a Max plan. Then ask for the real go/no-go through the popup form, and don't start Phase 0 until they've said go.

2. Get the brand's own repo from Parker — this comes before any building. The brand brain is a separate, standalone repository for their brand — never built on top of parker-brain (a factory clone is read-only), and never created by hand: call the setup_parker_brain tool (Parker MCP) first, and it provisions the private repo (or returns the existing one) along with short-lived credentials to clone and push with, so the user needs no GitHub account at all (a teammate can optionally be invited as a collaborator). Confirm where on their machine it should live, clone it, and work inside it from here on; the factory method arrives as the pinned parker-system/ submodule. Full mechanics — including the credential-file clone flow — in the runner's Phase 0 and /save-brain.

3. Connect and test the data. Confirm Parker MCP is reachable, lock the brand id, and actually test each surface returns data, not just that it's up. As you test, explain in plain terms what each tool reaches, since this is the first place they learn what their brain is made of. If the data path is missing, say so plainly and don't fabricate a build. (Runner Phase 0.)

4. Scaffold the repo. Create the flat layout so the brain has a home for every doc — including the running-notes the intake writes to. Create BUILD-STATUS.md per the runner's status file section, with the full prompt ledger, and show them where it lives: one page that always says what's done, what's running, and what's left, so they never dig through the chat for an update. (Runner Phase 0.)

5. Run the brand intake — the things only they can tell you. Now that the brand is connected and the repo is scaffolded, and before the slow craft copy in the next step, ask the short, skippable set of questions about what Parker genuinely cannot observe on its own: their campaign objective, north-star and how they define a winner, ad naming convention, whether they read performance in-platform or through a third-party tool, their main business objective, their competitor list, their brief format, and optionally their unit economics. Make it easy and personal: lead with what you can already see, prefer a quick pick over an open question, and let them paste links. Cover the whole set, and give it a flow — move through it as one conversation with a thread, in the runner's order (first what success means for the brand, then how they measure it, then how the account and work are organized, then the market, then the gap question last), grouping each cluster into a batch. Get through all of them; don't collapse it to two or three. On format: every question goes through the popup question form — none as plain chat. The form is what fires a notification; a question typed into chat fires nothing, so a user who stepped away never learns the build is waiting. Batch each cluster into one popup with real options plus the form's free-text answer and a skip choice. For items that want a paste (naming doc, brief template), the form asks first and the paste follows once they've chosen to give it. Calibration changes how much you explain a question, not which questions you ask, since every item is something only they can tell you. Just begin the full intake — don't open by asking how much of it they want to do. That forces a decision before they've answered anything. Lead in naturally with the first card; the opt-out is always there without a menu, since every question is skippable and they can say "just build it" to stop. The default is the complete set; if a depth choice ever surfaces anyway, full is the recommendation, never quick. It is never a gate — any single item they don't know or don't want, skip and log to running-notes/missing-context.md (if they defer one for later, note it pending and don't re-ask it this session); they can tap out of the rest, or skip the intake entirely and build, but don't drop half the list on your own. The full question set, grouped, with where each answer lands, is the brand intake step in the runner's Phase 0.

6. Ship the factory method. Copy the factory prompts, skills, and craft layer into the brand repo so the brain is self-contained and references nothing in the factory at runtime. This is the slow file copy, which is why it runs after the conversational intake. (Runner Phase 0.)

7. Run the build. Execute the prompts in dependency order per the runner: Phase 1 audit, Phase 2 strategy (with its gate honored per their intake answer), Phase 3 ideation. Speak at phase boundaries — a few plain sentences on what just got built and what starts now, so the build teaches at the moments a person actually reads. Everything between boundaries goes to BUILD-STATUS.md and the run log, not the chat: no per-prompt narration, no review verdicts in the transcript. Follow the runner's failure policy — retry transient failures once, mark what still fails as blocked in the status file, keep building what doesn't depend on it, and raise blocked items at the next phase boundary rather than stopping the world.

8. Verify and save to GitHub. Run the build verification, then commit and push to the brand's repo so the work is backed up and shareable. Don't skip the save. By this point the runner's stamp step has also armed the standing routines — registered on this instance at their default cadences, no approval gate, because the go-ahead at the top covers it — and the verification checks they're actually registered. (Runner's verify and save sections.)

9. Hand off to /get-started. The build is done, but the work isn't until they know what they have and how to use it. Lead with the one plain sentence the arming owes them: the brain's routines are on — say what runs and when, and that /setup-routines changes a cadence or turns any off. Then run /get-started to walk them through the finished brain and leave them with a first move. Tell them it's re-runnable any time, by anyone on the team.

Hard rules

• The brand gets its own repo. Never commit brand data into the parker-brain clone. If they're working inside the clone, stand up the brand's own repo and explain why.
• The intake is never a gate. Skippable, calibrated, personal. Anything skipped is an open question in missing-context.md, not a blocker, and the build runs as normal without it.
• Teach at the moments, run quiet between them. The welcome, the intake, phase boundaries, blockers, and the finish get real conversation; everything else lives in BUILD-STATUS.md. Neither a silent grind nor a wall of narration — the first buries them in nothing, the second in noise.
• Keep BUILD-STATUS.md true at every state change. It is the answer to "where are we and how much is left," and the ledger a dead session resumes from.
• Defer the detail to the runner. prompts/onboarding-runner.md is the canonical build method, with the dependency graph, the fidelity contract, the path map, and the gates. Follow it; don't reinvent it here.
• End on /get-started. The build isn't the deliverable; a person who can use it is.

Deliverable

A finished brand brain in its own GitHub repo, built from the brand's real data, shaped by whatever intake they chose to give, verified and saved — and a person who's been walked through it and handed off to /get-started, not left staring at a folder of files.