twenty-partner-recap

Network upkeep, not the lead path. After a batch of partner calls: pull the Fireflies meetings, work out which partner each one is, summarize the call, and drop that summary as a Note on the partner's profile. Runs end to end with no per-note confirmation.

The recap notes it writes are what twenty-partner-shortlist later reads to tell a real capability from a partner's own marketing copy. Roughly 5 of the 29 validated partners have one today, so every run makes the shortlist better.

Optional --prune: after the recaps are safely in the CRM, delete the corresponding Fireflies recordings to free storage. Confirmed first, see Phase 6.

Credentials, the gql() helper and every query live in ../_shared/partner-api.md. This skill needs all three keys.

---

Phase 1 — Pull meetings

Default scope: the last 2 days, which covers "yesterday". The user can override per run: "last week", a date, or pasted Fireflies URLs and IDs.

List recent transcripts, keep the ones inside the window (date is epoch milliseconds), then fetch each kept transcript's detail.

If two transcripts share the same partner and day (Fireflies sometimes double-records), keep the one with more sentences.

---

Phase 2 — Match each meeting to a Partner

Only a meeting tied to an existing Partner gets processed. A lead or discovery call has no Partner match: skip it and list it at the end.

1. Page through all partners once, building two maps:
   • email → partner from every persons.edges.node.emails.primaryEmail
   • domain → [partners] from each company.domainName.primaryLinkUrl
2. For each meeting, take the attendee emails and drop anything @twenty.com plus the host and organizer: that is the Twenty side. For each remaining attendee:
   • Exact email match wins. It is the strongest signal.
   • Otherwise domain match, skipping free providers (gmail.com, outlook.com, hotmail.com, yahoo.com, icloud.com, proton.me and friends). Exactly one partner on the domain means a match. Several means flag it in the report and skip, never guess.
3. The meeting title is a secondary hint only (Partner intro between … and <name> was the historical convention). Never the primary matcher.

---

Phase 3 — Summarize, transcript first

Judge content quality before writing. Never write a note from nothing or from noise.

• A transcript is usable only with real content: roughly 15 sentences or more and an average of 4 words or more per sentence. A handful of one-word lines (Platform. Opportunity. Background.) is garbled ASR, not a transcript. Treat it as unusable even though the array is not empty.
• Usable transcript → write the recap yourself from the transcript. The default whenever one exists.
• No usable transcript but a Fireflies summary exists → fall back to summary.overview, then richer fields, then short_summary. Note the fallback in the source line.
• Neither → the call is still processing or was never recorded. Skip it, record it as "skipped: content not ready", move on. Today's calls often land here for a while. Never inject an empty or placeholder note.

Write the note in English, structured. No em dashes: use a colon or a comma.

**TL;DR:** one-line verdict / state of the relationship.

**Profil:** team size, location, languages, structure.
**Compétences Twenty:** deployment (cloud / self-host), data model, migrations, what they've
actually shipped.
**Contexte:** background, how they found Twenty, motivation, target clients, current
partnerships.
**Next steps:** concrete follow-ups (who owes what).
**Flags:** risks, unknowns, ASR artifacts to double-check.

Source: Fireflies <transcript-id> (call <YYYY-MM-DD>, transcript|summary).

The Source: Fireflies <transcript-id> line is load-bearing: it is the dedup key for re-runs and the prune key for Phase 6. Always include the real transcript id.

Compétences Twenty is the section that matters downstream. It is the only place a verified capability gets recorded, as opposed to what the partner writes about themselves. State what they have actually shipped, not what they say they can do.

---

Phase 4 — Inject the Note

For each matched meeting, check first whether it was already noted: read the partner's notes (noteTargets filtered by targetPartnerId) and look for a body containing Fireflies <transcript-id>.

• No such note → createNote with bodyV2.markdown, then createNoteTarget linking noteId to targetPartnerId. Title: Partner call recap: <Partner name> (<YYYY-MM-DD>).
• Note exists → regenerate the recap, diff it against the existing body, and append only net-new information under a dated **Update <YYYY-MM-DD>:** block via updateNote. Nothing new means leaving it untouched.

No confirmation step: match, summarize, write. Then verify each write by reading the note back and confirming the partner link resolved.

---

Phase 5 — Report

One table:

Action is one of created, updated (appended), unchanged, skipped: no partner match, skipped: ambiguous domain (N partners), skipped: content not ready. End with the counts.

---

Phase 6 — Prune (--prune, opt-in, deletes Fireflies recordings)

Runs only with --prune. Fireflies storage fills up, and a recording whose content is already safe in the CRM is dead weight. Deletion is irreversible and on an external service, so always confirm before deleting.

A recording is safe to prune only when its recap note was confirmed written this run (created or updated), or already exists in the CRM with this transcript's Fireflies <id> in its body. Never prune a meeting that was skipped, has no note, or whose note you could not verify: losing the recording loses the only copy.

1. Build the prune set from this run's safe meetings. If asked to "free more", add existing recap notes whose Fireflies <id> resolves to a still-present transcript.
2. Present the exact list (partner, transcript id, date) and get explicit confirmation. Default to keeping the most recent unless told otherwise.
3. Delete each confirmed transcript with deleteTranscript(id:), then verify by re-listing and confirming the ids are gone. Report deleted N/M and how many remain.

Matching old notes back to transcripts: notes written before this skill embed only a date, not an id, so fall back to the meeting-title person name (Partner intro between … and <name>, … - <name> x Rashad) against the partner name in the note title. Notes written by this skill carry Fireflies <id> in the body, so the mapping is exact going forward.