twenty-lead-brief

First step of the lead path. Takes a raw call and produces everything the rest of the path needs:

twenty-lead-brief  →  twenty-partner-shortlist  →  twenty-partner-intro

Four outputs, in order:

1. A qualification summary printed in the conversation. You can stop here.
2. A partner brief the partner reads to scope and quote.
3. partner-match-criteria.md, the input to twenty-partner-shortlist.
4. An Opportunity in the partners workspace, carrying the brief's URL.

Credentials, the gql() helper and every query live in ../_shared/partner-api.md. Read it rather than restating anything.

Step 1 — Get the transcript

The user provides it: pasted text, a path (.txt / .vtt / .srt, a meetily folder or transcripts.json), or a Fireflies link or ID.

• meetily transcripts.json is { "segments": [ { "text": … } ] }: concatenate text in order.
• .vtt / .srt: drop cue numbers and timecodes.
• Fireflies: fetch the transcript detail (see the shared reference). Needs FIREFLIES_API_KEY.

No transcript means stop and ask. Never fabricate one, never proceed without one.

For a long transcript, read the whole thing before writing. Coverage is the point.

Step 2 — The qualification summary

A structured extraction against a fixed schema, not a summary. A "summary that loses nothing" is a contradiction; the schema is what prevents loss, because every dimension has a slot and a gap is marked rather than silently dropped.

Rules

• Extract ONLY what is in the transcript. If a field isn't covered, write "Not discussed." A visible gap beats a confident fabrication: it is the signal to ask on the next call.
• Separate stated FACTS from your INFERENCES. Mark any inference "(inferred)". Downstream matching trusts the facts, so don't contaminate them with guesses.
• Preserve specifics verbatim: numbers, dates, names and roles, tool and CRM names, prices, budgets, exact requirements. Never round or paraphrase a number. Specifics are where the matching signal lives.
• Use the customer's own words for needs and objections. Quote pivotal lines.
• Don't smooth over a contradiction or a vagueness: note it. A flagged contradiction is more useful than a falsely tidy summary.
• With no speaker labels, infer from context who is Twenty and who is the prospect. Speech-to-text garbles names: flag an uncertain one "(uncertain)" and never invent one.
• Keep PART A tight: it is the one-pager the rest of the path runs on. Push anything not specific to this deal into PART B. State each fact once.

Output (these exact headers)

== PART A — DEAL ONE-PAGER ==

1. ONE-LINE SUMMARY
2. COMPANY — name, what they do, size/employees, HQ + countries of operation, industry
3. PEOPLE ON THE CALL — name, role/title, side (Twenty vs prospect); infer roles if
   unlabeled and flag uncertain names
4. CURRENT SITUATION — what CRM/tools they use today; specific pains
5. WHY THEY'RE INTERESTED IN TWENTY
6. WHAT THEY WANT — bulleted needs/requirements, verbatim where possible
7. IMPLEMENTATION COMPLEXITY (for partner matching)
   - Deployment: cloud / self-host / both / unclear  (+ the evidence)
   - Data model: custom objects, multi-tenant, row-level security, migrations
   - Integrations / custom apps needed
   - Workflows / automation needs
   - Scale: number of seats/users
   - Region + language the partner would need to cover
8. COMMERCIALS — budget or prices discussed, plan tier (Pro/Org/Enterprise), seat count,
   deal value, who pays
9. TIMELINE & DECISION — key dates, decision-makers, urgency, decision process
10. OBJECTIONS / RISKS / FEARS — including anything that could kill the deal
11. ALTERNATIVES — competitors or other options they're weighing
12. DOES THIS DEAL NEED A PARTNER? — yes / no / maybe + why; and if yes, what kind
    (scope, region, language, seniority/tier)
13. NEXT STEPS / OPEN QUESTIONS / FOLLOW-UPS
14. PARTNER-FACING BRIEF — a 2-4 sentence narrative a partner can skim to decide yes/no,
    drawn only from PART A

== PART B — APPENDIX (not deal-specific) ==

15. PRODUCT / WEBSITE / GTM FEEDBACK — feedback on the product, pricing page, website
    wording, onboarding, or trial; capture even if off-topic for qualification
16. TERMINOLOGY / DOMAIN-LANGUAGE NOTES — words that mean different things to each side or
    carry domain-specific meaning (e.g. "partner", "donor", jargon)
17. KEY VERBATIM QUOTES — 3-8 direct quotes that capture intent, needs, or objections

Print it, then save it to the lead folder as YYYY-MM-DD-<lead>-call-summary.md.

Stop here if the user only wanted the summary. Ask before continuing to Step 3: a lead that is clearly not partner-shaped (section 12 says no) does not need a partner brief.

Step 3 — The partner brief

The doctrine lives in design-doc-doctrine.md in this folder: what to produce, the structure, the rules, the verification, the self-check. Read it and follow it. The rest of this section is only the mechanics.

Default output is a zero-inference partner brief. Pass --full for the inference-enabled design doc. The doctrine defines both.

1. Gather — read every source material in full, not just the summary. Convert a .docx with textutil -convert txt "<file>" -output /tmp/out.txt on macOS.
2. Extract, grounded — facts vs inferences, per the doctrine.
3. Draft in the doctrine's section structure.
4. Verify load-bearing claims live — WebFetch against the doctrine's doc map before asserting any capability. Build the References appendix as you go.
5. Reconcile discrepancies — sources that disagree (call vs braindump, a name differing across sources) get flagged both ways, never silently resolved.
6. Resolve ❓ with the operator — after a full v1 draft, use AskUserQuestion for the unknowns a Twenty insider can answer. Leave customer-facing unknowns as ❓. Running autonomously (a subagent or batch run) means skipping the questions and leaving every unknown as ❓.
7. Run the doctrine's self-check, fix, then save as YYYY-MM-DD-<lead>-partner-brief.md (or -design-doc.md in --full).

Step 4 — Publish the brief as a Google Doc

The partner gets a link, never an attachment: a Gmail compose URL cannot carry a file, and a .md attachment is a poor read.

1. Open the shared Drive folder in Chrome:

open -a "Google Chrome" "https://drive.google.com/drive/folders/1ISDCplqLv6GrBQOOX7Fk4OK07LAK8BPd"

2. Tell the user: create the Doc there, paste the brief markdown, then paste the share URL back. Mention Tools → Preferences → Enable Markdown once, so the paste renders headings, bold and tables instead of showing raw ##.

3. Wait for the URL. If the user skips it, carry on with Step 5 and leave designDocUrl empty. Say so, because twenty-partner-intro will then have no link to send.

The folder is shared anyone with the link can view, so a partner can open it without an account. Do not call the Drive API: the connected account is personal, and any Doc it created would land in the wrong Drive under the wrong owner.

Step 5 — Write partner-match-criteria.md

Always, as a third file in the lead folder. This is the input twenty-partner-shortlist reads.

• Hard requirements — a Criterion | Why table. Cover language and region, deployment type, data-model complexity signal, migration capability, engagement model (fixed vs retainer).
• Strong preference — bullets: domain familiarity, migration experience, willingness to scope for free, ability to work with non-technical end-users.
• Nice to have — bullets: industry-specific workflow experience, partner size fit.
• Red flags — bullets: anything that would disqualify a partner silently (language, hosting model, engagement type, technical depth).
• Budget — what the client said about money, verbatim, or "not stated". Most calls never state a ceiling, and that is itself the answer. twenty-partner-shortlist shows this next to each partner's rate; it never filters on it.
• Matching notes — 3 to 5 bullets: technical nuances, the prospect's sophistication level, migration unknowns, who the decision-makers are. Draw from Open questions and Implementation complexity.

Step 6 — Record the Opportunity

This step writes to production. Search before creating, always.

1. Search for an existing Opportunity on the company name (see the shared reference). If one comes back, show it to the user and ask whether to update it or create a new one. Never create a silent duplicate.
2. Resolve the company and the point of contact: search first, create only on a miss.
3. Create the Opportunity:

Do not set isListed: that belongs to the marketplace pull flow, which this path does not use. Do not set introSentAt and do not create any Application: twenty-partner-intro owns both.

4. Verify by reading the record back, then print its id and name.

Output files

In the lead folder:

• YYYY-MM-DD-<lead>-call-summary.md
• YYYY-MM-DD-<lead>-partner-brief.md (or -design-doc.md in --full)
• partner-match-criteria.md

Notes

• Keep partner-match-criteria.md current as you learn more about the lead. It feeds twenty-partner-shortlist and, eventually, in-product matching logic.
• Sections 7 and 12 of the summary are the matching axes: Deployment → deploymentExpertise, scope needs → partnerScope, region and language → partner region and languages, scale → capacity, the "needs a partner?" tier → partnerTier.
• Worked example: partners-experience/TSF/2026-05-26-tsf-design-doc.md shows the target coverage, flag discipline and verification appendix. It predates the current concision and formatting rules, so follow the doctrine over the example where they differ.