TL;DR: These 20 prompts cover what a text-based AI assistant can actually do around a meeting: decide if it needs to happen, turn a topic list into a decision-shaped agenda, draft the pre-read that shortens the room, script the facilitation, and turn your own notes into decisions and a follow-up. None of them join, record, or transcribe a call.
Can an AI Assistant Actually Join or Record This Meeting?
No, not through anything below. Every prompt on this page works on text you give it: a rough topic list, a pre-read you're drafting, or notes someone in the room typed. If what you actually want is a tool that listens to a live call and hands you a transcript, that's a different category of product, and this page won't pretend otherwise.
Everything from here on assumes you're working from typed notes, an agenda being built from scratch, or a summary someone already wrote, not an audio recording.
Should This Even Be a Meeting?
The cheapest fix for a bad meeting is not holding it. Before building an agenda, it's worth running the topic through a quick, honest test.
1. The should-this-be-a-meeting test
Role: someone deciding whether a topic needs a live meeting or can be resolved asynchronously.
Task: given the topic and goal below, state whether this needs real-time discussion or could
be resolved with a written update, a doc comment thread, or a single decision-maker's call.
Topic: [WHAT THIS IS ABOUT]
Goal: [WHAT DECISION OR OUTCOME IS NEEDED]
People who'd normally be invited: [LIST]
Format: one paragraph verdict, then a one-line reason.
Constraints: default to no meeting needed unless the topic genuinely requires real-time
back-and-forth between multiple people whose input changes the outcome.
What to change: be honest about the goal field. A vague goal along the lines of wanting alignment on the project almost always resolves to not needing a meeting once you're forced to state what decision needs making. A sharper goal, like picking between two named options before a specific date, is a better test of whether it's genuinely a meeting.
How Do You Build an Agenda From the Decision You Need, Not the Topics You Want to Cover?
An agenda built by listing topics produces a meeting that discusses everything and decides nothing. Working backward from the decision fixes that: state what has to be true when the meeting ends, then build only the agenda items that get you there.
2. Turn a topic list into a decision-shaped agenda
Role: someone preparing an agenda for a meeting that needs to end with a decision.
Task: given the rough topic list and the decision needed below, produce an agenda with each
item phrased as a question the meeting must answer, ordered to reach the decision fastest.
Rough topics: [LIST]
Decision needed by end of meeting: [DECISION]
Meeting length: [MINUTES]
Format: numbered agenda, each item as a question, with a suggested minute allocation per item
that sums to the meeting length.
Constraints: drop any topic from the rough list that doesn't serve the stated decision, and
note it as parked rather than silently deleting it.
What to change: state the actual decision, not a restated topic. Discussing the Q3 roadmap is a topic; deciding which two of five features ship in Q3 is a decision. The prompt can only build a decision-shaped agenda if you feed it one.
3. Recurring status-meeting agenda template
Role: someone who runs the same weekly or biweekly status meeting and is tired of rebuilding
the agenda from scratch.
Task: produce a reusable agenda template with placeholders for what changes week to week.
Meeting purpose: [WHAT THIS MEETING IS FOR]
Recurring sections every week: [E.G., BLOCKERS, METRICS REVIEW, DECISIONS NEEDED]
Format: a template with [VARIABLE] placeholders for the sections that change, and fixed
wording for the sections that don't.
What to change: save the output as a template with variables rather than regenerating it every week. Most of a recurring meeting's agenda is stable; only a few fields, like this week's blockers or this week's number, actually change. Our guide to setting up variables worth reusing covers what's worth storing this way versus what should stay a fresh input each time.
4. Time-boxed agenda with an explicit stop condition
Role: someone preparing an agenda for a meeting capped at a hard time limit.
Task: allocate the time budget across the items below and state what happens if the group
hasn't reached the decision by the time limit.
Items and decision needed: [LIST]
Hard time limit: [MINUTES]
Format: agenda with per-item minutes, plus one line stating the fallback if time runs out.
Constraints: the fallback must name a specific next step, not just continuing the discussion
at another time.
What to change: decide the fallback before the meeting starts, not during it. A fallback invented in the room under time pressure is usually just scheduling another meeting, which defeats the point of time-boxing in the first place.
What Should a Pre-Read Include So the Meeting Is Actually Shorter?
A pre-read only shortens the meeting if it does the reading that would otherwise happen out loud in the room: background, the options already considered, and the specific question left open. A pre-read that just restates the agenda doesn't save anyone anything.
5. Draft a pre-read from your own rough context
Role: someone preparing a pre-read document ahead of a meeting.
Task: turn the rough context below into a pre-read that front-loads background so the meeting
can start at the open question instead of re-explaining the situation.
Rough context: [PASTE YOUR NOTES, BACKGROUND, RELEVANT DATA]
Open question the meeting needs to resolve: [QUESTION]
Format: background in 2-3 short paragraphs, options already considered as a bulleted list with
why each was or wasn't chosen, then the specific open question, in that order.
Constraints: use only the context given. If the rough notes don't state why an option was
rejected, leave that as [WHY REJECTED] rather than inventing a reason.
What to change: actually send it and ask people to read it before the meeting. A pre-read that goes unread just adds a step. State plainly in the invite that the meeting will start from the open question, not from a recap of the pre-read.
6. One-pager for a decision meeting
Role: someone preparing a one-page pre-read for a meeting whose sole purpose is making one
decision.
Task: produce a single page covering the decision, the options, the recommendation (if any),
and what happens if no decision is reached.
Decision: [DECISION]
Options: [LIST]
Your recommendation, if any: [RECOMMENDATION OR "none yet"]
Format: one page. Decision stated as a question at the top, options as a short table, your
recommendation stated plainly or marked as not yet decided.
What to change: if you genuinely have no recommendation, say so instead of forcing one. A recommendation invented just to look decisive wastes the group's time relitigating a position nobody actually holds.
How Do You Script a Meeting You're Nervous About Running?
The nerves are usually about the moment the room goes quiet or someone derails the discussion, not about the topic itself. A short script for the opening, the redirect, and the close removes most of that.
7. Facilitator's opening script
Role: someone facilitating a meeting who wants a scripted opening rather than improvising.
Task: write a 30-45 second opening that states the goal, the decision needed, and one ground
rule for how the discussion will run.
Meeting goal: [GOAL]
Decision needed: [DECISION]
Ground rule: [E.G., ONE PERSON TALKS AT A TIME, OR TANGENTS GET PARKED FOR THE LAST 5 MINUTES]
Format: spoken-word script, short sentences meant to be said out loud, not written prose.
What to change: practice saying it once before the meeting. A script that reads fine on the page can still feel stiff out loud if the sentences run long. Cut anything you wouldn't naturally say to a colleague.
8. Redirect script for a discussion that's drifted
Role: a facilitator who needs to bring a drifted discussion back to the agenda without
shutting anyone down.
Task: write 2-3 short phrases that acknowledge what's being discussed, name that it's off the
current agenda item, and offer to park it.
Current agenda item: [ITEM]
What the discussion has drifted to: [TANGENT]
Format: 2-3 short spoken phrases, not a paragraph.
What to change: use the actual tangent topic rather than a generic redirect. Naming it specifically and offering to come back to it after the current item is decided reads as acknowledging the person, not silencing them.
9. Pressure-test a decision before it's finalized
Role: someone pressure-testing a decision the group is about to finalize, before it's locked
in.
Task: given the decision and reasoning below, list the strongest reasonable objections a
thoughtful skeptic would raise, and what would have to be true for each objection to matter.
Decision about to be made: [DECISION]
Reasoning so far: [REASONING]
Format: numbered objections, each with the condition that would make it a real problem.
Constraints: raise only objections grounded in the reasoning given or genuinely obvious gaps
in it. Do not manufacture a concern that doesn't connect to the actual decision.
What to change: run this before the meeting ends, not after, while there's still time to address a real objection instead of discovering it once everyone's left the room.
10. Round-robin check-in for remote or hybrid meetings
Role: a facilitator running a remote or hybrid meeting where quieter voices tend to get
talked over.
Task: write a short round-robin prompt that asks each named person one specific question
related to the topic, not a generic request for thoughts.
Topic: [TOPIC]
People and their relevant angle: [NAME - WHY THEIR INPUT MATTERS HERE]
Format: one specific question per named person.
What to change: tailor each question to why that person is actually in the room. A generic request for thoughts gets a shrug; a specific question tied to what changes for them gets an answer.
How Do You Turn Messy Notes Into Decisions and Owners?
Raw meeting notes are usually a mix of what was said, what was decided, and what just got mentioned in passing. Pulling those apart is the genuinely useful step, and it's one a general-purpose assistant does well when you ask for it explicitly instead of a generic request to summarize.
11. Separate decisions from discussion in raw notes
Role: someone turning raw meeting notes into a clean record of what was actually decided.
Task: read the notes below and separate them into three lists: decisions made, action items
with an owner, and open questions still unresolved.
Raw notes: [PASTE YOUR NOTES]
Format: three headed lists. Under each action item, name the owner only if the notes state
one; otherwise write [NO OWNER NAMED - ASSIGN ONE].
Constraints: do not infer an owner from context or seniority. If the notes don't name who's
doing something, flag it rather than guessing.
What to change: this is the single most important constraint on this page. An assistant asked to extract action items will happily invent a plausible-sounding owner if the notes are ambiguous, and a wrong name on an action item is worse than no name at all: it tells the wrong person nothing is expected of them while the room believes it's covered.
12. Extract action items with due dates from vague language
Role: someone converting vague commitments from meeting notes into trackable action items.
Task: find every commitment in the notes below, however loosely stated, and convert it into
an action item with an owner and a date.
Raw notes: [PASTE YOUR NOTES]
Format: table with columns Action, Owner, Due date.
Constraints: if the notes don't state a date, write [NO DATE SET] rather than assuming one.
If the notes don't name who volunteered, write [UNCLEAR - CONFIRM OWNER].
What to change: send the output back to the room for confirmation before treating it as final, especially the unclear rows. Those are exactly the commitments vague enough that people forget they made them.
13. Executive summary for a stakeholder who wasn't in the room
Role: someone writing a meeting summary for a stakeholder who wasn't present and doesn't need
the discussion, only the outcome.
Task: write a summary covering what was decided and what it means for this stakeholder
specifically, with none of the discussion that led there.
Raw notes: [PASTE YOUR NOTES]
Who this is for and what they care about: [STAKEHOLDER, THEIR CONCERN]
Format: 3-4 sentences. Decision first, then the specific implication for this reader.
Constraints: exclude discussion, dead ends, and disagreement that was resolved. Include only
what was decided and why it matters to this specific reader.
What to change: write a genuinely different version per audience rather than one generic summary. What a VP of Sales needs from a product meeting and what an engineer needs from the same meeting barely overlap. Our stakeholder-update templates go deeper if you're doing this every release cycle rather than once.
14. One-paragraph announcement for a wider team channel
Role: someone announcing a decision from a meeting to a wider team channel who weren't there
and don't need meeting-by-meeting detail.
Task: write a single paragraph stating what was decided, who it affects, and what changes for
them starting when.
Raw notes: [PASTE YOUR NOTES]
Who this affects and how: [TEAM, WHAT CHANGES]
Format: one paragraph, 3-5 sentences, no meeting recap, no attendee list.
What to change: cut anything that reads as a recap of the discussion. A wider-channel announcement should read as a decision that happened, not a meeting that happened.
If a decision from a meeting needs to become a formal product requirement, our meeting-notes-to-spec workflow for product managers goes a level deeper than this page does, with a four-step pipeline from raw notes to a reviewable spec section.
How Do You Write the Follow-Up Nobody Wants to Write?
The follow-up is the step that most often just doesn't happen, not because it's hard, but because writing it from scratch after a meeting that already ran long feels like a chore. Structuring it well makes it fast enough to actually send the same day.
15. The what-we-decided follow-up email
Role: someone writing the follow-up email after a meeting, to be sent the same day.
Task: write a follow-up covering the decision, the action items with owners and dates, and
the next checkpoint.
Raw notes or decision/action list: [PASTE]
Format: short intro line, bulleted decisions, bulleted action items (Owner - Action - Due),
one line on when this group reconvenes or checks in next.
Constraints: use only owners and dates that were actually stated or confirmed. Mark anything
unconfirmed rather than smoothing over the gap.
What to change: send it the same day. A follow-up written two days later has already lost the moment where everyone remembers agreeing to something. Same-day is what actually makes people follow through.
16. Follow-up for a meeting that ended without a clear decision
Role: someone writing a follow-up for a meeting that ran out of time without reaching the
decision it was meant to reach.
Task: write a follow-up that states this plainly, summarizes the two or three positions in
the room, and proposes a specific next step to actually reach a decision.
What was discussed and where it stalled: [SUMMARY]
Format: 3-4 sentences, honest about the outcome, ending with a concrete proposed next step:
a named decision-maker, a smaller follow-up meeting, or an async vote by a date.
What to change: resist the urge to write this as if a decision was reached when it wasn't. A follow-up that papers over an inconclusive meeting just moves the confusion to whoever reads it and assumes it's settled.
17. Client-facing weekly status follow-up
Role: someone writing a client-facing status update after an internal or client meeting.
Task: write a status update covering progress since the last update, what's decided or
changed, and what's needed from the client next, if anything.
Raw notes: [PASTE]
What's needed from the client, if anything: [ASK, OR "nothing needed"]
Format: three short sections: progress, decisions or changes, what we need from you. Each
1-2 sentences.
Constraints: state plainly that nothing is needed this week if that's the case, rather than
omitting the section, so the client isn't left guessing whether there's an ask buried in it.
What to change: if you send this weekly, save it as a template with variables rather than rebuilding the structure each time. Our free client update generator is built specifically around that recurring weekly cadence, including the week nothing shipped.
How Do You Prep a Recurring Meeting Without Rebuilding the Agenda Every Time?
Different recurring meeting types need different prep, and confusing them is a common way a meeting runs long for no reason.
| Meeting type | What it should decide | What actually shortens it |
|---|---|---|
| Weekly status | What's blocked and what needs a decision this week | A pre-read with last week's numbers already filled in |
| Standup | Nothing; it's a sync, not a decision meeting | Keeping it strictly to blockers, moving decisions elsewhere |
| Brainstorm | Which two or three ideas move to the next stage | A round-robin script so one voice doesn't dominate |
| Retro | What changes next sprint, specifically | A structured worked/didn't-work prompt, not an open floor |
| Decision meeting | The single decision named in the agenda | A one-pager pre-read with options and a recommendation |
18. Retro prompt: what worked, what didn't, what changes
Role: someone facilitating a retrospective who wants structured input instead of an open
floor discussion.
Task: given the raw input below, organize it into what worked and what didn't, then propose
one specific, ownable change to try next sprint, not a vague intention.
Raw input from the team: [PASTE NOTES, SURVEY RESPONSES, OR CHAT LOG]
Format: three headed lists (worked, didn't, proposed change), the proposed change stated as
a specific action with an owner.
Constraints: the proposed change must be something a specific person can actually do
differently next sprint, not a general call to communicate better.
What to change: push back on vague inputs before you run this. A complaint that communication was bad isn't actionable on its own; ask the team what specifically didn't get communicated before the retro, not during it.
19. Post-mortem for a meeting that didn't work
Role: someone doing a quick post-mortem on a meeting that ran long, went off-topic, or ended
without the intended outcome.
Task: given what happened below, identify the specific point where the meeting went off
track and one concrete change for next time.
What happened: [BRIEF ACCOUNT OF HOW THE MEETING WENT]
Intended outcome: [WHAT IT WAS SUPPOSED TO ACHIEVE]
Format: 2-3 sentences: where it went off track, and one specific structural change (not a
general instruction to run it better) to prevent the same failure next time.
What to change: do this the same day, while you remember the actual moment things drifted, not a week later when it's flattened into a vague sense that the meeting wasn't worth holding.
20. Reusable recurring-meeting agenda with variables
Role: someone standardizing the agenda for a meeting that happens every week or sprint.
Task: produce an agenda template with [VARIABLE] placeholders for whatever changes each
occurrence, and fixed structure for whatever doesn't.
Meeting purpose: [PURPOSE]
Sections that repeat every time: [LIST]
Sections that change every time: [LIST]
Format: numbered template. Fixed sections written out in full, changing sections as
[VARIABLE] placeholders with a one-line description of what goes there.
What to change: store this as a saved template rather than a one-off output. A recurring meeting is, by definition, a prompt you'll run again next week, and rebuilding it from scratch each time is exactly the kind of repeated work a personal prompt library is for.
Does the Free Plan Cover This?
Yes, for occasional use. The Free plan includes 5 prompt enhancements a day, forever, no card required, per the FAQ page, which is enough to draft an agenda or a follow-up on a normal day. What Free doesn't include: Refine and Shorten modes for polishing a draft further, saving these as reusable templates, or the personal context library for storing your standard meeting-purpose and stakeholder details once instead of retyping them into every prompt. Those are Pro-plan features, priced at the time of writing on /pricing; check the current figure there, since it changes.
If you're gathering structured input in writing instead of running a live discussion, a survey is often the better tool. See our companion guide on designing surveys that don't quietly bias their own answers.
Stop rewriting prompts. Start shipping.
Works with ChatGPT, Claude, Gemini, Grok, Midjourney, Ideogram, Veo3 & Kling. 4.8★ on the Chrome Web Store.
Create An Account