@plaud-ai/mcp 0.1.58 → 0.2.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/chunk-4QBEOJPX.js +92 -0
- package/dist/chunk-7KGB7GSZ.js +33 -0
- package/dist/chunk-MPCF6HMK.js +151 -0
- package/dist/{chunk-YMQLKZLW.js → chunk-SNSGVRCU.js} +1 -101
- package/dist/chunk-UPEENHCG.js +70 -0
- package/dist/index.js +63 -57
- package/dist/install-TU2Y3ARS.js +370 -0
- package/dist/{server-5L7BYLYR.js → server-3256GMAD.js} +5 -15
- package/dist/{setup-KGUMS567.js → setup-7JTG3C2W.js} +17 -61
- package/package.json +14 -10
- package/plugin.json +1 -1
- package/skills/plaud-browse/SKILL.md +39 -0
- package/skills/plaud-digest/SKILL.md +41 -0
- package/skills/plaud-export/SKILL.md +51 -0
- package/skills/plaud-find/SKILL.md +54 -0
- package/skills/plaud-followup/SKILL.md +59 -0
- package/skills/plaud-read/SKILL.md +51 -0
- package/skills/plaud-shared/SKILL.md +67 -0
- package/dist/chunk-7PYQFJJW.js +0 -111
- package/skills/plaud/SKILL.md +0 -40
|
@@ -0,0 +1,51 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: plaud-export
|
|
3
|
+
version: 1.0.0
|
|
4
|
+
description: "Push Plaud content or a generated artifact to Notion, Slack, HubSpot, Linear, Gmail, or a custom webhook. Use when the user says 'save to Notion', 'post to Slack', 'send to webhook', 'file this in HubSpot', or asks to deliver recording content to an external system."
|
|
5
|
+
metadata:
|
|
6
|
+
requires:
|
|
7
|
+
bins: []
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
# plaud-export
|
|
11
|
+
|
|
12
|
+
**Read [`plaud-shared`](../plaud-shared/SKILL.md) first.**
|
|
13
|
+
|
|
14
|
+
## When to use
|
|
15
|
+
|
|
16
|
+
- User has a ready artifact (from `plaud-followup`) or recording content and wants to **deliver** it somewhere.
|
|
17
|
+
- Destination is an external system (not the chat).
|
|
18
|
+
|
|
19
|
+
## Out of scope
|
|
20
|
+
|
|
21
|
+
- Generating the artifact — that's `plaud-followup`.
|
|
22
|
+
- Reading recording content — that's `plaud-read`.
|
|
23
|
+
|
|
24
|
+
This skill is the final leg: take content that already exists and send it.
|
|
25
|
+
|
|
26
|
+
## Steps
|
|
27
|
+
|
|
28
|
+
1. **Confirm the payload.**
|
|
29
|
+
- Recording summary (raw `get_note` content)?
|
|
30
|
+
- Generated artifact (email, SOAP, brief — already drafted)?
|
|
31
|
+
- Raw transcript excerpt?
|
|
32
|
+
2. **Confirm the destination + identifiers.** Ask for the exact target. Plaud does not store destination credentials.
|
|
33
|
+
3. **Deliver using the MCP tool or integration available in the user's environment.** Plaud MCP itself does not expose a `push` tool — this skill assumes another MCP (Notion MCP, Slack MCP, a webhook tool, Gmail send) is available in the session.
|
|
34
|
+
4. **Report the delivery URL** (Notion page URL, Slack message permalink, webhook HTTP status) back to the user.
|
|
35
|
+
|
|
36
|
+
## Destination identifier cheat-sheet
|
|
37
|
+
|
|
38
|
+
| Destination | Required identifier | Typical ask |
|
|
39
|
+
|---|---|---|
|
|
40
|
+
| Notion | page ID or database ID | "Which Notion page should this go under?" |
|
|
41
|
+
| Slack | channel name or ID | "Which channel? (e.g., `#sales` or `C0123`)" |
|
|
42
|
+
| HubSpot / Salesforce | CRM object ID (deal / contact / company) | "Which deal/contact should this attach to?" |
|
|
43
|
+
| Linear | team or project ID | "Which Linear team or project?" |
|
|
44
|
+
| Gmail | recipient email(s) | "Who should this email go to?" |
|
|
45
|
+
| Webhook | full URL | "Paste the webhook URL" |
|
|
46
|
+
|
|
47
|
+
## Anti-patterns
|
|
48
|
+
|
|
49
|
+
- Never persist destination credentials in the conversation or in files. Assume the MCP host provides them.
|
|
50
|
+
- Never send to a default destination ("I'll put it in `#general`") — always confirm.
|
|
51
|
+
- Never alter the artifact content during delivery. If Slack needs mrkdwn, convert format without changing meaning.
|
|
@@ -0,0 +1,54 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: plaud-find
|
|
3
|
+
version: 1.0.0
|
|
4
|
+
description: "Find a specific Plaud recording by name keyword, date range, or topic. Use when the user says 'find the Weekly Sync', 'the meeting from Monday', 'the call about Q2', 'recordings last week', or describes what they're looking for rather than listing."
|
|
5
|
+
metadata:
|
|
6
|
+
requires:
|
|
7
|
+
bins: []
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
# plaud-find
|
|
11
|
+
|
|
12
|
+
**Read [`plaud-shared`](../plaud-shared/SKILL.md) first.**
|
|
13
|
+
|
|
14
|
+
## Background
|
|
15
|
+
|
|
16
|
+
Plaud's `list_files` API does **not** accept `query` / `date_from` / `date_to` server-side — unknown params are silently ignored. Filtering happens client-side.
|
|
17
|
+
|
|
18
|
+
The MCP `list_files` tool accepts the same three optional params and performs the filter for you: pass the user's keyword and/or date window and let the tool paginate up to 5 pages.
|
|
19
|
+
|
|
20
|
+
## Steps
|
|
21
|
+
|
|
22
|
+
1. **Elicit criteria if vague.** If the user just said "find a recording", ask for at least one of:
|
|
23
|
+
- a name keyword (even a partial match),
|
|
24
|
+
- a rough date or date range,
|
|
25
|
+
- a duration range (less useful, ask only if name and date fail).
|
|
26
|
+
2. **Call `list_files`** with the filter params you gathered:
|
|
27
|
+
- `query=<keyword>` — case-insensitive substring match on `name`.
|
|
28
|
+
- `date_from=YYYY-MM-DD`, `date_to=YYYY-MM-DD` — inclusive window on `created_at`.
|
|
29
|
+
- Omit any that the user did not specify.
|
|
30
|
+
3. **If zero matches**, ask the user to broaden one axis (shorter keyword, wider date range).
|
|
31
|
+
4. **If many matches** (> 10), return the top 10 sorted by `created_at` desc and mention the total.
|
|
32
|
+
5. **Never auto-load transcripts**. Present the match list and wait for the user to pick one — that triggers `plaud-read`.
|
|
33
|
+
|
|
34
|
+
## Date interpretation rules
|
|
35
|
+
|
|
36
|
+
| User phrase | Filter |
|
|
37
|
+
|---|---|
|
|
38
|
+
| "today" | `date_from` = today, `date_to` = today |
|
|
39
|
+
| "yesterday" | both = yesterday |
|
|
40
|
+
| "this week" | Monday of this week → today |
|
|
41
|
+
| "last week" | Monday of last week → Sunday of last week |
|
|
42
|
+
| "this month" | 1st of this month → today |
|
|
43
|
+
| "last month" | 1st → last day of previous month |
|
|
44
|
+
| "from Monday" | `date_from` = the most recent Monday, no `date_to` |
|
|
45
|
+
|
|
46
|
+
Resolve relative dates against the **current date** (from conversation context), not the model's training cutoff.
|
|
47
|
+
|
|
48
|
+
## Example
|
|
49
|
+
|
|
50
|
+
User: "find the customer onboarding call from last week"
|
|
51
|
+
|
|
52
|
+
Agent:
|
|
53
|
+
- `list_files(query="onboarding", date_from="2026-04-13", date_to="2026-04-19")`
|
|
54
|
+
- Return matches: "Found 2 recordings. `abc123` Customer Onboarding — Acme (2026-04-15, 42m), `def456` Onboarding Q&A (2026-04-17, 18m). Which one?"
|
|
@@ -0,0 +1,59 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: plaud-followup
|
|
3
|
+
version: 1.0.0
|
|
4
|
+
description: "Turn a Plaud recording into a follow-up email, thank-you note, action-item list, SOAP note, or meeting brief. Use when the user says 'draft follow-up', 'what were the action items', 'send thank-you email', 'turn this into a SOAP note', 'write the recap', or names an artifact to generate from a recording."
|
|
5
|
+
metadata:
|
|
6
|
+
requires:
|
|
7
|
+
bins: []
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
# plaud-followup
|
|
11
|
+
|
|
12
|
+
**Read [`plaud-shared`](../plaud-shared/SKILL.md) first.**
|
|
13
|
+
|
|
14
|
+
## When to use
|
|
15
|
+
|
|
16
|
+
- User wants a **generated document** grounded in one recording.
|
|
17
|
+
- Target format is explicit (email, SOAP note, brief, action-item list) or implicit ("write the follow-up").
|
|
18
|
+
- If the user wants to *send* the output to Notion / Slack / a webhook, chain into `plaud-export` after drafting.
|
|
19
|
+
|
|
20
|
+
## Steps
|
|
21
|
+
|
|
22
|
+
1. **Identify the recording.** If the user didn't name one, hand off to `plaud-find` or `plaud-browse`.
|
|
23
|
+
2. **Fetch source content.**
|
|
24
|
+
- `get_note` first — usually enough for summaries and action items.
|
|
25
|
+
- `get_transcript` only if the artifact needs verbatim quotes (e.g., legal memo) or speaker attribution (e.g., SOAP).
|
|
26
|
+
3. **Generate the artifact** in the requested format. Ground every claim in the source; do not invent attendees, dates, decisions, or numbers.
|
|
27
|
+
4. **Present to the user** in the chat, then ask if they want to refine or export.
|
|
28
|
+
|
|
29
|
+
## Artifact templates
|
|
30
|
+
|
|
31
|
+
### Follow-up email
|
|
32
|
+
- To: attendees (from notes if listed).
|
|
33
|
+
- Subject: "Follow-up — {recording name}, {date}".
|
|
34
|
+
- Opening line: thanks + one-line meeting summary.
|
|
35
|
+
- Body: 3–5 bullets of key points.
|
|
36
|
+
- Action items: numbered list with owner and due date if mentioned.
|
|
37
|
+
- Closing: "Let me know if I missed anything."
|
|
38
|
+
|
|
39
|
+
### Thank-you email
|
|
40
|
+
- Short. One paragraph. One concrete thing you learned or appreciated from the call.
|
|
41
|
+
|
|
42
|
+
### Action-item list
|
|
43
|
+
- Plain markdown: `- [ ] {owner}: {item} (due {date})`.
|
|
44
|
+
- Mark owner as `?` if unclear from notes — do not guess.
|
|
45
|
+
|
|
46
|
+
### SOAP note (clinical)
|
|
47
|
+
- **Subjective** — patient's words (from transcript).
|
|
48
|
+
- **Objective** — observations (from transcript, not inferred).
|
|
49
|
+
- **Assessment** — summary's diagnosis if present.
|
|
50
|
+
- **Plan** — action items and next appointment.
|
|
51
|
+
|
|
52
|
+
### Meeting brief
|
|
53
|
+
- Attendees, date, duration, decisions, risks, next steps.
|
|
54
|
+
|
|
55
|
+
## Anti-patterns
|
|
56
|
+
|
|
57
|
+
- Never invent email recipients. If attendees weren't captured, ask the user.
|
|
58
|
+
- Never invent due dates. Mark as `due: TBD` if not stated.
|
|
59
|
+
- Do not send the email — this skill drafts. Handoff to `plaud-export` for delivery.
|
|
@@ -0,0 +1,51 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: plaud-read
|
|
3
|
+
version: 1.0.0
|
|
4
|
+
description: "Read the transcript, AI summary, notes, or download audio for a specific Plaud recording. Use when the user says 'show the transcript', 'summarize this', 'what was said', 'get audio', 'the notes from', or names a specific recording to dig into. Also covers extracting structured fields from a recording."
|
|
5
|
+
metadata:
|
|
6
|
+
requires:
|
|
7
|
+
bins: []
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
# plaud-read
|
|
11
|
+
|
|
12
|
+
**Read [`plaud-shared`](../plaud-shared/SKILL.md) first.**
|
|
13
|
+
|
|
14
|
+
## When to use
|
|
15
|
+
|
|
16
|
+
- User names a specific recording (by name or ID) and wants to read its content.
|
|
17
|
+
- User asks for "transcript", "summary", "action items", "audio", "who said what", or a structured extraction ("action items, decisions, attendees").
|
|
18
|
+
- If the user did **not** specify a recording, hand off to `plaud-find` (by topic) or `plaud-browse` (by recency) first.
|
|
19
|
+
|
|
20
|
+
## Tool selection matrix
|
|
21
|
+
|
|
22
|
+
| User wants | Tool | Notes |
|
|
23
|
+
|---|---|---|
|
|
24
|
+
| AI summary, TL;DR, action items | `get_note` | Returns Markdown; usually enough — try this before `get_transcript` |
|
|
25
|
+
| Verbatim quotes, full dialogue | `get_transcript` | Timestamped; larger |
|
|
26
|
+
| Audio download link | `get_file` then use `presigned_url` | Link expires in 24h |
|
|
27
|
+
| Full metadata + availability flags | `get_file` | Check `source_list` / `note_list` populated before claiming content exists |
|
|
28
|
+
|
|
29
|
+
## Structured extraction workflow
|
|
30
|
+
|
|
31
|
+
If the user provides a schema (e.g., `{"action_items": [], "decisions": [], "attendees": []}`):
|
|
32
|
+
|
|
33
|
+
1. Call `get_note` first — the AI summary usually already contains these fields.
|
|
34
|
+
2. Only call `get_transcript` if the summary is missing a required field.
|
|
35
|
+
3. Return JSON matching the user's schema. Mark any missing field with `null` and note why.
|
|
36
|
+
|
|
37
|
+
Common schemas:
|
|
38
|
+
- Sales: `{ "pain_points": [], "follow_ups": [], "deal_stage": "" }`
|
|
39
|
+
- Clinical: `{ "diagnoses": [], "medications": [], "next_appointment": "" }`
|
|
40
|
+
- Project: `{ "action_items": [], "decisions": [], "attendees": [] }`
|
|
41
|
+
|
|
42
|
+
## Output
|
|
43
|
+
|
|
44
|
+
- Transcripts: preserve `[MM:SS - MM:SS] Speaker: content`. Do not reformat timestamps.
|
|
45
|
+
- Summaries: render Markdown directly in the reply.
|
|
46
|
+
- Audio: print the URL and mention "expires in 24h".
|
|
47
|
+
|
|
48
|
+
## Anti-patterns
|
|
49
|
+
|
|
50
|
+
- Do not call `get_transcript` speculatively — it's the largest payload.
|
|
51
|
+
- Do not paraphrase the AI summary unless the user asked; quote it verbatim.
|
|
@@ -0,0 +1,67 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: plaud-shared
|
|
3
|
+
version: 1.0.0
|
|
4
|
+
description: "First read before any Plaud operation. Auth flow, error handling, output conventions, token refresh. Use when the user mentions Plaud for the first time in a session, or when any other Plaud skill is invoked."
|
|
5
|
+
metadata:
|
|
6
|
+
requires:
|
|
7
|
+
bins: []
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
# plaud-shared
|
|
11
|
+
|
|
12
|
+
**CRITICAL — read this before calling any Plaud tool.** Applies to every other `plaud-*` skill.
|
|
13
|
+
|
|
14
|
+
## Authentication
|
|
15
|
+
|
|
16
|
+
- Plaud uses OAuth. Tokens are stored in `~/.plaud/tokens.json` and refreshed automatically.
|
|
17
|
+
- If any tool returns an auth error (message includes `Not authenticated` or `401`), call the `login` tool and wait for the browser callback. Do **not** retry the original tool until login returns success.
|
|
18
|
+
- Never ask the user to paste tokens. The `login` tool handles the whole flow.
|
|
19
|
+
|
|
20
|
+
## Tool inventory
|
|
21
|
+
|
|
22
|
+
| Tool | Purpose |
|
|
23
|
+
|---|---|
|
|
24
|
+
| `login` | Open browser for OAuth; blocks until callback or 2-min timeout |
|
|
25
|
+
| `logout` | Revoke and clear tokens |
|
|
26
|
+
| `get_current_user` | Verify who is signed in |
|
|
27
|
+
| `list_files` | Browse, paginate, filter recordings (supports `query`, `date_from`, `date_to`) |
|
|
28
|
+
| `get_file` | Full record incl. `presigned_url`, `source_list`, `note_list` |
|
|
29
|
+
| `get_note` | AI-generated summary and action items |
|
|
30
|
+
| `get_transcript` | Timestamped transcript with speaker labels |
|
|
31
|
+
|
|
32
|
+
## Error semantics
|
|
33
|
+
|
|
34
|
+
| Pattern in error message | Meaning | What to do |
|
|
35
|
+
|---|---|---|
|
|
36
|
+
| `401` / `Not authenticated` | Token missing or expired | Call `login`, then retry |
|
|
37
|
+
| `404` | File ID does not exist | Tell the user the ID is wrong; do not retry |
|
|
38
|
+
| `500` | Backend error (often an invalid ID too — see §7.1 of proposal) | Retry once; if still 500, treat as NOT_FOUND |
|
|
39
|
+
| `fetch failed` / `ECONNREFUSED` | Network problem | Abort; tell user to check connection |
|
|
40
|
+
|
|
41
|
+
## Output conventions
|
|
42
|
+
|
|
43
|
+
When presenting recordings to the user:
|
|
44
|
+
|
|
45
|
+
- Always show name, date, duration, and file ID — users need the ID to ask follow-up questions.
|
|
46
|
+
- Format durations human-readable: `23s`, `5m23s`, `1h05m`. Raw milliseconds are for logs only.
|
|
47
|
+
- Format dates as `YYYY-MM-DD` in local time.
|
|
48
|
+
- Transcripts: preserve `[MM:SS - MM:SS] Speaker: content` format.
|
|
49
|
+
- Notes: render Markdown directly.
|
|
50
|
+
|
|
51
|
+
## Data model quick reference
|
|
52
|
+
|
|
53
|
+
- `duration` field is **milliseconds**.
|
|
54
|
+
- `source_list` — array; each item with `data_type === "transaction"` holds the transcript segments (JSON-encoded string in `data_content`).
|
|
55
|
+
- `note_list` — array; each item with `data_type === "auto_sum_note"` holds the AI summary (Markdown in `data_content`).
|
|
56
|
+
- `presigned_url` — expires in 24 hours; re-fetch with `get_file` if stale.
|
|
57
|
+
|
|
58
|
+
## When to load which sibling skill
|
|
59
|
+
|
|
60
|
+
| User intent | Skill to follow |
|
|
61
|
+
|---|---|
|
|
62
|
+
| "List / show / browse my recordings" | `plaud-browse` |
|
|
63
|
+
| "Find the meeting about X" / "from Monday" | `plaud-find` |
|
|
64
|
+
| "Show transcript / summary / audio" | `plaud-read` |
|
|
65
|
+
| "Weekly digest" / "what did I have this month" | `plaud-digest` |
|
|
66
|
+
| "Draft follow-up" / "action items" / "thank-you email" | `plaud-followup` |
|
|
67
|
+
| "Save to Notion / Slack / webhook" | `plaud-export` |
|
package/dist/chunk-7PYQFJJW.js
DELETED
|
@@ -1,111 +0,0 @@
|
|
|
1
|
-
// src/skills.ts
|
|
2
|
-
var SKILLS = [
|
|
3
|
-
{
|
|
4
|
-
name: "search-recordings",
|
|
5
|
-
description: "Search and filter Plaud recordings by date, tag, or keyword",
|
|
6
|
-
content: `## Plaud Skill: search-recordings
|
|
7
|
-
|
|
8
|
-
There is no server-side search or filter API. To find a recording, fetch all pages from \`list_files\` and match client-side.
|
|
9
|
-
|
|
10
|
-
**Step 1 \u2014 Collect search criteria**
|
|
11
|
-
|
|
12
|
-
If the user's request is vague, ask for more specific information before fetching:
|
|
13
|
-
- Approximate date or time range?
|
|
14
|
-
- Rough title or topic to look for in the name?
|
|
15
|
-
|
|
16
|
-
The more specific the criteria, the earlier a match can be found during pagination.
|
|
17
|
-
|
|
18
|
-
**Step 2 \u2014 Fetch pages and match**
|
|
19
|
-
|
|
20
|
-
Call \`list_files\` starting from page 1. For each page, check if any recording matches the user's criteria by name, date, or duration. Continue fetching subsequent pages until a match is found or all pages are exhausted.
|
|
21
|
-
|
|
22
|
-
**Step 3 \u2014 Present results**
|
|
23
|
-
|
|
24
|
-
Show a clear list of matches: recording name, date, duration, and file ID. If no match is found, tell the user and suggest refining the criteria.
|
|
25
|
-
|
|
26
|
-
Do not fetch transcripts or notes unless the user explicitly asks to view the content of a specific recording.`
|
|
27
|
-
},
|
|
28
|
-
{
|
|
29
|
-
name: "extract-structured-data",
|
|
30
|
-
description: "Extract structured fields from a Plaud recording using a custom schema",
|
|
31
|
-
content: `## Plaud Skill: extract-structured-data
|
|
32
|
-
|
|
33
|
-
When the user wants to extract specific fields or structured information from a recording, follow this workflow:
|
|
34
|
-
|
|
35
|
-
1. If no recording is specified, call \`list_files\` and ask the user to identify the target
|
|
36
|
-
2. Call \`get_note\` to retrieve the AI-generated summary, action items, and key topics
|
|
37
|
-
3. Call \`get_transcript\` if the extraction requires full verbatim content
|
|
38
|
-
4. Apply the user's schema or field list to the content and return the extracted data
|
|
39
|
-
5. Present each field clearly; flag any fields where the content is ambiguous or absent
|
|
40
|
-
|
|
41
|
-
Example schemas the user might request:
|
|
42
|
-
- \`{ "action_items": [], "decisions": [], "attendees": [] }\`
|
|
43
|
-
- \`{ "pain_points": [], "follow_ups": [], "deal_stage": "" }\`
|
|
44
|
-
- \`{ "diagnoses": [], "medications": [], "next_appointment": "" }\``
|
|
45
|
-
},
|
|
46
|
-
{
|
|
47
|
-
name: "generate-artifact",
|
|
48
|
-
description: "Generate a document (email, summary, SOAP note, brief) grounded in a Plaud recording",
|
|
49
|
-
content: `## Plaud Skill: generate-artifact
|
|
50
|
-
|
|
51
|
-
When the user wants to generate a document grounded in recording content, follow this workflow:
|
|
52
|
-
|
|
53
|
-
1. Call \`get_note\` to retrieve AI-generated notes for the target recording
|
|
54
|
-
2. Call \`get_transcript\` if the artifact requires verbatim quotes or precise detail
|
|
55
|
-
3. Generate the artifact using the recording content as the source of truth
|
|
56
|
-
4. Format the output to match the requested artifact type
|
|
57
|
-
|
|
58
|
-
Common artifact types:
|
|
59
|
-
- **Follow-up email** \u2014 summarize key points, list action items, professional tone
|
|
60
|
-
- **Meeting summary** \u2014 attendees, decisions made, next steps
|
|
61
|
-
- **SOAP note** \u2014 Subjective / Objective / Assessment / Plan format for clinical use
|
|
62
|
-
- **Project brief** \u2014 background, goals, scope, timeline from a planning session
|
|
63
|
-
- **Weekly digest** \u2014 highlights across multiple recordings from the past week`
|
|
64
|
-
},
|
|
65
|
-
{
|
|
66
|
-
name: "synthesize-corpus",
|
|
67
|
-
description: "Analyze trends and patterns across multiple Plaud recordings",
|
|
68
|
-
content: `## Plaud Skill: synthesize-corpus
|
|
69
|
-
|
|
70
|
-
When the user wants to analyze patterns, trends, or themes across multiple recordings, follow this workflow:
|
|
71
|
-
|
|
72
|
-
1. Call \`list_files\` with date or tag filters to identify the target set of recordings (max 50 per call)
|
|
73
|
-
2. For each recording, call \`get_note\` to retrieve the AI-generated summary
|
|
74
|
-
3. Call \`get_transcript\` only if deeper analysis requires full verbatim content from specific recordings
|
|
75
|
-
4. Synthesize insights across all recordings:
|
|
76
|
-
- Recurring themes or topics
|
|
77
|
-
- Trends over time
|
|
78
|
-
- Consistent decisions or blockers
|
|
79
|
-
- Patterns in action items or follow-ups
|
|
80
|
-
5. Present findings with references to specific recordings as supporting evidence
|
|
81
|
-
|
|
82
|
-
Use date filters to scope the corpus (e.g., last week, last quarter, a specific project period).`
|
|
83
|
-
},
|
|
84
|
-
{
|
|
85
|
-
name: "push-to-destination",
|
|
86
|
-
supported: false,
|
|
87
|
-
description: "Send recording content or a generated artifact to Notion, HubSpot, Slack, Linear, or a webhook",
|
|
88
|
-
content: `## Plaud Skill: push-to-destination
|
|
89
|
-
|
|
90
|
-
When the user wants to send recording content or a generated artifact to an external system, follow this workflow:
|
|
91
|
-
|
|
92
|
-
1. Confirm what content to send: extracted data, a generated artifact, or raw notes
|
|
93
|
-
2. Confirm the destination and any required identifiers:
|
|
94
|
-
- **Notion** \u2014 page ID or database ID
|
|
95
|
-
- **HubSpot / Salesforce** \u2014 CRM object ID (deal, contact, or company)
|
|
96
|
-
- **Linear** \u2014 project or team ID
|
|
97
|
-
- **Slack** \u2014 channel name or ID
|
|
98
|
-
- **Webhook** \u2014 URL provided by the user
|
|
99
|
-
3. Deliver the content to the destination using the appropriate integration tool or API call available in your environment
|
|
100
|
-
4. Confirm successful delivery to the user
|
|
101
|
-
|
|
102
|
-
Note: Destination credentials (API tokens, webhook URLs) must be provided by the user. Do not store them in conversation history \u2014 use environment variables or the user's config.`
|
|
103
|
-
}
|
|
104
|
-
];
|
|
105
|
-
var ACTIVE_SKILLS = SKILLS.filter((s) => s.supported !== false);
|
|
106
|
-
var SKILLS_COMBINED = ACTIVE_SKILLS.map((s) => s.content).join("\n\n---\n\n");
|
|
107
|
-
|
|
108
|
-
export {
|
|
109
|
-
ACTIVE_SKILLS,
|
|
110
|
-
SKILLS_COMBINED
|
|
111
|
-
};
|
package/skills/plaud/SKILL.md
DELETED
|
@@ -1,40 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: plaud
|
|
3
|
-
description: Access and manage Plaud recordings, transcriptions, and meeting notes. Use when the user mentions Plaud, wants to find recordings, review transcripts, check meeting summaries, or manage their audio files.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
You have access to the user's Plaud recordings via MCP tools. Use them to help the user find, review, and analyze their recordings.
|
|
7
|
-
|
|
8
|
-
## Available tools
|
|
9
|
-
|
|
10
|
-
| Tool | When to use |
|
|
11
|
-
|---|---|
|
|
12
|
-
| `login` | User is not authenticated, or auth has expired |
|
|
13
|
-
| `logout` | User wants to sign out or disconnect |
|
|
14
|
-
| `get_current_user` | User asks who is logged in, or to verify account |
|
|
15
|
-
| `list_files` | User wants to browse, search, or find recordings |
|
|
16
|
-
| `get_file` | User wants full details of a specific recording (including download link) |
|
|
17
|
-
| `get_note` | User wants the AI-generated summary, action items, or key topics of a recording |
|
|
18
|
-
| `get_transcript` | User wants the full timestamped transcript with speaker labels |
|
|
19
|
-
|
|
20
|
-
## Typical workflows
|
|
21
|
-
|
|
22
|
-
**First-time use:** Call `login` first. If any tool returns an auth error, call `login` before retrying.
|
|
23
|
-
|
|
24
|
-
**Find a recording:** Call `list_files` to browse. Use pagination (`page`, `page_size`) if the user wants more results.
|
|
25
|
-
|
|
26
|
-
**Review notes or summary:** Call `get_note` with the file ID.
|
|
27
|
-
|
|
28
|
-
**Read transcript:** Call `get_transcript` with the file ID.
|
|
29
|
-
|
|
30
|
-
**Get full details (including download link):** Call `get_file` with the file ID. The response includes:
|
|
31
|
-
- `source_list`: timestamped transcript with speaker labels
|
|
32
|
-
- `note_list`: AI-generated summaries in Markdown
|
|
33
|
-
- `presigned_url`: temporary download link (valid 24 hours)
|
|
34
|
-
|
|
35
|
-
## Guidelines
|
|
36
|
-
|
|
37
|
-
- Always check if the user is logged in before calling data tools. If you get an auth error, call `login` first.
|
|
38
|
-
- When listing files, present results clearly with name, date, and duration.
|
|
39
|
-
- When showing transcripts, format them readably with timestamps and speaker labels.
|
|
40
|
-
- When showing notes, render the Markdown content directly.
|