Onboard

---
name: onboard
description: First-run flow for Growth OS. Takes a business URL and walks the user through the full setup — build the context hub, connect accounts, run the growth audit — then explains what to do next. Use when someone runs /growth-os:onboard, says "set up Growth OS", "get started", "onboard my business", or just drops a URL and asks Growth OS to take it from there.
---

# onboard

The front door to Growth OS. One command turns a raw business URL into a working Growth OS: a persistent context hub, a set of connected data sources, and a first growth audit — with a plain-language explanation of what each step found and what to do about it.

## What it does

`onboard` is an orchestrator. It doesn't do the heavy lifting itself — it sequences the three foundational skills in the right order and keeps the user oriented between them:

1. **context** — read the URL, draft a first-pass positioning (USP/UVP/ICP), and confirm it with the user. Writes `.agents/product-marketing.md`.
2. **connect** — figure out which data sources the user can wire up right now (zero-approval) versus which need a lead-time approval, and walk them through the fast ones first.
3. **audit** — run the growth audit against whatever is connected, plus the always-available checks (SEO, page speed, GEO), and write findings back to the hub.

Then it hands off: a short "here's what I found, here's what's worth doing first" summary.

## When to use

- The user is running Growth OS for the first time in a repo/project.
- Someone gives you a business URL and expects Growth OS to "take it from here."
- A returning user wants to re-baseline a business (new site, new positioning, new quarter).

If the hub already exists and the user only wants one piece (just re-run the audit, just connect one account), skip straight to that skill instead of the full flow.

## Inputs

- **Business URL** (required). The homepage is enough. If the user gives a deeper page (pricing, product), use it — more signal.
- Optional: a one-line description of the business, if the site is thin or gated.

If no URL is provided, ask for one before doing anything. Everything downstream keys off it.

## Steps

1. **Confirm the target.** Echo the URL back and state what you're about to do: build a context file, connect data sources, run an audit. Set the expectation that this takes a few passes and that nothing gets published or changed on their site — Growth OS is read-side.

2. **Check for an existing hub.** Look for `.agents/product-marketing.md`.
   - If missing → this is a true first run. Continue to step 3.
   - If present → tell the user Growth OS is already set up here. Offer: refresh context, re-run the audit, or connect more accounts. Don't silently overwrite anything.

3. **Delegate to `context`.** Hand off the URL. `context` runs its batched interview (pre-filled from the URL, user confirms), and writes the hub. Wait for it to finish and confirm the positioning is captured before moving on — the audit and every downstream skill reads from this file.

4. **Delegate to `connect`.** Now that we know the business, wire up data. `connect` scans `.env` for existing keys, splits sources into 🟢 start-now versus 🔴 needs-approval, and walks the user through the fast ones (GA4, Search Console, MailerLite, PageSpeed) first. Make it clear the 🔴 sources (Google Ads, Meta) can be started in parallel because the approvals sit with the account owner and take real calendar time — the user shouldn't wait on them to get value today.

5. **Delegate to `audit`.** Run the growth audit. It uses whatever `connect` managed to wire up for the live baseline, and always runs the checks that need no accounts (SEO crawl, PageSpeed if the key is set, GEO visibility). It appends an `## Audit Findings` section to the hub.

6. **Explain and hand off.** Summarize in plain language:
   - What Growth OS now knows about the business (one or two lines from the context).
   - What's connected and what's still pending approval.
   - The three or four highest-leverage findings from the audit.
   - The single next action worth taking — usually either "connect X to unlock Y" or "fix Z on the site."

   Point the user at `/growth-os:dashboard` for the assembled overview and `/growth-os:delegate` when they want to act on a specific finding.

## Which adapters / CLI it calls

`onboard` itself calls no adapters directly. It delegates:

- Positioning → **context** skill
- Data wiring → **connect** skill (which references `docs/integrations/*`)
- Audit → **audit** skill (which invokes the read-side CLI: `growth-os ga4 …`, `growth-os gsc …`, `growth-os psi …`, plus the GEO module)

## How it delegates

Sequential, gated hand-offs. Each step must land before the next starts, because each one depends on the previous:

- `context` must write the hub before `audit` can reason about the business or run GEO (GEO queries are derived from the ICP).
- `connect` should run before `audit` so the audit has live GA4/GSC data for the baseline — but the audit still runs (with a smaller scope) if the user skips connecting.

Never block the whole flow on a 🔴 approval. If Google Ads or Meta aren't ready, note them as pending and finish onboarding with everything else. The user gets value on day one and the slow approvals catch up later.

## Guardrails

- Read-side only. `onboard` never publishes, edits the user's site, or writes to any connected account.
- Idempotent. Running it again on an already-onboarded project offers a refresh, never a silent wipe.
- Own keys. Every credential the user provides during `connect` lives in their `.env`, never in the hub and never sent anywhere but the source API.