I Built a Meeting Notes Gem — Here's What It Actually Does

Keywords: meeting notes, AI note taking, Gemini Gem, action items, meeting summary, follow-up emails, engineering meetings

Reading time: ~7 minutes

I sit in a lot of meetings. Some of them produce decisions and action items. Some of them produce a lot of talking. The challenge is turning what gets said into something useful and shareable before everyone forgets what was agreed.

My Meeting Notes Gem handles that conversion. It takes raw notes — the kind you type quickly while someone is still talking — and produces structured summaries with clear decisions, action items, and owners. The output is something I can actually send to the team without spending another 20 minutes cleaning it up.

The Problem I Was Trying to Solve

Three specific problems kept showing up with meeting follow-ups before I built this Gem:

First, action items that disappeared. A meeting would end with verbal commitments — "I'll send the spec draft by Friday," "Can you check the config and report back?" — and a week later nobody could remember who agreed to what. The notes I took were accurate but unstructured, and the commitments were buried somewhere in the middle of paragraphs.

Second, summaries that took too long to write. By the time I cleaned my raw notes into something shareable, half the team had already moved on to the next meeting. The follow-up was either never sent or sent so late it didn't help.

Third, inconsistency in what got captured. Some meetings I'd capture everything; others I'd forget to note key decisions. There was no standard for what a "good" meeting summary looked like, so the quality varied by how tired I was, how much I was participating, or how good the meeting was in the first place.

I wanted a way to turn raw notes into a consistent, structured output fast enough that the follow-up could happen the same day.

What I Tried First (and Why It Wasn't Enough)

My first approach was a meeting notes template I copied into a new doc for each meeting. The template had sections for decisions, action items, and discussion. The structure was right but the actual filling-in took 15–20 minutes per meeting — which often meant I skipped it for back-to-back meetings.

Second was using a generic AI to clean up my raw notes. This worked but the context had to be re-pasted each session, and the AI would sometimes miss action items or reformat things in ways that didn't match what the team expected.

Third was a more structured note-taking approach during meetings: typing action items in a specific format as they came up. This helped but I was already taking raw notes; converting to a structured format in real-time added cognitive load I didn't want.

What I wanted was a tool that took my messy raw notes and produced a clean, structured output in seconds — not in minutes.

The Meeting Notes Gem did exactly that.

The Gem I Use

Here's the core of the instructions I saved into the Gem:

You are my meeting notes assistant. You take raw meeting notes (typed quickly, often messy) and produce structured summaries.

When I share raw notes from a meeting:

  • Extract decisions (with the decision, not the discussion)
  • Extract action items (what, who, when) — flag any action item that has no clear owner or deadline
  • Summarize key discussion points briefly — what was discussed, not who said what
  • Use a consistent output structure every time: Decisions, Action Items, Discussion Summary, Open Questions
  • Don't invent content — if something isn't in the notes, say "not captured" rather than guessing
  • Keep the output short enough to read in 60 seconds

My context: engineering team meetings. Notes go to internal distribution. Format is plain text or simple markdown. No need for formal report styling.

The "don't invent content — if something isn't in the notes, say 'not captured' rather than guessing" instruction is the one I undervalued at first. It's the most important. The default tendency of any AI is to fill in gaps. In a meeting summary, that means inventing decisions or assigning action items to people who didn't agree. The "not captured" instruction prevents that.

Two Real Examples — Before and After

These are based on actual meetings. Names and details are changed but the raw notes and the outputs are representative.

Example 1: Sprint Planning Meeting

Situation. A 90-minute sprint planning meeting with the team. I typed rough notes throughout. The meeting covered capacity, story estimates, dependencies, and a few open questions. By the end I had about 40 lines of raw notes with names, action verbs, and shorthand.

What I asked the Gem (raw notes excerpt):

"sprint 23 planning. capacity: j 60%, m 80%, s out friday. stories: ticket 4521 estimated 5 (j), ticket 4522 8 (m), ticket 4523 3 (s), ticket 4524 13 (j+m), ticket 4525 5 (?). j took 4521 and 4524 first half, m 4522 and 4524 second half. s on bug triage. dep on 4524 is the api rate limit issue we discussed last week - j said he'll talk to vendor about higher limit, no eta yet. cut ticket 4525 - too big, punt to next sprint. questions: who reviews the migration PR? m said he'd ask around."

Gem's output:

Decisions

  • Cut ticket 4525 from sprint 23 — too large, deferred to next sprint

Action Items

  • J: tickets 4521 + first half of 4524
  • M: ticket 4522 + second half of 4524
  • S: bug triage (S out Friday)
  • J: contact API vendor about rate limit increase for 4524 dependency — no ETA, follow up next sprint if no response
  • M: find a reviewer for the migration PR — owner not confirmed yet

Discussion Summary

Sprint 23 capacity: J at 60%, M at 80%, S out Friday. Four stories committed (4521, 4522, 4523, 4524) totaling 29 points. Story 4524 has a dependency on the API rate limit issue, which J is escalating with the vendor. Story 4525 cut due to size.

Open Questions

  • Migration PR reviewer — M to find someone, no name yet
  • Vendor response on rate limit — no ETA, no clear escalation path if they don't respond

What the Gem got right. It extracted the action items with owners and the decision with the decision (not the discussion). It separated "who does what" from "what was decided" cleanly. It flagged the open questions — the migration PR reviewer and the vendor response — which were items that needed follow-up but didn't have owners yet. The output was short enough to read in 60 seconds, as the instructions specified.

What I changed before sending. About 5% — I added a "Next sync" line with the date, removed one open question that I'd already followed up on, and corrected a name typo. The structure and most of the content was the Gem's.

Example 2: Vendor Escalation Call

Situation. A 45-minute call with a vendor about a recurring issue. Notes were particularly messy because I was on the call (not typing) and had to reconstruct some from memory and a few text messages I sent myself.

What I asked the Gem:

"vendor call - acme networks. issue: 3 sla misses in past month. they say it's a staffing issue, new person on rotation, training period. they offered to add backup contact for 60 days. we pushed for monitoring integration, they're not ready. action: they'll send revised escalation policy by next tuesday. need to decide internally: accept backup contact, or escalate to account exec? not captured: name of new rotation engineer, timeline for monitoring integration."

Gem's output:

Decisions

  • Acknowledge vendor's offer of a 60-day backup contact pending internal decision

Action Items

  • Vendor: send revised escalation policy by next Tuesday
  • Justin: decide internally whether to accept backup contact offer or escalate to account exec

Discussion Summary

Three SLA misses in the past month attributed by vendor to a new person on rotation undergoing training. Vendor offered a 60-day backup contact to bridge the transition. We asked about monitoring integration, which they said isn't ready yet — timeline not provided.

Open Questions

  • Name and tenure of the new rotation engineer — not captured
  • Timeline for monitoring integration — not provided by vendor
  • Internal: accept backup contact vs. escalate to account exec — decision pending

What the Gem got right. It preserved the "not captured" markers from my notes — the new engineer's name and the integration timeline. It didn't invent those. The "accept backup contact vs. escalate to account exec" open question was exactly the kind of item that would have been lost in a paragraph-style summary but is now visible as an explicit decision point.

What I changed before sending. About 5% — I added a line saying I'd talk to my team lead before making the accept/escalate decision, and a target date for that conversation. The structure was the Gem's.

Where This Works and Where It Doesn't

After about 18 months of use, here's an honest assessment.

It works well for:

  • Internal team meetings with consistent attendees and recurring topics.
  • External calls with vendors or clients where there's a clear decision/action structure.
  • One-on-ones where the same person uses the same format repeatedly.
  • Quick follow-ups — converting 30 minutes of messy notes into a 60-second summary.

It doesn't work well for:

  • Highly sensitive meetings where the political dynamics matter as much as the decisions. The Gem captures what was said; it doesn't capture what was meant.
  • Brainstorming sessions where the value is in the discussion, not the decisions. Summarizing these into decisions strips the useful content.
  • Meetings with multiple parallel conversations where the notes can't capture the structure anyway. The output is only as good as the input notes.
  • Meetings you didn't take notes for. The Gem can summarize from text input but can't reconstruct a meeting you didn't capture.

How to Use This

The workflow:

  1. During the meeting, type raw notes as you would anyway — names, decisions, action items, questions, anything you want to remember.
  2. After the meeting (within an hour if possible), paste the raw notes into the Gem.
  3. Review the output for accuracy. The Gem can miss nuance in your shorthand or misread intent — verify action items against what actually happened.
  4. Send the summary to the meeting participants the same day.
  5. For recurring meetings, archive the summaries in a shared location so people can find them later.

The most common mistake is treating the Gem's output as a complete record of the meeting. It's a structured summary of what you captured. If your notes were thin, the summary will be thin. The Gem doesn't make up for incomplete notes — it makes the most of whatever you give it.

A Note on What This Replaces

The Gem doesn't replace the discipline of taking notes during meetings. It doesn't replace the judgment about what's worth capturing. And it doesn't replace the social work of actually following up on commitments — the summary makes them visible, but someone has to do them.

What it replaces is the post-meeting writing work. For me, that's typically 15–20 minutes per meeting of restructuring raw notes into something I can send. For back-to-back meeting days (which I try to avoid but sometimes can't), the time savings compound quickly. The same-day follow-up has become standard for my team in a way it wasn't before.

Related Reading

Sources

— Justin

📅 First published: 2026-05-05 | 🔄 Last updated: 2026-06-21