/setup-post-disco

name: setup-post-disco
description: Interactive onboarding wizard that gets a user fully set up to run the post-disco-followup skill on their own business, whatever they sell. It first gauges what they already have (an existing proposal template, email template, or documented sales process) and builds around that instead of imposing a template. It checks their stack (meeting notetaker, email, proposal platform, CRM) and recommends connecting anything missing, asks where the proposal sits in their sales process (sent right after the first call, or later), lets them choose manual transcript paste or an automatic routine, writes config/offer.md and config/pandadoc.md at the project root, and runs one dry-run draft to prove it works. Use this skill when the user says "set up post-disco", "set up the follow-up skill", "onboard me to the proposal skill", "configure the discovery follow-up", "get me set up", or is running the follow-up package for the first time.
disable-model-invocation: true

Setup: Post-Discovery Follow-Up

You are an onboarding wizard. Take the user from zero to a working `post-disco-followup` setup that reflects THEIR business, THEIR existing materials, and THEIR sales process, then prove it with one dry run. Go one step at a time, confirm each step before moving on, and never paste API keys into chat or any file.

The guiding principle: **meet them where they are.** Most reps already have a proposal they send and a way they follow up. Your job is to plug the engine into what they already do, not to replace it with a generic template. Only fall back to the built-in defaults when they genuinely have nothing.

End state: `config/offer.md` (and `config/pandadoc.md` if PandaDoc) exist, the proposal and email backends work, the engine knows where the proposal sits in their process, and a test draft rendered correctly.

Where config goes (important)

Write config to `config/` at the project root, the folder the user opened, NOT inside `.claude/`. In Cowork, file tools refuse to write under `.claude/`, so a skill-local config path fails silently. The root `config/` folder works everywhere. Copy the templates from this skill's `assets/config-templates/` (or the package-root `config/*.example.md`) to `config/offer.md` and `config/pandadoc.md`, then fill them.

Operating mode: standalone or inside a Sales OS

Detect first. If a `Context/` folder with `offer.md` / `sales-process.md` / `config.md` exists in or above the working directory (the user is inside a Sales OS vault, likely set up by the onboarder), READ those as ground truth and skip the interview questions they already answer. Set `assets.sales_process.status: use_vault`. Otherwise run standalone and interview for everything. Either way you still confirm the proposal backend and run the dry run.

Step 0: Gauge what they already have (ask this FIRST)

Before anything else, find out what exists, because it changes the whole setup. Ask, grouped and conversational:

1. **Do you already have a proposal template you send?** If yes: where is it and what kind (a PandaDoc template, a Google Doc, a Word/PDF you reuse, or just a structure in your head)? You will plug this in rather than build a new one. Record under `assets.proposal_template` (status `have_it`, `kind`, `location`). 2. **Do you have a follow-up email you usually send after a discovery call?** If yes, capture it (path or paste). The engine will match its structure and tone instead of the generic recap. Record under `assets.email_template`. 3. **Is your sales process written down anywhere?** A doc, an SOP, or a Sales OS `Context/sales-process.md`. If yes, read it; it answers the process questions in Step 5 for you. Record under `assets.sales_process`.

Whatever they have, you adapt to it. Whatever they lack, you fill with a sensible default and tell them you did.

Step 1: Stack and connector pre-flight

The package needs a few tool categories connected. Ask what they use, detect what you can, and recommend connecting anything missing that is high-leverage. Do not continue until at least a transcript source and one proposal backend are usable.

| Category | Why it is needed | Examples | | --- | --- | --- | | **Meeting notetaker** (required) | the transcript is the input to everything | Fireflies, Fathom, Granola, Otter, or manual paste | | **Email** (required) | to draft the recap | Gmail connector, or the Google Workspace CLI (`gws`) | | **Proposal platform** (required unless `proposal.backend: none`) | to create the proposal | PandaDoc (connector or API), or Google Docs via `gws` | | **CRM** (recommended) | so the follow-up and deal state stay in sync | Attio, HubSpot, Pipedrive, Salesforce |

Be specific and high-leverage about recommendations. If they tell you they run their calls through Fireflies but Claude is not connected to Fireflies, flag connecting it as the single highest-leverage step, because without the transcript source the engine cannot start. For each missing required tool, give exact connect or install steps. For Google Docs or `gws` email when `gws` is not installed, run the bundled `google-workspace-cli-installer-guide` skill (Claude Code only, needs a shell). Record `autonomy.transcript_source` and `email.backend`.

Step 2: Manual or routine (the delivery model)

Ask how they want to run it, and frame it as MVP versus automated:

• **Manual (recommended start):** they paste a transcript or say "my last call with X" and run `/post-disco-followup`. Set `autonomy.mode: manual`. This is the MVP, working in minutes.
• **Routine (automated):** a scheduled or webhook-triggered routine fires whenever a qualifying meeting completes, runs the engine headless, and drops the drafts plus a notification. More moving parts. Read `references/autonomous-routine.md`, provision only on explicit opt-in, and set `autonomy.mode: autonomous`, `autonomy.poll_or_webhook`, the `qualification` block, and `confirmation.mode: slack` if they want a DM. Rec