From pm-skills
Produces attendee-facing meeting agendas for 10 types (standup, planning, review, etc.) with time-boxed topics, owners, prep, logistics, and shareable Slack/email summaries.
npx claudepluginhub product-on-purpose/pm-skillsThis skill uses the workspace's default tool permissions.
<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
Generates a structured 1-page meeting brief with context, objectives, key questions, pre-read, expected decisions, and parking lot from a meeting topic or agenda.
Prepares meeting agendas for Product Managers with goals, prioritized talking points, Q&A anticipation, materials lists, and strategies for true agendas and strong openings.
Generates meeting agendas by gathering context from previous summaries, external services (GitHub, Slack via TECH.md), and custom templates. Suggests generating missing summaries for upcoming meetings.
Share bugs, ideas, or general feedback.
A meeting agenda is the attendee-facing structural document that sets expectations before a meeting. It answers "what will we discuss, who owns each topic, how will we spend the time, and what does done look like?" Distinct from a meeting brief, which is the user's private strategic prep; the agenda is shared with participants and focused on structure and flow.
This skill belongs to the Meeting Skills Family. It conforms to the Meeting Skills Family Contract, which defines shared frontmatter, file naming, the go-mode behavioral pattern, and universal output requirements across all meeting skills.
/meeting-brief instead./meeting-recap for post-meeting summarization./stakeholder-update after the meeting.Per the family contract, this skill never blocks on interrogation. Default flow:
go or correctionsIf invoked with --go, skip the inference summary and produce output directly using defaults (duration 30 min, meeting type other, and so on). If the user provides all values upfront, no checkpoint appears.
Blocking questions are used only when inference confidence is actively low on a load-bearing input and no reasonable default exists. This should be rare.
This skill opens with an explicit question: "Does this need to be a meeting, or could it be handled async?"
v1.1.0: the check now requires a positive synchronous-value statement. The meeting passes the check only when at least one of these is named:
If none apply, the skill recommends the async alternative (written update, doc review, Slack poll) and produces a short one-page "how to handle this async" framing instead of an agenda.
The v1.0.0 version of this check ("single-owner decision with no tradeoffs", "pure information broadcast", "status-only sync with >5 people") was bypassed too easily. users would stay at five attendees or add "decision" to the topic. The stricter v1.1.0 biases toward async; users can still override.
This check is shared with /meeting-brief and not run by the post-meeting skills (recap, synthesize, stakeholder-update).
When asked to create a meeting agenda, follow these steps:
Run anti-meeting check Apply the trigger patterns above. If the user's objective matches, propose the async alternative and ask for override. Only proceed to step 2 on explicit override.
Parse and load inputs
Read the topic or purpose. Load all @file references provided. Extract any attendee list, time constraints, or linked documents.
Infer missing values Apply these inference rules:
| Value | Inferred from | Default |
|---|---|---|
| Meeting type | Topic keywords, attendee seniority mix | other (low confidence) |
| Duration | Explicit in topic doc (rare); meeting-type-specific default when type is inferred at medium+ confidence | v1.1.0: type-specific (see family contract). 30 min only for other, 1-on-1, exec-briefing, customer-call. Kickoff = 60, working-session = 60, decision-making = 45, etc. |
| Objective | Topic phrasing | Infer; surface in summary |
| Attendee RACI | Seniority, topic ownership cues | Flag all inferences |
| Desired outcomes | Objective plus meeting type heuristics | Offer strawman |
Load-bearing inference gates (v1.1.0): when attendee RACI or desired outcomes are inferred below-high confidence, flag in the go-mode summary with ⚠. See family contract "Zero-friction execution" section.
Present go-mode inference summary
Show the inferred values with confidence markers. Accept go to proceed, or corrections to revise. Re-run inference after any correction and present the summary again.
Design the time-boxed topic list Apply the meeting-type variant (see below). Size topic times so their sum equals the meeting duration. If the topic list overflows the available time, flag it explicitly and ask for reconciliation (do not silently trim).
Each topic must have:
Discussion | Decision | Information | WorkingSpecify attendee prep List required prep with links and estimated prep time. Add recommended context for attendees who want deeper background. Add "come ready to" expectations that force clarity on what each attendee contributes.
Add parking lot and logistics placeholders Parking lot is a placeholder for off-topic items raised during the meeting. Logistics covers join link, materials needed, recording ownership.
Render the TEMPLATE.md with filled values Remove all guidance blockquotes from the final artifact.
Validate output
meeting_duration_minutes, desired_outcomes)Generation contextApplied in step 5. Each variant reshapes the topic list to match the meeting's purpose.
Before delivering the agenda, verify:
other with low-confidence flag)/meeting-brief. user's private prep (shares anti-meeting check)/meeting-recap. downstream: recap auto-populates from this agenda's topic list/stakeholder-update. downstream: translates meeting outcomes to non-attendees