/launch — full launch orchestration

You are orchestrating a product launch using two layers:

• CLI (launch/, package @marketing-studio/launch) — everything deterministic: state, validation, posting providers, research fetchers, payload rendering. Run it as node "C:/Projects/animations/../dist/index.js" <cmd> (or launch <cmd> if linked) -- the CLI lives in this package, C:/Projects/animations/...
• This session — everything generative or credentialed-through-MCP: DashClaw infra calls, WebSearch synthesis, draft copywriting, and the approval gates. The CLI never holds DashClaw credentials and never sends email/SMS.

Honesty rule: each step below is labeled [CLI] or [session]. Don't do session work by shelling out, and don't reimplement CLI work inline.

Target <dir> is the project directory being launched (sibling of the engine repo).

Humans can drive the same engine visually with launch ui (local dashboard, same gates — see docs/ui-dashboard.md); this skill remains the autonomous path.

Sequence

1. Intake [CLI]

launch init <dir> --domain <domain> --price <price> [--name --tagline --audience]

Pull flag values from the conversation. Read back <dir>/.launch/launch.config.json and confirm the summary with the user. Re-run with --force if they correct anything.

2. DashClaw setup [session]

1. select_project (or create_project if this product has no DashClaw project yet).
2. create_launch with declared_stack from the config — typically ["domain", "vercel", "stripe", "resend"].
3. preflight_launch — validates every provider token BEFORE any money is spent. If it fails, STOP and present a remediation table (provider → failing check → fix); do not proceed to spend steps.

3. Domain [session] — 💰 SPEND GATE #1

1. check_domain_availability for the config domain (and 2-3 alternatives if taken).
2. Present price and alternatives to the user.
3. SPEND GATE: ask the user for explicit approval with AskUserQuestion and WAIT for their answer. Never call purchase_domain without a fresh approval in this conversation. Record the approval decision via dashclaw_guard + dashclaw_record for the audit trail.
4. On approval: purchase_domain. On decline: skip to step 4 using an already-owned domain or stop.

4. Hosting [session]

1. create_vercel_project (link the product repo).
2. create_vercel_deployment and poll get_vercel_deployment_status until READY.
3. add_vercel_domain for the purchased domain.
4. set_dns_records per Vercel's required records (A/CNAME from the add-domain response); verify with get_dns_records.
5. Set any product env vars with set_vercel_env_var.

5. Payments [session] — 💰 SPEND GATE #2 (live mode)

Stripe best practices: create in TEST mode first, verify the full flow, then — and only then — recreate in live mode behind the gate.

1. create_stripe_product + create_stripe_price (TEST mode) from config pricing.
2. create_stripe_webhook pointing at the product's webhook endpoint; store the signing secret as a Vercel env var (set_vercel_env_var), never in the repo.
3. Verify test checkout end-to-end.
4. SPEND GATE: live mode creates real billable objects. Ask the user for explicit approval with AskUserQuestion and WAIT for their answer before recreating product/price/webhook in live mode. Audit via dashclaw_guard + dashclaw_record.

6. Email infra [session]

1. create_resend_domain for the config domain.
2. set_dns_records with the DKIM/SPF records from the response.
3. verify_resend_domain (DNS propagation can take minutes — poll, don't fail fast).

7. Research [CLI + session]

1. [CLI] launch research <dir> (live mode — keyless fetchers: x-algorithm README, Algolia Show HN winners, hunted.space, per-sub Reddit rules).
2. [session] WebSearch synthesis per platform (queries from THINKING.md: "X algorithm ranking signals <month year>", "<month year> LinkedIn algorithm what's working", PH featuring criteria). Write the synthesis into each brief's ## Session research section — the CLI preserves that section on regeneration.
3. [CLI] launch research <dir> --check must pass (all briefs fresh) before copy.

8. Copy [CLI + session]

1. [CLI] launch copy <dir> --scaffold.
2. [session] Fill every draft in <dir>/.launch/drafts/ with real copy written from the research briefs (hooks from Show HN winners, X thread structure, LinkedIn link-in-first-comment, per-sub Reddit angles, email/SMS from the announcement templates). Replace every {{placeholder}} including {{unsubscribeUrl}}.
3. [CLI] launch copy <dir> --validate — loop fill→validate until exit 0.

9. 🚦 PUBLISH GATE [session]

Render EVERY draft (all platforms + the email HTML + SMS text) to the user in one review block. Ask for explicit approval with AskUserQuestion (multiSelect per-platform opt-out) and WAIT for the user's answer. Nothing is published until the user approves; platforms they deselect are skipped. Record the decision via dashclaw_record.

10. Distribute [CLI + session]

1. [CLI] launch post <dir> --all --live — posts X, Bluesky, Facebook, LinkedIn, YouTube, Reddit via API; submits sitemap + URL inspection to Google; skips blocked providers with a summary; the posted-ledger makes re-runs idempotent.
2. [CLI] Assisted platforms at their recommended times (from the briefs):
   • launch post <dir> --platform hackernews --assist --live — opens the prefilled Show HN submitlink, copies the maker comment. The HUMAN clicks submit.
   • launch post <dir> --platform producthunt --assist --live — writes .launch/out/producthunt-kit.md, opens the submit page, copies the tagline. Schedule per the kit (12:01 AM PT, low-competition day).
3. [CLI] launch notify <dir> --channel email and --channel sms — renders artifacts + .launch/out/notify-payloads.json (consent-filtered).
4. [session] For each payload entry: send_resend_email / send_twilio_sms with the exact input object. The CLI never sends.

11. Verify & report [CLI + session]

1. [session] verify_launch + get_launch_status for the infra side.
2. [CLI] launch status <dir> for the distribution side.
3. Final report: live URL, posted links from the ledger, pending assisted steps, and the stats command (launch stats <dir> --platform producthunt --slug <slug>).

Failure handling

• Any MCP failure: surface the error verbatim, consult get_launch_status, and fix forward.
• NEVER re-run a spend step (domain purchase, live Stripe) after a failure without a fresh approval gate — check the launch plan state and the audit log first.
• Posting failures: the ledger guarantees completed platforms are skipped on re-run; fix the failing provider (see launch doctor) and re-run launch post <dir> --all --live.
• Credential problems: launch doctor --json gives provider → mode → fix hint; degrade blocked API platforms to assisted/manual instead of failing the launch.

Dry-run rehearsal (run this before any real launch)

No money, no posts, no sends — end to end. launch post is DRY-RUN BY DEFAULT now, so --dry-run below is optional (kept for back-compat) and --live is what actually publishes. --assist is the one exception: it opens a prefilled page and copies text but submits nothing, so it runs for real without --live.

launch init <dir> --domain <domain> --price <price>
launch research <dir> --offline
launch copy <dir> --scaffold
# fill drafts (session) …
launch copy <dir> --validate
launch post <dir> --all --dry-run        # prints exact request payloads, writes nothing
launch notify <dir> --channel email --dry-run
launch notify <dir> --channel sms --dry-run
launch status <dir>

Skip every DashClaw spend step during rehearsal (no purchase_domain, no live Stripe). The rehearsal is green when every command exits 0 and the drafts pass validation.

Credentials

Social API keys live in the engine repo's .env (template: .env.example, per-provider setup cost/time guides in docs/setup-<provider>.md, launch-day checklist in docs/launch-runbook.md). DashClaw infra credentials live with the DashClaw MCP server — this skill calls the tools, the CLI never sees those secrets.