Generalize meeting-record sourcing: Plaud is one option, not the assumption
Bryan's correction: transcript source shouldn't be Plaud-specific. Google Meet, Teams, or no transcript at all (fall back to notes/task registry) are all real cases. Reworked Prerequisites and steps 3-5 so the skill asks which source applies instead of defaulting to Plaud and treating an empty result as 'no record exists.' Plaud-specific mechanics (official connector, id resolution via list_files, of_ prefix, pagination) kept as documented detail for when Plaud is the actual source, not as the only path.
This commit is contained in:
@@ -18,17 +18,36 @@ contract for what this skill's output actually contains.
|
||||
## Prerequisites
|
||||
|
||||
This skill uses, but does not own, the following connected tools — confirm they're
|
||||
reachable before starting, and degrade gracefully (see Hard Rules) if one isn't:
|
||||
- **Plaud** — meeting transcripts (recap: current meeting; agenda: previous meeting).
|
||||
Use the official `Plaud` connector (`get_current_user`, `list_files`, `get_file`,
|
||||
`get_transcript`, `get_note`) — **not** the older `Plaud MCP` connector, which
|
||||
predates Plaud's own official one and should be treated as deprecated. Resolve a
|
||||
recording's `file_id` via `list_files` (filter by `query`/`date_from`/`date_to`) —
|
||||
never assume a Plaud web-app URL's slug is the API `file_id` directly; the API id
|
||||
carries an `of_` prefix the web URL does not show. `get_transcript` paginates
|
||||
(`next_cursor`) — loop until it's null before treating the transcript as complete.
|
||||
`get_note` returns the AI summary/action items tab separately from the raw
|
||||
transcript — worth pulling alongside `get_transcript`, not instead of it.
|
||||
reachable before starting, and degrade gracefully (see Hard Rules) if one isn't.
|
||||
|
||||
**Meeting record — the source varies. Ask, don't assume Plaud.** Recap mode needs
|
||||
*some* record of what was discussed; which kind depends on how MPM actually recorded
|
||||
that particular meeting, which isn't fixed. In rough order of how much structure they
|
||||
give you, and check whichever plausibly applies rather than defaulting to the first one
|
||||
tried before:
|
||||
- **Plaud** — if used, the official `Plaud` connector (`get_current_user`,
|
||||
`list_files`, `get_file`, `get_transcript`, `get_note`) — **not** the deprecated
|
||||
`Plaud MCP` connector. Resolve a recording's `file_id` via
|
||||
`list_files(query=...)` — never assume a Plaud web-app URL's slug is the API
|
||||
`file_id` directly; the real id carries an `of_` prefix the web URL doesn't show.
|
||||
`get_transcript` paginates (`next_cursor`) — loop until null. `get_note` returns the
|
||||
AI summary/action-items tab separately — worth pulling alongside the transcript.
|
||||
- **Google Meet transcript** — typically lands as a Google Doc in Drive (often in a
|
||||
"Meet Recordings" folder or attached to the Calendar event) — search Drive/Calendar,
|
||||
don't assume it doesn't exist just because Plaud has nothing.
|
||||
- **Teams transcript**, or any other recording tool MPM starts using — same principle:
|
||||
ask where it lives before concluding no record exists.
|
||||
- **No transcript at all** — perfectly valid. Fall back to whatever does exist for that
|
||||
meeting: the person's own notes, a task registry, prior emails/Chat about it. State
|
||||
plainly in Notes & Flags that no transcript was available and the brief is built from
|
||||
secondary sources — this is the never-fabricate rule applying to the *source*, not
|
||||
just the content.
|
||||
|
||||
If it's not obvious which source applies, **ask the person** rather than trying each
|
||||
connector in sequence and treating empty results as "nothing exists here." An empty
|
||||
result from one source is not evidence the meeting has no record at all.
|
||||
|
||||
Other tools this skill uses:
|
||||
- **Odoo** (MCP) — linked Project/tasks, Sales/Purchase Orders, Knowledge Base,
|
||||
Helpdesk tickets
|
||||
- **Google Workspace** (MCP) — Gmail, Google Chat, Drive, Sheets
|
||||
@@ -61,17 +80,18 @@ table for cross-referencing other MPM document types about the same real-world t
|
||||
principle; don't merge their content into this ledger, just reference them).
|
||||
|
||||
### 3. Determine mode: Agenda or Recap
|
||||
Agenda mode (pre-meeting prep) pulls the *previous* meeting's transcript and any
|
||||
updates since. Recap mode (post-meeting) pulls the *current* meeting's transcript. Ask
|
||||
if not specified by the request.
|
||||
Agenda mode (pre-meeting prep) pulls the *previous* meeting's record and any updates
|
||||
since. Recap mode (post-meeting) pulls the *current* meeting's record. Ask if not
|
||||
specified by the request. "Record" — see Prerequisites above — is whatever source
|
||||
actually applies for that meeting, not necessarily Plaud.
|
||||
|
||||
### 4. Capture and normalize attendees
|
||||
- **First run for this topic:** ask who's attending / who attended.
|
||||
- **Recurring topic:** pre-fill from the manifest's last attendee list and ask "same as
|
||||
last time, or any changes?" — not a blank-slate interview.
|
||||
- **Recap mode with a Plaud transcript available:** prefer *actual* attendance from the
|
||||
transcript's speaker attribution over the pre-meeting expected list — someone who
|
||||
showed up unexpectedly and spoke shouldn't be treated as absent.
|
||||
- **Recap mode with a transcript available (any source):** prefer *actual* attendance
|
||||
from the transcript's speaker attribution over the pre-meeting expected list —
|
||||
someone who showed up unexpectedly and spoke shouldn't be treated as absent.
|
||||
- **Normalize into two groups:**
|
||||
- Internal MPM attendees — record by name for the brief; no further resolution
|
||||
needed (no external allowlist implications for this brief type).
|
||||
@@ -85,7 +105,8 @@ if not specified by the request.
|
||||
### 5. Pull data, scoped to what this brief type actually needs
|
||||
Not a monolithic "pull everything" — internal-meeting-brief's real needs, based on the
|
||||
first run, are:
|
||||
- Plaud transcript (per mode, above) — the primary source
|
||||
- The meeting record (per mode, above) — the primary source, whichever tool it
|
||||
actually lives in
|
||||
- Gmail / Google Chat: updates since the manifest's last-meeting date, scoped by
|
||||
project/topic keywords, never a blanket search
|
||||
- Odoo Project tasks, if a linked project exists (expect this to be sparse or absent —
|
||||
|
||||
Reference in New Issue
Block a user