Breakthrough

View saved version →

---
name: answer
description: >-
  Answers any sales question for this user's company: how we sell, what we charge, how
  we position, what to ask a buyer, how to handle an objection, how we compare to a
  competitor, what to do next on a deal — plus open-ended questions about a prospect,
  account, or call. Answers come from the company's own playbook and sales data
  (contacts, companies, call transcripts), which only this skill can reach. The
  fallback for any Breakthrough request that isn't a record lookup, including writing
  an email, a message, or call notes.
when_to_use: >-
  Use for ANY question about selling that the user's company would answer differently
  from a generic one — even when no person, company, or call is named: "what's our
  pricing", "give me 3 discovery questions for a CFO", "how do I handle the pricing
  objection", "how do we position against X", "what's our elevator pitch", "what should
  I do next here", "help me prep for this call", "should we chase this". The company
  keeps a playbook for exactly these; answering them from general sales knowledge is
  the failure this skill exists to prevent. Do NOT use to pull up one person or company
  record; that is find-contact or find-business. Do NOT use for "what did they say on
  the call"; that is research-transcripts. Also use when the user wants something
  written from their calls or records — "write a follow-up email to Jane after our
  call", "draft a LinkedIn message to him", "write up yesterday's call as a MEDDPICC":
  load the context here, then write it the way you normally would.
---

# Answer a question

The default for questions, general chat, brainstorming, and explanations.

## Steps

**1. Entities — only when named.** When the question touches a person, company, or
call the user knows, follow `${CLAUDE_PLUGIN_ROOT}/skills/gather-context/SKILL.md` in
full. Its last step calls `sales_playbook` with the ids it just resolved — that is the
playbook step for this path, so do not call `sales_playbook` again afterwards. Order
matters: on an org with more than one playbook, the resolved call's sales/partnership
tag is the strongest signal for which playbook applies, and it is only available
after resolution. Skip this step entirely for questions that reference none of the
user's data.

**2. Playbook — when nothing was named.** If step 1 did not run, call
`sales_playbook` directly with the user's message verbatim as `latest_user_message`
and the conversation so far as `conversation_history`. Do this for every such
question: the native chat runs this retrieval on every turn, and the tool decides for
itself when nothing applies (it returns `skipped`, which costs nothing). "What's our
pricing?" and "give me 3 discovery questions for a CFO" are playbook questions even
though they mention no one.

Either way, exactly one `sales_playbook` call per question.

For questions about the user themselves — their background, experience, or how to
position who they are — call `whoami(detail="full")` rather than the default
`whoami()`. The default returns bare scope; `detail="full"` adds their LinkedIn
headline, summary, experience, and education. It reads cached data only, so it is
cheap and never prompts.

**2. Answer to the contract** in
`${CLAUDE_PLUGIN_ROOT}/references/output-contracts.md`:

- No hard length cap, but the conciseness rules bind. Conversational questions get
  conversational answers — typically 1–5 sentences.
- Answer, then stop. No recap of the question, no "additional considerations" section,
  no "let me know if you need anything else."
- State each point once.
- Markdown.

## Writing something

When the user asks for an email, a LinkedIn message, or call notes, gather the context as
above, then write it in your usual format. If it is about a call (notes on it, a
follow-up to it), read that call with `call_transcript_conversation` first; listing the
call or reading `<PastCallNotes>` is not reading it. Every specific in the draft should
come from what you retrieved; leave a placeholder for anything you don't have, such as
the user's availability. Nothing is sent: the user sends it.

## Web search

Use Claude Code's `WebSearch` / `WebFetch` under the rules in
`${CLAUDE_PLUGIN_ROOT}/references/context-assembly.md`. The one that gets violated most:
**do not web-search a question about a call the user had.** Pull the transcript. If the
transcript isn't in scope, say so and offer to find it — substituting a web search for
the user's own call data is the specific failure the system prompt calls out.

## Grounding

Distinguish what the data shows from what you're inferring. "They raised a Series B in
March" and "they're probably budget-constrained this quarter" are different claims and
the user is making decisions on both.

If the question can't be answered from what's in scope, say what's missing and what would
answer it.

View saved version →

---
name: find-business
description: >-
  Looks up one company in Breakthrough by name, website domain, or LinkedIn company URL
  and returns its stored profile. Answers "is this account already in the system" and
  pins down which company the user means before acting.
when_to_use: >-
  Use when the user says "pull up Acme", "do we have anything on acme.com", "look up
  this company", "are we already working with them", "what do we have on that account".
  Do NOT use to find a person; that is find-contact. Do NOT use for what was said on
  calls with the account; that is research-transcripts. Do NOT use for questions
  needing judgment about the account rather than its record; that is answer.
---

# Find a business

Wraps the `business_profile` MCP tool.

## Usage

Pass the user's phrasing as `query`. The tool extracts domains and LinkedIn company URLs
from the text itself, so a full sentence works.

`limit_candidates` defaults to 5.

For "who do we know at X", call `resolve_prompt_context` instead — it cross-references
businesses to contacts in one pass, which `business_profile` alone does not do.

## Reporting

Report the resolved business and, where the data includes them, the contacts tied to it.

If several candidates come back, present them and ask. If nothing resolves, say so —
don't substitute web results for CRM data without labelling them as such.

View saved version →

---
name: find-contact
description: >-
  Looks up one person in Breakthrough by name, email address, or LinkedIn URL and
  returns their stored record — role, employer, linked company. Answers "is this person
  already in the system" and pins down which person the user means before acting. For
  a factual question about who a named person is, what they do, or where they work,
  this returns the user's own record of them.
  An open-ended "what do we know about" or "how should I approach" them is answer; so
  is writing them an email or LinkedIn message, or notes on a call with them; what they
  said on a call is research-transcripts.
when_to_use: >-
  Use when the user says "who is this", "do we have Jane", "look up jane@acme.com",
  "what's her title", "is he in the system", "which Jane do we know", "pull up her
  record", "where does Matt work". Also use for a factual question about someone the
  user sells to or works with (a contact, prospect or customer): Breakthrough holds the
  user's own record of them. Do NOT use to add
  someone new; that is import-contact. Do NOT use to update a record that has gone
  stale; that is refresh-contact. Do NOT use for what was said
  on calls with them; that is research-transcripts. Do NOT use for questions needing
  judgment about the person rather than their record; that is answer.
---

# Find a contact

Wraps the `contact_profile` MCP tool.

## Usage

Pass the user's phrasing as `query`. The tool extracts embedded email addresses and
LinkedIn URLs itself, so `"do we have anything on jane@acme.com"` works as well as
`"jane@acme.com"` — no need to strip the sentence down first.

`limit_candidates` defaults to 5. Raise it when a common name returns an ambiguous set.

When the request is vague about who is meant, call `resolve_prompt_context` first — it
cross-references contacts against businesses and returns concrete recommendations, which
disambiguates "the CTO at that fintech" better than a name search can.

## Reporting

Report what resolved: full name, contact ID, role, employer, LinkedIn URL.

**If several candidates come back, present them and ask.** Do not pick the top hit and
proceed — the downstream action is usually an email to a real person, and picking wrong
means writing to the wrong one.

**If nothing resolves, say so plainly.** "No contact matching that in Breakthrough" is
the first thing to say. If the user asked what *they* have on file, stop there. If they
asked a factual question about the person (where someone works, what their title is),
the web may still answer it: do so, but label it as not from Breakthrough, never as if
it came from the CRM. Either way, offer the import path (the import-contact skill) if a
LinkedIn URL or email is available.

View saved version →

---
name: gather-context
description: >-
  Shared subroutine that loads the Breakthrough context behind a request — resolves
  which contacts, companies, and recorded calls are in scope, then retrieves the
  relevant sales playbook sections. The answering skill runs this
  first, so it is not selected on its own; invoke it directly only to preload
  everything known about an account before a working session.
disable-model-invocation: true
---

# Gather Breakthrough context

The prelude the answering skill runs before it produces anything:
resolve the entities in scope, then pull the evidence and playbook behind them.

Read `${CLAUDE_PLUGIN_ROOT}/references/context-assembly.md` for the voice, length, and
web-search rules that come with this context. Read
`${CLAUDE_PLUGIN_ROOT}/references/mcp-tools.md` for argument details.

## Sequence

**1. Confirm scope.** Call `whoami`. If `license_id` is missing, stop — the session is
not authenticated and every other tool will return `skipped`. Tell the user to
authenticate rather than reporting an empty result.

**2. Resolve.** Call `resolve_prompt_context` with the user's message **verbatim**. Do
not summarize or extract keywords first; the tool does its own signal extraction and
pre-digesting destroys what it keys on.

The response carries a `recommendations` array generated from real counts against this
org's data. **Follow it unless you have a specific reason not to.** It knows
what exists in scope; the prompt text does not.

**If the response says `clarification_needed: true`, stop and ask.** (When the map lists
`ambiguous_names` without that flag, the request's target resolved elsewhere: proceed with
it and do not pick one of the listed people.) A first name that
matches several people ("Ben", "Andre", "Marco") is a question for the user, not a
guess for you. The flag already accounts for shared history: when only one candidate
has calls on record the map resolves them and does not set the flag, so if you are
seeing it, history did not settle it either. Reply with the
candidates from `ambiguous_names` (name, company, calls on record) and nothing else; do
not resolve, draft, or answer until the user says which person they mean. The native
app never has to guess here because the user attached the record; asking is how this
surface gets the same certainty.

**3. Detail.** For entities the map surfaced, call `contact_profile` and
`business_profile`. Each returns the entity notes and `recent_calls`: that person's or
company's calls, newest first, with `tags`. When the request is about their past calls
("from my calls with Ben, what does he care about"), the notes are the starting point,
not the answer: read the calls — `format="summary"` for each (up to 3 in full).

**Sales methodology.** The scorecard belongs to the company. `business_profile` shows it
as a `sales_methodology` field. When the request is about a deal (what
to do next, gaps, call prep, strategy, where it stands) and it is present, call
`sales_methodology` with the `business_id`, then read
`${CLAUDE_PLUGIN_ROOT}/references/sales-coaching.md` before answering. For a deal with a
person, `contact_profile` shows `company.sales_methodology`; use `company.id` as `business_id`. Skip it for
drafting and for notes from a call unless the user asks.

**After a clarifying question.** If you asked which person or company and the user
answered with a name, run `resolve_prompt_context` on that name before continuing. The
clarified map carries the CALLS ON RECORD step that the ambiguous one could not.

**4. Evidence.** Pull transcripts with `search_transcripts`,
`contact_transcripts_list`, or `call_transcript_conversation`. Use `format="summary"`
when scanning several calls — pulling multiple transcripts at `format="full"` buries the
question in raw text. The rule: up to 3 calls, open them in full; more than 3, open each as
`format="summary"` (its thematic summary) and go back to `format="full"` only for the one
call an exact quote or number must come from. The app carries full transcripts up to 5,
but everything you open stays in your context for the whole conversation, so the
plugin's ceiling is lower on purpose. Use `format="full"` for a single deep dive, and when the request
turns on what was said on one call (a summary of it, notes from it, a follow-up to it,
a thank-you for it), open that call — the native app hands the whole transcript to the
model, and answering from the stored notes instead is the gap. A long transcript comes
back in parts: the response carries `parts` and `next_part`; keep calling with the next
`part` until `next_part` is null before you summarize or extract anything from it.
When a resolved person has calls on record, the map's **CALLS ON RECORD** recommendation
names the exact next step; follow it whenever the request is about a call with them.

**5. Playbook.** Call `sales_playbook` with the user's current message and the
conversation so far.

## When to stop early

Steps 3 and 4 are conditional on step 2. A request with no entity signal — "what's a
good subject line pattern?" — has no contact, business, or call to resolve, so skip
those rather than firing lookups that come back empty. Retrieving nothing and retrieving
nothing *useful* look the same in the output but cost the user latency.

**Step 5 is not conditional.** The playbook is org-level guidance, so it is exactly
what a question with no entity signal needs — "what's a good subject line pattern?" is
answered by this org's playbook, not by a generic one. Skip `sales_playbook` only when
the request turns on no guidance at all: a bare record lookup, or reading back what was
said on a call.

## Reporting

State what you actually found: which contacts and businesses resolved, which calls you
read, whether the playbook returned relevant sections. If a name in the request resolved
to nothing, say so explicitly — a draft built on an unresolved contact is a draft about
someone the user may not have meant.

Never assert a fact about a contact or business that no retrieved source supports.

View saved version →

---
name: import-contact
description: >-
  Adds a NEW person to Breakthrough from a LinkedIn profile URL or an email address,
  then starts enrichment to fill in their role, employer, and background. Requires a
  URL or email — a name alone is not enough to import from.
when_to_use: >-
  Use when the user supplies a LinkedIn URL or email address and says "import", "add",
  "pull in", "get this person into the system", "track this guy", "add her to
  Breakthrough". Do NOT use for someone already in the system whose details have gone
  stale; that is refresh-contact. Do NOT use to check whether they already exist; that
  is find-contact.
---

# Import a contact

Wraps the `import_contact` MCP tool.

## Before calling

**Check whether they already exist.** Run the find-contact skill first. Importing
someone already in the CRM enqueues enrichment work for nothing and can create a
duplicate the user then has to clean up.

**You need a LinkedIn URL or an email address.** `query` alone is a weak signal for
import — the tool imports from an identifier, not from a name. If the user has neither,
say so rather than importing something approximate.

## Calling

`import_contact(linkedin_url=None, email=None, query=None)` — pass whichever identifier
you have.

This tool is annotated **destructive** and Claude Code will prompt before it runs. That
prompt is correct; do not tell the user to pre-approve it.

## What it does

- Queues background enrichment against external data sources
- Waits for the contact to be created, for up to **~90 seconds**, and returns then
- The fit result keeps generating after it returns: `contact_without_fit_generating`
  means it is still running; `contact_profile` shows it a minute or two later

A pause is expected. Don't retry a call that seems slow — you'll queue a second import.

## Reporting

Report the returned status and the contact if one was created.

Enrichment continuing after the tool returns is normal. Say the import started and that
data will fill in, rather than presenting a partially-enriched record as final.

If the result is `{"status": "skipped", "reason": "missing_or_invalid_license_context"}`,
nothing was imported — that's an auth failure. Tell the user to authenticate.

View saved version →

---
name: refresh-contact
description: >-
  Keeps an EXISTING Breakthrough contact's employer and title right. When the user
  states where someone works now ("Marco works at Kleecks, I just met him", "she's
  advising RudderStack"), records that employer once the user confirms — the fix for
  people LinkedIn has wrong. Otherwise re-pulls their details from LinkedIn when the
  record is stale, and answers whether someone's job is still current ("is Matt still
  at Quindar?", "did he leave?"): Breakthrough holds the user's own record of that
  person. Confirms before changing anything.
  Writing to them or writing up a call is answer; what they said on a call is
  research-transcripts; their record as it stands is find-contact.
when_to_use: >-
  Use for statements of where someone works now ("Mauricio works at Autopistas del
  Café", "he's at Globex now", "he joined Kleecks"); refresh requests ("refresh Jane",
  "update his title"); complaints that a record is wrong ("you have him at his old
  company"); departures ("Sarah left Acme", "FYI they moved on"); and currency
  questions ("is this current?", "where is Sarah now?"). Prefer this over find-contact
  and answer whenever a contact's employer or title is stated, reported
  changed, or questioned — nothing changes without the user's say-so. Do NOT use for
  someone not yet in the system; that is import-contact.
---

# Refresh a contact

Wraps the `refresh_contact` MCP tool, which does two different things:

- **Records an employer the user states.** The user is the source of truth; nothing is
  re-read from LinkedIn, because LinkedIn is usually what was wrong.
- **Re-pulls the record from LinkedIn** when it has gone stale.

## When this applies

The backend routes broadly on purpose, because the tool confirms before changing
anything. All of these belong here:

- **Statements of where someone works now** — "Mauricio works at Autopistas del Café",
  "he joined Kleecks", "she's advising RudderStack". Advisory, fractional and board roles
  count. These go to the correction path below, not a refresh.
- **Explicit commands** — "refresh Jane's contact info", "update this contact's title"
- **Stale-data complaints** — "John's data is wrong", "you have her at her old employer"
- **Employer or title changes, however phrased** — including passive and note-style
  mentions with no refresh verb at all: "Sarah no longer works at Acme", "he's at Globex
  now", "FYI Sarah left Acme"
- **Currency questions** — "is his info up to date?", "do you have more current data?"

## Recording an employer the user states

Call `refresh_contact(query=..., employer="<company>")` — the company as the user said
it, or its website. `employer` is where the person IS:

- "Venkat **left** Splashtop" names where he is NOT — there is no employer; this is a
  plain refresh. If they also say where he went ("left Splashtop for RudderStack"), the
  destination is the `employer`, never the origin.
- A company inside a **question** — "is Matt still at Quindar?" — is something to check,
  never an employer.

Nothing is written until the user confirms. Each status names the one thing still
missing — **ask the user, then call again with their answer. Never fill these in
yourself.**

| Status | Ask the user | Then call again with |
| --- | --- | --- |
| `needs_contact_choice` | which of the listed people they mean | `contact_id` of that candidate |
| `needs_business_choice` | which of the listed companies they mean | `employer_business_id`, or `employer_website` if none is right |
| `needs_new_company_confirmed` | whether the company the tool found is right — or its website, if it found none | `employer_website=<website>` — `employer` stays the company's name |
| `needs_change_kind` | was our record simply wrong, or did they change jobs? (decides whether past calls move) | `employer_change_kind="correction"` or `"job_change"` |
| `needs_since` | when they started | `employer_since="YYYY-MM-DD"` |
| `proposal` | show `message` — it says exactly what will change — and ask whether to apply | `apply_token` from this result, **only after they agree** |
| `no_change_needed` | nothing — the record is already right; say so | — |
| `applied` | nothing — report what changed | — |
| `expired` | the confirmation lapsed; start over | — |

Keep the same `employer` and answers on every follow-up call. `apply_token` is single
use and short lived: never store, reuse, or invent one.

## Re-pulling from LinkedIn

`refresh_contact(linkedin_url=None, email=None, query=None, user_requested=False)`. Pass
the user's message as `query` when you have no identifier — resolution is the tool's job.

`user_requested` is your call, and the tool never infers it from the wording of `query`:

- **true** — the user asked for the refresh outright ("refresh Jane", "re-pull his
  details", "update her record from LinkedIn"), or has just confirmed a refresh you
  offered. The tool starts the refresh.
- **false** — you are acting on a hint: a change report, a complaint, a currency question
  ("Sarah left Acme", "is Matt still at Quindar?"). The tool resolves the contact and
  returns `needs_confirmation` so you can ask first.

Annotated **destructive**; Claude Code prompts before it runs. Don't ask the user to
pre-approve it.

## Handling the result — read this before reporting anything

For a re-pull (no `employer`), five statuses. **Only `started` changed any state.** Every
other status is a safe no-op that enqueued nothing.

| Status | What happened | What you must do |
| --- | --- | --- |
| `started` | Refresh was **enqueued** | Report it's queued. Enrichment is *not* complete — don't present current field values as refreshed. |
| `needs_confirmation` | One contact resolved, but from an **implicit** signal | **Stop and ask the user before refreshing.** Show which contact you matched. Once they confirm, call again with `user_requested=true`. |
| `ambiguous` | Several candidates matched | Present the candidates and ask which. Do not pick one. |
| `no_linkedin_url` | Contact found, but no stored URL to re-enrich from | Report it. Retrying will not help. |
| `no_match` | Nothing resolved | Report it. Offer the import-contact skill if they have a URL or email. |

### Why `needs_confirmation` exists

Breakthrough deliberately separates an explicit refresh *command* from an implicit
*signal*. A passing mention — a note, a complaint, a question about currency — resolves
the contact but stops short of refreshing, so a stray mention never silently triggers
a re-pull.

A statement of a **new employer** — "update Marco's employer, he's now at Kleecks" — is
not a re-pull at all: pass it as `employer` (above). A re-pull only re-reads LinkedIn and
cannot record what the user just told you.

Collapsing these statuses into "done" defeats the guardrail. Report the one you got.

## Reporting

Name the contact you matched — full name, ID, current role and employer — so the user can
catch a wrong match before anything is re-enriched.

For `started`, say the refresh is queued and data will update, not that it is updated.

For a stated employer, report only what the tool says happened: a `proposal` is not a
change until the user agrees and `applied` comes back.

View saved version →

---
name: research-transcripts
description: >-
  Searches and reads the user's recorded Breakthrough call transcripts — finds which
  calls touched a topic, lists a contact's calls, or reads one call in full. Answers
  what was actually said, by whom, and when, citing the call it came from.
when_to_use: >-
  Use when the user says "what did they say about pricing", "did we discuss budget",
  "when did we last talk to Acme", "what were their objections", "pull up that call",
  "did they commit to anything", "who was on the call", "did it come up". Do NOT use to
  write the call up as notes or a MEDDPICC; that is answer. Do NOT use for questions needing
  judgment beyond what the calls actually state; that is answer.
---

# Research call transcripts

Wraps `search_transcripts`, `contact_transcripts_list`, and
`call_transcript_conversation`. Full argument details in
`${CLAUDE_PLUGIN_ROOT}/references/mcp-tools.md`.

## Before searching: who is the request about?

When the request names a person or a company ("what did Ben think of the demo",
"pull up that call with Acme"), run `resolve_prompt_context(user_prompt=<verbatim>)`
**first**, before `search_transcripts`. It says which contacts and businesses exist with
that name, how many calls each has, and whether the name is ambiguous. A first name
alone often matches several people, each with their own demo — searching transcripts
for "Ben demo" and reading the top hit picks one of them silently, which is the worst
outcome.

- `clarification_needed: true` → reply with the clarifying question the
  recommendations spell out (the candidates and their calls on record) and stop.
- One matched contact → use its id with `contact_transcripts_list`, then open the
  call you need. Do not fall back to a free-text `search_transcripts` for a person who
  resolved.
- A matched business but no contact ("that call with Acme") →
  `search_transcripts(query=<topic or "">, filter_by="business_names:<name as returned>")`,
  then open the call you need. `business_profile` returns the profile and notes, not
  the call list.
- No match → `search_transcripts` with the topic is the right next step.

## A topic across a window ("product requests from the last week")

The search index holds each call's name, imported summary, participants, businesses,
date and tags — not what was said. A topic like "product requests" is rarely in a title,
so do not search for it. Bound the set instead and read:

1. `search_transcripts(query="", filter_by="call_date:>=<YYYY-MM-DD> && tags:Sales",
   sort_by="call_date:desc", limit=50)` — the prospect calls in the window, newest first.
   The tool returns at most 50; if you get 50 back, the window holds more: query again
   with `call_date:<=` the oldest date you received (`<=`, not `<`: several calls can share
   a timestamp) and drop the ids you already have, until a page comes back short. Say how
   many calls there were in total.
2. Open **each** of them with `format="summary"` (the thematic summary) and read for the
   topic. Do not stop at three because three felt like enough; stop when the list is done.
3. Answer from what the summaries say, citing call and date; go back to `format="full"`
   only for a call an exact quote must come from.

If the window is empty, say so and offer the most recent calls instead of quietly
substituting them.

## After a clarifying question

When you asked "which Ben?" and the user answered with a name, run
`resolve_prompt_context` again on that name before anything else. The map for the
clarified name carries the CALLS ON RECORD step; the first map did not, because the name
was ambiguous. Then `contact_profile` — its `recent_calls` lists their calls, newest
first, with tags — and read the calls the question is about.

## Choosing the entry point

| The question | Tool |
| --- | --- |
| "when did X come up" / topic across calls | `search_transcripts` |
| "what calls have we had with Jane" | `contact_transcripts_list` (needs contact IDs) |
| "what happened on that call" | `call_transcript_conversation` |

`contact_transcripts_list` takes **integer contact IDs**, not names — resolve through
`contact_profile` or `resolve_prompt_context` first. It returns metadata only, no
transcript bodies.

## Searching

`search_transcripts(query, limit, filter_by, sort_by)`:

- `query` — semantic + keyword. Empty browses without relevance ranking.
- `filter_by` — filter grammar, applied **before** ranking. Only five fields exist:
  `name`, `participant_names`, `business_names`, `call_date` (a date as `YYYY-MM-DD`,
  or unix seconds), `tags`. Every response carries `today` and, when you filtered by
  `call_date`, `call_date_window` with the dates actually searched; check it against
  the period the user asked about before reporting that there were no calls.
  Inventing a field name errors out rather than being ignored.
- `tags` is what kind of call it is: `Sales`, `Internal`, `Onboarding`,
  `Instructional`, … A question about prospects or customers means `tags:Sales`; a
  question about "my calls" in a window usually means `tags:!=Internal`. Every result
  carries its `tags`, so say which calls you left out and why.
- `sort_by` — sort grammar. Defaults to `call_date:desc` on an empty query,
  relevance otherwise.

Filter when you know the constraint (a named account, a date range); let relevance rank
when you don't.

## Reading

`call_transcript_conversation(transcript_id, include_structured, format)`:

- **`format="summary"`** when scanning several calls. Pulling three or four at `"full"`
  buries the question in raw dialogue.
- **`format="full"`** for a single deep dive, or when exact wording matters — an
  objection, a commitment, a number.
- `include_structured=True` adds per-sentence timing and speaker structure. Only with
  `format="full"`, and only when you need to attribute lines to speakers.

## Reporting

Cite which call each finding came from — call name and date. "They pushed back on
pricing" is worth little; "on the Feb 12 call, Dana said the $40k figure would need
CFO sign-off" is actionable.

Distinguish what was said from what it implies. And when the search returns nothing, say
the calls don't cover it rather than reasoning from general knowledge about the account —
the entire premise of the question was the user's own call data.