Skip to content
cccskills
FreePublished on GitHub

find-in-granola

Find what people said, decided, or promised in Granola meetings. The skill narrows meetings by date and participants, checks notes before transcripts, distinguishes decisions from discussion, and supports each finding with its meeting title and date.

OriginalShow the original description

Answer "what did we say, decide, or promise" from Granola meeting notes — narrow to the meetings that can hold the answer, read the notes before the transcript, and cite the meeting behind every claim. Use when the user asks what happened in a meeting, what a customer or teammate said, what was decided or promised, or refers to a call, sync, standup, or demo.

See how to install

Good for

  • Checking decisions from last week's customer call
  • Verifying the exact wording of a commitment
  • Reviewing customer feedback across multiple meetings
  • Checking unresolved topics in recurring meetings

Files included (1)

  • SKILL.md3.2 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Find what was actually said

Meeting notes are what people remembered, plus a summary a model wrote afterwards. The job is to locate the right meeting, read what it records, and separate what was decided from what was merely discussed.

1. Narrow to the meetings that can contain the answer

Start from list_meetings scoped by time range and involvement, not from a broad query. "The customer call last week" is a date range and an attendee, not a keyword. If the user names a folder or team space, list_meeting_folders first and list inside it. When results look empty, get_account_info tells you which email and workspace you are reading from — a personal account connected where the work one was meant is the usual cause, so say which one you searched.

2. Notes first, transcript only when the wording matters

get_meetings returns the summarized notes and any private notes, which is enough for "what was decided". Reach for get_meeting_transcript only when the exact phrasing matters — a commitment, a number, a quote the user wants verbatim — and quote the line rather than paraphrasing it. Transcripts are long; read them for the passage you need, not front to back.

3. Ask the question tool questions, not lookups

query_granola_meetings answers a natural-language question across many meetings and cites its sources. Use it when the question spans meetings ("what have customers said about pricing this quarter"). Do not use it to fetch a meeting you already identified — read that one directly, because a synthesized answer blurs which meeting said what.

4. Separate decided from discussed

Notes mix proposals, objections, and outcomes. Report a decision only when the notes record one — an action item, an "agreed", an owner and a date. If the notes show discussion without a conclusion, say the question was raised and not resolved; that is a real answer.

5. Cite the meeting

Every claim names the meeting title and date it came from, with a link when the tool returns one. Two meetings that disagree are a finding to report, not a conflict to resolve silently — the later one is not automatically right.

Anti-patterns

  • Searching by keyword when the user gave you a date or a person. Meeting titles rarely contain the topic; attendees and dates find the meeting.
  • Quoting the summary as if someone said it. Summaries are generated; only the transcript holds words people actually spoke.
  • Reading one instance of a recurring meeting. A weekly sync decides things across weeks; check the neighbours before saying something was never raised.
  • Reporting "no meetings found" without the scope. Name the workspace, folder, and time range you searched, so an empty result can be checked.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

10x

FreeSummary

Review how you use Superset and identify unused features that fit your workflow. Get a short list of suggestions, learn about each option, and set up selected features such as scheduled agents, parallel workspaces, or shared tasks.

  • Find unused Superset features worth exploring
  • Set up scheduled agent tasks
  • Start parallel work in separate workspaces
superset-sh/superset15.3KUpdated Oct 18, 2026

automate

FreeSummary

Set up recurring tasks in Superset with an agent prompt, a schedule or event trigger, and a chosen execution workspace. After explicit confirmation, create the automation, check its saved settings, and review a real first run.

  • Scheduling a daily or weekly agent task
  • Starting agent work when a GitHub pull request opens
  • Triggering tasks from selected Slack reactions
superset-sh/superset15.3KUpdated Oct 18, 2026

browser

FreeSummary

Browse pages, click controls, fill fields, and inspect screenshots or console messages through Superset's browser pane. Use it to preview a running web app, check interface behavior, and work through browser tasks in a visible session.

  • Preview a locally running web app
  • Capture screenshots of a page
  • Inspect console errors
superset-sh/superset15.3KUpdated Oct 18, 2026

Build Stripe payments, subscriptions, and invoicing using verified documentation and API parameter definitions. The skill guides product selection, sandbox testing, and webhook handling, where server notifications determine payment and subscription state.

  • Choose Stripe products for payments or recurring billing
  • Implement Checkout or invoice flows
  • Investigate Stripe code that compiles but behaves incorrectly
superset-sh/superset15.3KUpdated Oct 18, 2026

cdp-verification

FreeSummary

Verify desktop UI changes through the Chrome DevTools Protocol, a connection for controlling the running app. Reproduce the user’s actual steps and compare screenshots, measured state, and console errors to establish evidence before and after a fix.

  • Reproducing reported bugs in the running app
  • Comparing UI behavior before and after a fix
  • Checking state across navigation and reopening
superset-sh/superset15.3KUpdated Oct 18, 2026

ci-triage

FreeSummary

Diagnose failed GitHub Actions runs by finding the first meaningful error, separating code problems from infrastructure issues and intermittent failures, and comparing the base branch. Get a focused report explaining the PR’s involvement and recommended next steps.

  • Investigating failed PR checks
  • Separating intermittent test failures from code defects
  • Checking whether the base branch already fails
superset-sh/superset15.3KUpdated Oct 18, 2026

See all skills by superset-sh

Report a problem with this skill