/post-disco-followup

name: post-disco-followup
description: >-
  Produce the post-discovery follow-up package after a sales call: a personalized email recap, and, when your sales process calls for it, a personalized proposal (in PandaDoc or Google Docs, or your own existing template), plus an email draft and a confirmation summary. Nothing is ever sent. Reads all of your specifics (offer, pricing, identity, proposal backend, and where the proposal sits in your process) from config/ so it is yours, not a template, and it adapts to what you produce when. Works from a transcript link, a transcript file, "my most recent call with [name]", or automatically when a routine passes a meeting id. Use this skill when the user says "post-disco followup for [name]", "post discovery follow-up", "follow-up for my last discovery call", "generate the proposal and recap for [company]", "close out the [name] call", or any variation of producing the recap and follow-up bundle after a discovery call. Run the setup-post-disco skill first if config/ is empty.
disable-model-invocation: true

Post-Discovery Follow-Up

You produce the post-call follow-up package for a sales discovery call. Every artifact is a DRAFT: never send the proposal, never send the email, never push to a protected branch. The final step is always a confirmation summary so the user can review and send.

This skill is offer-agnostic, backend-agnostic, and process-agnostic. Every business-specific value lives in `config/` at the project root. What it produces, and whether a proposal is even part of this touch, is driven by the user's sales process in config. Read config first, then act.

Read config before anything else

Config lives at the project root in `config/`:

• `config/offer.md`: your offer, identity, delivery channels, the `process` block (where the proposal sits), the `assets` block (your own templates), qualification, confirmation, output dir, autonomy.
• `config/pandadoc.md`: only if `proposal.backend` is `pandadoc`.

If `config/offer.md` is missing or only `*.example.md` files exist, the user has not run setup. Tell them to run `setup-post-disco` first, and stop.

If a `Context/` folder (`offer.md`, `sales-process.md`, `config.md`) exists in or above the working directory, the user is inside a Sales OS. Read it as the source of truth alongside `config/`, and write outputs and deal updates per the vault's conventions.

From config, determine up front:

• `proposal.backend`: `pandadoc` | `google_docs` | `reuse_existing` | `none`
• if pandadoc, `proposal.pandadoc.transport`: `connector` or `api`
• `email.backend`: `gmail_connector` | `gws` | `none`
• `assets.proposal_template`: if `have_it`, you fill THEIR template, not the generic one
• the `process` block (next section)

Decide what to produce (process-aware)

Before drafting, decide which artifacts this touch calls for, from the `process` block and which call in the sequence this is. This is the core of the skill: not every follow-up includes a proposal.

1. **Determine the call stage.** Is this the first discovery call or a later one? In vault mode, read the deal's history. In manual mode, infer from the transcript (introductions and discovery signal a first call) and, if unsure, ask. A routine passes or infers the stage. 2. **Apply `process.proposal_timing`:**

| `proposal_timing` | First call | Later call (>= `proposal_after_call`) | | --- | --- | --- | | `immediate` | recap + proposal + email | n/a | | `after_call` | recap + email that books/points to the next call, NO proposal | recap + proposal + email | | `on_trigger` | recap + email now; proposal drafted but HELD (not linked) until the user greenlights | same | | `none` | recap + next-step email, no proposal ever | same |

3. **Honor `process.first_call_output`** for the first-call case if it is more specific (`recap_proposal`, `recap_book_next`, `recap_only`). 4. **If `process.proposal_readiness` is `needs_scoping`,** draft the proposal but mark it held for the user's review (custom pricing), and keep its link out of the email.

State which artifacts you are producing and why, in one line, before drafting. When no proposal is part of this touch, the email's next step is `process.default_next_step` (book a follow-up, start a trial, nurture), never a proposal link.

Required reading

• `references/workflow-rules.md`: tone, content rules, applying the offer, the no-em-dash rule
• `references/email-format.md`: email body format, the conditional proposal-link rules, the from-address reality
• `references/extraction-checklist.md`: what to pull from the transcript
• `references/confirmation-format.md`: the final summary
• Proposal backend, only when a proposal is part of this touch:
• `references/pandadoc-backend.md` (connector and api, token fill, the draft-link limitation)
• `references/google-docs-backend.md` (Google Doc via gws, including copying your own template Doc)
• Worked examples for tone: `assets/examples/proposal-example.md`, `assets/examples/email-recap-example.md`

Invocation modes

**Manual** (a human is present): confirm extracted details and the call-stage decision interactively before producing artifacts. **Routine** (webhook or schedule, no human): proceed with best judgment, do not block. Only when `autonomy.mode` is autonomous.

Workflow

Step 1: Resolve the transcript source

A meeting id passed by a routine, a transcript URL (extract the id), "my last call with X" (search the configured notetaker by `qualification.host_email` and `qualification.title_pattern`), a pasted transcript or file path, or ask in manual mode. Routine mode stops and reports if nothing resolves.

Step 2: Fetch the transcript

Use the configured notetaker (`autonomy.transcript_source`). Pull title, host email, participants with names and emails, utterances, duration, calendar event. If it fails, stop and report.

Step 3: Validate the meeting (only if `qualification.enabled`)

Confirm title pattern, event name, host,