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 "w

Preview of the first 4,000 characters. Read full instructions →

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 o

Preview of the first 4,000 characters. Read full instructions →

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 deta

Preview of the first 4,000 characters. Read full instructions →

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, 

Preview of the first 4,000 characters. Read full instructions →

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.
- **Sever

Preview of the first 4,000 characters. Read full instructions →

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 

Preview of the first 4,000 characters. Read full instructions →