OpenWhispr

View saved version →

---
name: ask-my-notes
description: Answer questions from the user's OpenWhispr notes, meeting transcripts and dictation history, saying which note it came from and when. Use this whenever the user asks what was said, decided, promised or discussed ("what did we decide about the launch date?", "when is the next draft due?", "find the note where I dictated the pricing ideas", "what did Sam think of the proposal?"), wants a brief before a meeting with someone ("prep me for my call with Acme"), or wants to look anything up in OpenWhispr, even if they don't name OpenWhispr.
argument-hint: "[question]"
---

# Ask my notes

Answer the user's question from what they captured in OpenWhispr, and show where each answer came from so they can trust it and find the original.

The OpenWhispr connector provides the tools used here (`search_notes`, `get_note`, `get_note_transcript`, `list_notes`, `list_transcriptions`, `list_folders`). If none of them is available, ask the user to connect OpenWhispr in their assistant's plugin or connection settings and sign in through the secure connection flow. Never ask for passwords, login codes or API keys in the conversation.

This skill only reads. Don't create, edit or delete anything while answering. If a brief or answer is worth keeping, offer to save it as a note and wait for a yes. When saving, always give `create_note` a `title`, because the desktop app can't import a note without one.

## 1. Search more than once

`search_notes` combines meaning-based and keyword search over the user's notes, including meeting notes. One phrasing often misses, so run two or three searches, limit 10 each:

- the distinctive nouns: names, companies, products, places ("Acme pricing page");
- the likely wording in the note itself ("go live", "sign-off");
- a broader topic, if the first two come back thin ("website timeline").

Merge the results. The `score` values only rank results against each other, so a low number doesn't mean a poor match. Read the candidates to decide which ones answer the question.

**Search doesn't read meeting transcripts.** It covers titles, the user's typed notes and the AI summaries. Recorded meetings often keep everything in the transcript under a title like "Untitled Note". So for anything said in a meeting, also page through `list_notes`, which returns newest first and includes each note's `transcript`, and look for the names or terms in the transcripts. Keep `limit` around 20 and stop after the period the question covers, or about 60 notes.

For time-based questions ("last week", "yesterday's call", "in September"), use each note's `created_at`. `list_notes` pages newest first. Keep `limit` around 20, because every item carries the full note text and transcript.

## 2. Read the source before answering

Search results can hold a lot of text, but the answer has to rest on what the note actually says:

- **Typed or dictated notes:** `content` is the user's own text. `enhanced_content`, when present, is an AI-cleaned version.
- **Meeting notes** (`note_type: "meeting"`): `get_note_transcript` gives the exact words. When the transcript starts with `[` it is a JSON list of segments:
  - `source: "mic"`, speaker `you`, is the user;
  - `source: "system"` is the other people on the call, labelled `speaker_0`, `speaker_1` and so on (shown in the app as "Speaker 1", "Speaker 2"), or by name when `speakerName` is set;
  - segment `timestamp` values aren't reliable clock times, so don't quote them.

  Use a person's name only when the note or transcript establishes it, for example when someone is addressed by name. If one speaker label covers several people, say "someone on the call" rather than guessing.
- **Uploaded recordings** (`note_type: "upload"`): the transcript is in `content`.

Skip stray fragments in transcripts, such as single words, snatches of another language or background chatter. They're usually microphone noise.

Quote short exact phrases when the wording matters, for example "we can't ship until legal signs off".

## 3. Dictation history

`list_transcriptions` returns past dictations, newest first. It has no search, so scan pages of 100 for the terms, up to about the 300 most recent, and say how far back you looked.

Each dictation's `text` is empty unless the user turned on **Cloud backup** in the OpenWhispr desktop app. Without backup the cloud keeps only word counts and timing. If every `text` comes back empty, tell the user their dictations can't be searched through the connector until Cloud backup is on (in the desktop app: **Settings → Privacy & Data → Cloud backup**). Then answer from their notes.

## 4. Answer

Lead with the answer, then the source for each claim, by title and date, never by ID:

> The pricing page goes live on 4 November, once legal signs off the new terms. Sam owns the copy changes.
> — from *Pricing sync with Acme* (meeting, 2 Oct 2026)

- **Notes disagree:** show both with their dates and say which is newer. The newer one usually reflects the latest decision.
- **Nothing found:** say what you searched for, then suggest why. The note may use other words, live in a team space (search covers personal notes only), or have been kept only on the device and never backed up.
- **Never fill gaps from general knowledge** as if it came from their notes.

## Meeting prep

When the user wants a brief before talking to someone ("prep me for my call with Acme"), search for the person and the company, then read the most recent two or three notes about them. Brief in this order:

1. **Last time:** the date and what the conversation was about.
2. **Decided:** what was agreed.
3. **Open:** action items still outstanding, and who owes them.
4. **Unanswered:** questions that are still open.
5. **To raise:** what's worth bringing up this time.

Keep it to what the notes support, and offer to save the brief as a note in the relevant folder.

View saved version →

---
name: dictionary-builder
description: Add names, jargon, acronyms and product terms to the user's OpenWhispr dictionary so dictation and transcription spell them right, and fix or remove dictionary words. Use this whenever the user wants OpenWhispr to recognise or spell words correctly ("add our client names to my dictionary", "it keeps writing 'cooper netties' instead of Kubernetes", "teach OpenWhispr the terms in this brief", "add the names from this repo"), asks to review, tidy, fix or delete dictionary entries, or complains that names come out wrong in their dictations or meeting transcripts.
argument-hint: "[words, or where to find them]"
---

# Dictionary builder

OpenWhispr's custom dictionary is the list of words it should spell exactly: people, companies, products, places, acronyms and jargon. OpenWhispr passes the list to the transcription engine as spelling hints.

**A short list beats a long one.** Some engines read only part of a long list. On-device transcription, for example, reads only about the last 150 words of it. The desktop app warns once the list passes about 550 characters. So add genuinely unusual words only, and leave everyday words out: they crowd out the words that matter without helping.

The OpenWhispr connector provides the tools used here (`list_dictionary`, `add_dictionary_words`, `update_dictionary_word`, `delete_dictionary_word`, and `search_notes` / `get_note_transcript` for mining meetings). If they aren't available, ask the user to connect OpenWhispr in their assistant's plugin or connection settings. Complete sign-in through the secure connection flow; never ask for a password, login code or API key in the conversation.

## 1. Gather candidate words

Work from whatever the user points at:

- **A list they typed:** take it as given. Step 2 still applies.
- **A document, email, brief or pasted text:** pull out names of people, companies, products and places that aren't household words, plus acronyms and domain terms with unusual spellings, such as "Kubernetes", "Ngozi Eze" or "Ballymaloe House".
- **A codebase or project folder** (when the assistant can read the files): product, company, service and library names the user would say out loud, and internal acronyms. Skip code identifiers such as `getUserId`, because people don't dictate those as written.
- **Their meetings or notes:** compare the names in note titles, participants and the existing dictionary with how the transcripts spell them. Propose the correct form for each mismatch, for example "Naka Mura" → "Nakamura".

Leave out ordinary words such as "invoice", "workshop" or "roadmap", generic terms and whole sentences. Keep the user's preferred spelling and capitalisation ("iOS", "McKinsey"). Add people by full name as one entry ("Ngozi Eze"), and add a first name on its own only if it's unusual and used alone.

## 2. Check what's already there

Page through `list_dictionary` with `limit` 500, passing `cursor` while `has_more` is true. Compare case-insensitively.

Leave words that already exist alone and list them as "already in your dictionary". Adding a word that differs only in capitalisation overwrites the existing entry's capitalisation, so never re-add one unless the user wants the casing changed.

## 3. Confirm, then add

- **The user typed an explicit list** and asked you to add it: add it without a confirmation round. It's exactly what they asked for.
- **You chose the words**, from a document, codebase or transcripts: show the list grouped as *People*, *Companies & products* and *Terms*, with anything you skipped and why, then ask before adding. The user should decide, since every word nudges future transcriptions.

Add everything in one `add_dictionary_words` call.

- **Per call:** up to 200 words.
- **Per word:** 1–100 characters, with no line breaks and no `<` or `>`.
- **Per account:** up to 5,000 entries.

Split bigger lists across calls. If the list is already long, suggest pruning stale entries alongside the new ones.

If the call is refused because the organisation's policy turns off cloud backup, say the dictionary can only be changed in the desktop app on that account.

Then report briefly, for example: "Added 9 words: Ngozi Eze, Ballymaloe House, … Already there: Kubernetes."

## 4. Fix or remove words

- **Fix a spelling:** call `update_dictionary_word` with the entry's `id` and the corrected word. If it's refused because the word is already used, the corrected spelling was probably deleted earlier, and OpenWhispr keeps deleted words reserved. In that case add the corrected word with `add_dictionary_words`, which restores it, then delete the misspelled entry.
- **Remove words:** show the exact entries first, get a yes, then call `delete_dictionary_word` for each.
- **Tidy-ups** ("clean up my dictionary"): suggest removing everyday words, near-duplicates ("Siobhan Kelly" next to "Shivon Kelly") and misspellings. Explain each suggestion and delete nothing without a yes.

## 5. Say when it takes effect

Tell the user the words are saved to their OpenWhispr account and apply to new dictations and transcriptions once the OpenWhispr app has synced. Recordings already transcribed don't change.

View saved version →

---
name: meeting-recap
description: Recap a meeting recorded in OpenWhispr by pulling the decisions, the action items with owners and due dates, and the open questions from its transcript, then save the recap back into OpenWhispr. Use this whenever the user asks to recap, summarize or write up a meeting, call, interview, 1:1 or standup, or wants its action items, next steps, minutes or follow-ups ("recap my call with Sam and save it", "what were the action items from this morning's sync?", "write up yesterday's kickoff into my Clients folder"), including the most recent meeting when none is named.
argument-hint: "[meeting name, person or date]"
---

# Meeting recap

Turn an OpenWhispr meeting into a recap the user can act on, and save it where they'll see it: on the meeting itself, in OpenWhispr.

The OpenWhispr connector provides the tools used here (`list_notes`, `search_notes`, `get_note`, `get_note_transcript`, `list_folders`, `update_note`, `create_note`). If they aren't available, ask the user to connect OpenWhispr in their assistant's plugin or connection settings. Complete sign-in through the secure connection flow; never ask for a password, login code or API key in the conversation.

## 1. Find the meeting

Recorded meetings are often titled "Untitled Note" and keep everything in their transcript, and `search_notes` doesn't read transcripts. So:

- **The user names it** by person, company, topic or day: run `search_notes` with those words. Also call `list_notes` with `limit` 20, which returns newest first and includes each note's transcript, and look for the names or topic inside the transcripts of meeting notes.
- **They don't name one** ("recap my last meeting"): call `list_notes` with `limit` 10 and take the newest note that has a transcript.
- **More than one plausible match:** ask which one. Show each candidate's title, date and opening line, and nothing more.

## 2. Read everything about it

Call `get_note`, then `get_note_transcript`.

- **Notes:** `content` holds what the user typed during the meeting. `enhanced_content` is the meeting's **AI Summary**, which the app shows in its own tab.
- **Transcript format:** the transcript comes back as text. When it starts with `[`, it is a JSON list of segments, each with `text`, a `source` (`mic` is the user, `system` is everyone else on the call) and usually a `speaker`:
  - `you` is the user;
  - `speaker_0`, `speaker_1` and so on are other voices, shown in the app as "Speaker 1", "Speaker 2";
  - `speakerName`, when set, is a real name.
- **Times:** segment `timestamp` values aren't reliable clock times, so don't quote them.
- **Uploaded recordings** (`note_type: "upload"`) keep their transcript in `content`, sometimes as `[Speaker 1] 00:00 - 00:12` blocks.

Read it with care:

- **Names:** use a person's name only when the note or transcript establishes it, from `speakerName`, from the participants, or from people addressing each other ("Thanks, Alex"). When one speaker label covers several people, write "the client said…" or "someone on the call…" rather than guessing who spoke.
- **Noise:** skip stray fragments, such as single words, snatches of another language or background chatter. They are usually microphone noise, not part of the meeting.
- **No transcript and no content:** say so plainly and stop. Don't recap an empty note.

## 3. Write the recap

The desktop app shows saved text in a Markdown editor. Use `##` and `###` headings, bullets and `- [ ]` checkboxes, and put a blank line between paragraphs. Don't use deeper headings, images or HTML, which don't display.

Use this structure, and leave out any section with nothing in it:

```markdown
## Summary

Two or three sentences: what the meeting was for and where it landed.

## Decisions

- What was agreed, in plain words.

## Action items

- [ ] Send the revised proposal — Sam, by Friday 24 Oct
- [ ] Book the photo shoot — owner not stated

## Open questions

- What was raised but not settled.

## Key details

- Dates, numbers, names, links and deadlines mentioned, exactly as said.
```

- **Stick to what was said.** If an owner or date wasn't stated, say so rather than inventing one. Users act on these lists.
- **Dates:** keep relative ones as spoken, adding the calendar date only when the meeting date makes it certain.
- **Length:** keep it readable in a minute. Longer meetings get more items, not longer items.

## 4. Save it back

Save the recap when the user asked for that ("…and save it"). Otherwise show it and offer to save it in one line.

**Default: the meeting's own AI Summary.** Use it when both are true:

- the meeting came from the OpenWhispr app, so `get_note` shows a `client_note_id`;
- its `enhanced_content` is empty.

In that case call `update_note` with the note's `id` and the recap as `enhanced_content`. The recap then appears in the meeting's **AI Summary** tab, synced to the user's devices. Never touch `content`, which holds the user's own notes.

**The meeting already has an AI Summary:** show what's there and ask whether to replace it or save the recap as a separate note.

**A separate note:** use one when the user asks for it, when replacing was declined, or when the meeting has no `client_note_id` because it was created outside the app. Call `create_note` with:

- a `title`, always, such as "Recap: <meeting title> (<date>)". The desktop app can't import a note without a title, and its syncing stalls.
- `content`: the recap;
- `folder_id`: the meeting's folder, or the folder the user named. Find its ID with `list_folders`, and ask before creating one.

**Two rules for any save:**

- Never send an empty string for `content` or `enhanced_content`. An empty value deliberately clears that field on every device.
- Offer a better title for a meeting still called "Untitled Note", such as "Acme kickoff (21 Oct)", only if it came from the app. Rename it with `update_note` only after a yes.

**After saving:** confirm where the recap went in one sentence. Don't paste the API response.

Never delete the meeting, its transcript or any other note as part of a recap.

View saved version →

---
name: snippet-builder
description: Create and manage OpenWhispr snippets, the spoken trigger phrases that OpenWhispr expands into saved text while the user dictates, such as email sign-offs, addresses, booking links, boilerplate replies and templates. Use this whenever the user wants a voice shortcut, text expansion, canned response or "a snippet for…", wants to list, change or delete snippets, or mentions dictating the same text over and over.
argument-hint: "[text to expand, or the snippet to change]"
---

# Snippet builder

A snippet is a trigger phrase plus replacement text. When the user says the trigger while dictating, OpenWhispr types the replacement. Good snippets save real typing and never fire by accident.

How matching works:

- OpenWhispr looks for the trigger anywhere in each finished dictation, ignoring case, as whole words, and replaces every occurrence.
- Punctuation must match exactly. If transcription writes "sign-off" where the trigger says "sign off", nothing happens.
- When triggers overlap, the longest one wins.
- Triggers are also passed to transcription as spelling hints, along with the dictionary.

The OpenWhispr connector provides the tools used here (`list_snippets`, `create_snippet`, `update_snippet`, `delete_snippet`). If they aren't available, ask the user to connect OpenWhispr in their assistant's plugin or connection settings. Complete sign-in through the secure connection flow; never ask for a password, login code or API key in the conversation.

## 1. Pin down the text

Get the exact replacement text: the link, address, sign-off or paragraph.

- **Keep it exactly as given.** Preserve line breaks and punctuation, and don't "improve" it unless asked.
- **Size limit:** replacements can be up to 5,000 characters.
- **Templates:** if the text should vary each time, keep the fixed part in the snippet and tell the user what they'll fill in after it expands.

## 2. Choose a trigger

A good trigger is:

- **Short and speakable:** two to four plain words. A single common word fires too often.
- **Distinctive:** a phrase the user wouldn't say in normal speech, because it expands wherever it appears, even mid-sentence. "my invoice footer" or "insert home address" are safer than "address".
- **Easy to transcribe the same way every time:** no punctuation, digits or symbols. Avoid words transcription may hyphenate or merge ("follow up" vs "follow-up"), and rare names or homophones it may spell differently.
- **At most 80 characters**, the desktop app's limit.

If the user gave a trigger, use theirs, and mention a problem only if it's likely to misfire. Otherwise suggest one, or two if there's a real choice.

## 3. Check the existing snippets

Page through `list_snippets` with `limit` 500, passing `cursor` while `has_more` is true. Look for:

- **The same trigger**, compared case-insensitively. `create_snippet` with a trigger that already exists doesn't fail: it silently replaces that snippet's text. So never create one without checking first.
- **A trigger that contains, or sits inside, the new one** ("invoice footer" and "my invoice footer"). These can clash, so pick a different phrase.
- **A snippet with the same purpose**, such as an older version of the same link or address. Show its current text and ask whether to update it or add a second one. Updating is usually what people want.

## 4. Confirm, then save

- **Create directly** when the user gave both the trigger and the text, or clearly asked for an update with the new text.
- **Otherwise** show the trigger and the replacement and ask before saving.

**To create one:** call `create_snippet` with `trigger` and `replacement`.

**To change one:**

- find it by trigger, compared case-insensitively;
- show the current text next to the new one;
- call `update_snippet` with its `id` and only the fields that change. Renaming to a trigger that is in use, or was deleted in the last 30 days, is refused; suggest another phrase.

**To delete one:** show it, get a yes, then call `delete_snippet`. Never delete a snippet just to recreate it. Update it instead.

## 5. Tell them how to use it

Close with one line, for example: *Say "my invoice footer" while dictating and OpenWhispr types the full footer.*

Mention that it works in new dictations once the OpenWhispr app has synced.

View saved version →

---
name: transcribe-recording
description: Transcribe audio files and recordings (interviews, voice memos, lectures, podcasts, call recordings) with OpenWhispr, then save the transcript as an OpenWhispr note, tidy it up or recap it. Use this skill first, before running any command or calling the connector's transcribe_audio tool, whenever the user asks to transcribe something or turn a recording into text or notes ("transcribe interview.m4a", "transcribe this voice memo for me", "get me a transcript of ~/Downloads/call.mp3", "turn these recordings into notes"). transcribe_audio can only carry clips of a few seconds. This skill uses the OpenWhispr command-line tool where the assistant has terminal access on the user's computer, and explains the desktop-app route everywhere else.
argument-hint: "<audio file> [--save to <folder>]"
---

# Transcribe a recording

Use the OpenWhispr command-line tool (`openwhispr`) to transcribe audio files, because it sends the file straight to OpenWhispr. The connector's `transcribe_audio` tool takes the audio inline in the tool call, as base64 text, and is capped at 3 MB, so every byte would have to pass through the conversation. That is only workable for a clip of a few seconds. Don't use it for real recordings.

## When commands can't run

If the assistant has no terminal on the user's computer, or cannot access the audio file there, it cannot run the local CLI. A hosted sandbox does not provide access to the user's desktop app or files. Explain the alternative in two lines: open the file in the OpenWhispr desktop app, which transcribes it into a new note, then ask the assistant about that note. The plugin's meeting recap and note search work on it from there.

## 1. Check the CLI

Run `openwhispr version`. The `transcribe` command needs version 0.3.0 or later.

If the command isn't found or is older, tell the user the install command and let them decide. Installing software on their machine is their call:

```bash
npm i -g @openwhispr/cli
```

It needs Node.js 20 or later.

## 2. Pick local or cloud

Run `openwhispr doctor`. It reports whether each backend can be reached.

| | Local (desktop app) | Cloud (`--remote`) |
|---|---|---|
| Needs | OpenWhispr desktop app open | Pro or Business plan, CLI signed in |
| Cost | Free | Counts toward 600 cloud minutes a month (beta) |
| Size | No limit | 4 MB per request. Larger files are split into 4-minute chunks, which needs `ffmpeg` installed |
| Privacy | Audio stays on the computer | Audio is uploaded to OpenWhispr. The file path is not |
| Extras | `--model <name>` picks a downloaded model | `--prompt` helps spell names |

Use local when the desktop app is reachable. Otherwise use cloud. Tell the user which one you're using and why.

If cloud isn't signed in, ask the user to run `openwhispr auth login` themselves. It asks for their OpenWhispr API key. The user creates one in the desktop app under Integrations → API keys, and it needs the `transcriptions:write` scope. Never ask the user to paste the key into the conversation.

## 3. Get names right (cloud)

For cloud runs, pass the names and jargon likely to come up in the recording with `--prompt`, for example `--prompt "Names: Sam Patel, Acme, Kubernetes"`. Take them from what the user says about the recording, or from their OpenWhispr dictionary (the connector's `list_dictionary`, or `openwhispr dictionary list`). Keep it to a few dozen of the most relevant terms. A short focused list helps more than the whole dictionary.

## 4. Transcribe

```bash
openwhispr transcribe "/path/to/recording.m4a" --format json
```

- **Quote paths** that contain spaces.
- **Formats:** wav, mp3, m4a, mp4 audio, ogg, flac and webm.
- **Video files:** if the CLI rejects one and `ffmpeg` is installed, extract the audio first with `ffmpeg -i in.mov -vn -c:a aac out.m4a`.
- **Long recordings** can take several minutes, since local runs allow up to 30. Use a long command timeout, and tell the user it's working.
- **Several files:** transcribe them one at a time and report each result.

**To save the transcript as a note** in the same step, add `--note --title "<title>" --folder "<folder name>"`:

- the folder must already exist, and `openwhispr folders list` shows the names;
- with no `--title`, the note is named after the file;
- the note lands in the account the backend uses: the desktop app's account for local, the signed-in account for cloud.

**Exit codes:**

| Code | Meaning | What to do |
|---|---|---|
| 2 | Backend unreachable | Open the desktop app, or use `--remote` |
| 3 | Not signed in, or the key lacks the scope | `openwhispr auth login` |
| 4 | Not found | Check the file path or folder name |
| 1 | Bad arguments | Read the message |

A plan error on cloud means the account isn't Pro or Business. Offer local instead.

## 5. Afterwards

Don't paste a long transcript into the chat unless the user asks. Show the first few lines, the length, and where it was saved. Then offer the useful next step:

- **Save it** as a note, if it wasn't saved already.
- **Tidy it up** into paragraphs with filler words removed, keeping the original wording available.
- **Recap it:** decisions, action items with owners and dates, and open questions. If it was saved as a note, the meeting-recap skill can write the recap back into OpenWhispr.

View saved version →

---
name: weekly-review
description: Review a week, or any date range, of the user's OpenWhispr notes and meetings, covering what happened, the decisions made and the action items and loose ends still open, grouped by folder, and optionally save the review back to OpenWhispr as a note. Use this for "weekly review", "what did I get done this week?", "summarize my meetings since Monday", "end-of-week recap", "what's still open from last week's calls?", monthly look-backs, or a Friday review routine. It looks back over what was captured. It is not for planning the week ahead from scratch, unless the user wants last week's open items carried forward.
argument-hint: "[date range, e.g. 'last week' or '1–15 Nov']"
---

# Weekly review

Turn a stretch of the user's OpenWhispr notes and meetings into a short review they can act on: what happened, what was decided, and what is still open.

The OpenWhispr connector provides the tools used here (`list_notes`, `list_folders`, `get_note_transcript`, `create_note`, `create_folder`). If they aren't available, ask the user to connect OpenWhispr in their assistant's plugin or connection settings. Complete sign-in through the secure connection flow; never ask for a password, login code or API key in the conversation.

## 1. Settle the window

Use the user's range if they give one. Otherwise:

- **"This week":** Monday to today.
- **"Last week":** the previous Monday to Sunday.
- **No range given:** the last 7 days.

Timestamps are in UTC. Use the user's local dates if you know their timezone. State the window at the top of the review, so a wrong guess is easy to spot.

## 2. Collect the notes

1. Call `list_folders` once and map folder IDs to names.
2. Page through `list_notes` with `limit` 20, passing `cursor` from each response. Notes come back newest first by creation date. Stop when a page reaches notes created before the window starts, or when `has_more` is false. Keep the page size small, because each item carries the full note text and transcript.
3. Keep the notes created inside the window. Notes created earlier but edited this week fall outside a creation-date scan. If the user wants those too, include any note whose `updated_at` is in the window and say so.
4. Skip empty notes, ones with no content and no transcript, which are often "Untitled" leftovers. Mention how many you skipped.

For each note, read the best available text:

- `enhanced_content`, the AI notes, when present;
- otherwise `content`;
- for meetings with neither, the `transcript` already in the list item. Call `get_note_transcript` only if that's missing.

In transcripts, `source: "mic"` is the user and `source: "system"` is the other people on the call. Ignore one-word fragments and background chatter.

## 3. Write the review

Keep it scannable. One line per item, real names and dates, nothing invented. If an owner or due date wasn't stated, write "owner not stated" rather than guessing.

```markdown
# Week of 3–9 Nov 2026

## Highlights
- 3–5 bullets: the most important outcomes of the week

## Meetings
- Mon 3 Nov — *Design standup*: agreed the Q1 priorities
- …

## Decisions
- …

## Open action items
- [ ] Owner — task — due date (from *note title*)

## Loose ends
- Questions raised but not answered, and things promised without a date

## By folder
- Work (4 notes), Clients (2), Ideas (3)
```

For a big window, more than about 40 notes, summarize folder by folder and keep **Highlights** to the top five. Say if anything was left out.

## 4. Offer to save it

Show the review first, then offer to save it as a note titled like "Weekly review — 3–9 Nov 2026":

- **Where:** the folder the user names. Otherwise use a "Weekly reviews" folder if one exists, or failing that their default **Personal** folder, and mention they can ask for a dedicated "Weekly reviews" folder (create it with `create_folder` only when they say yes).
- **How:** call `create_note` with a `title`, always (the desktop app can't import a note without one, and its syncing stalls), the review as `content`, and the folder's `folder_id`. Use the default `note_type`. The app shows notes in a Markdown editor: keep to `##`/`###` headings, bullets and `- [ ]` checkboxes, with a blank line between paragraphs.
- **Once saved:** confirm the title and folder. Don't paste the API response.

Save without asking only when the user already asked for it ("…and save it to my notes"). Save once: a note created through the connector doesn't update cleanly in the desktop app yet, so if the user wants changes, finish them in the chat before saving. Never edit or delete the notes being reviewed.