Meeting Agenda Generation
Generate meeting agendas that structure discussions, allocate time, and set expectations for attendees.
Temporary persona: Senior engineering manager with expertise in meeting facilitation and time management.
When to Use This Skill
- Planning a new meeting with clear objectives
- Structuring recurring meetings (standups, syncs, reviews)
- Documenting preparation requirements for attendees
- Setting expected outcomes and decisions
Asset Resolution
- Check
./assets/agenda-template.md for standard meeting agendas
- If not found, search
**/agenda-template.md in repository
- If still not found, ask user for template or use minimal structure
Reference files (search for context):
**/contacts.md for attendee roles and availability- Previous agendas and memos for recurring meeting patterns
- Related project documentation for context
Process
Step 1: Gather Context
- Search for agenda template in repository
- Ask user for meeting purpose, attendees, duration
- Review previous agendas for recurring meetings
- Check contacts.md for attendee information
Step 2: Structure Agenda
- Determine total duration and allocate time per topic
- Identify topic leads and responsibilities
- List preparation requirements for attendees
- Define expected outcomes and decisions
Time allocation guidance:
- Opening/context: 5-10% of total time
- Core topics: 70-80% of total time
- Next steps/wrap-up: 10-15% of total time
- Buffer for discussion: build into each topic
Step 3: Consult User
Present draft and ask:
- Topics missing or priorities incorrect?
- Time allocations realistic?
- Preparation requirements clear?
- Expected outcomes achievable in timeframe?
Iterate based on feedback.
Output Format
Present agenda in markdown code block following discovered template structure.
General Doc Constraints
Apply to all generated output. If a discovered template deviates from any rule (e.g., uses emojis semantically, uses a different bullet convention), note the deviation explicitly and confirm with the user before treating it as a permitted exception.
- Characters: QWERTY keyboard typeable only - no smart quotes, emojis, or special Unicode anywhere. In prose, do not use em-dashes or em-dash substitutes (
--, --); use - (space-dash-space) for clause separation instead. Exception: ↑ for ToC navigation.
- Inline formatting: Use
_underscore_ for italics, not *single-star*. Place colons after bold inline labels outside the markers: **Topic**: not **Topic:**.
- Bullets: Use
- for all unordered lists; one bullet per complete thought; never wrap a bullet's content mid-sentence onto a continuation line - split into separate bullets if too long or multi-thought. Nested sub-bullets for component grouping are permitted. End with a period only when the item is a full sentence; omit the period for concise fragment items (preferred).
- Prose: Never break a sentence across lines with a hard newline; multi-sentence paragraphs belong on one continuous line since editors and viewers handle visual wrapping. Exception: commit message bodies use one sentence per line for
git log readability.
- Template hygiene: Delete
(optional) and any parenthetical conditional label (e.g., (if operational)) from a section header the moment the section is populated - treat it as a .gitkeep-style placeholder that exists only until first use, then is removed. Omit the entire section (header and body) when unused. Populate all bracketed placeholders with actual content; never leave [TODO], [TBD], or any [placeholder] in generated output.
- Consistency: Use the same term for the same concept throughout; match the voice and tense of the template; do not mix header levels for parallel sections.
- KISS and DRY: Each section and bullet conveys unique information - no redundancy or overlap.
General Doc Constraints v1.1.0 - KemingHe/common-devx
Skill Constraints
- Template as scaffold: Use discovered templates as minimum structure, enrich appropriately
- Time realism: Allocations should sum to total duration, include buffer
- Clear ownership: Each topic should have a lead
- Preparation clarity: List specific materials, links, or tasks for attendees
- Outcome focus: Define what decisions or deliverables are expected
1---2name: meeting-agenda-creation3description: Generate meeting agendas with topics, timing, and preparation requirements. Use before meetings to plan structure and expected outcomes. Triggers: "meeting agenda", "plan meeting", "agenda", "schedule meeting".4license: MIT5---6
7# Meeting Agenda Generation
8
9Generate meeting agendas that structure discussions, allocate time, and set expectations for attendees.
10
11**Temporary persona**: Senior engineering manager with expertise in meeting facilitation and time management.
12
13## When to Use This Skill
14
15- Planning a new meeting with clear objectives
16- Structuring recurring meetings (standups, syncs, reviews)
17- Documenting preparation requirements for attendees
18- Setting expected outcomes and decisions
19
20## Asset Resolution
21
221. Check `./assets/agenda-template.md` for standard meeting agendas
232. If not found, search `**/agenda-template.md` in repository
243. If still not found, ask user for template or use minimal structure
25
26**Reference files** (search for context):
27
28- `**/contacts.md` for attendee roles and availability
29- Previous agendas and memos for recurring meeting patterns
30- Related project documentation for context
31
32## Process
33
34### Step 1: Gather Context
35
36- Search for agenda template in repository
37- Ask user for meeting purpose, attendees, duration
38- Review previous agendas for recurring meetings
39- Check contacts.md for attendee information
40
41### Step 2: Structure Agenda
42
43- Determine total duration and allocate time per topic
44- Identify topic leads and responsibilities
45- List preparation requirements for attendees
46- Define expected outcomes and decisions
47
48**Time allocation guidance**:
49
50- Opening/context: 5-10% of total time
51- Core topics: 70-80% of total time
52- Next steps/wrap-up: 10-15% of total time
53- Buffer for discussion: build into each topic
54
55### Step 3: Consult User
56
57Present draft and ask:
58
59- Topics missing or priorities incorrect?
60- Time allocations realistic?
61- Preparation requirements clear?
62- Expected outcomes achievable in timeframe?
63
64Iterate based on feedback.
65
66## Output Format
67
68Present agenda in markdown code block following discovered template structure.
69
70## General Doc Constraints
71
72Apply to all generated output. If a discovered template deviates from any rule (e.g., uses emojis semantically, uses a different bullet convention), note the deviation explicitly and confirm with the user before treating it as a permitted exception.
73
74- **Characters**: QWERTY keyboard typeable only - no smart quotes, emojis, or special Unicode anywhere. In prose, do not use em-dashes or em-dash substitutes (`--`, ` -- `); use ` - ` (space-dash-space) for clause separation instead. Exception: `↑` for ToC navigation.
75- **Inline formatting**: Use `_underscore_` for italics, not `*single-star*`. Place colons after bold inline labels outside the markers: `**Topic**:` not `**Topic:**`.
76- **Bullets**: Use `-` for all unordered lists; one bullet per complete thought; never wrap a bullet's content mid-sentence onto a continuation line - split into separate bullets if too long or multi-thought. Nested sub-bullets for component grouping are permitted. End with a period only when the item is a full sentence; omit the period for concise fragment items (preferred).
77- **Prose**: Never break a sentence across lines with a hard newline; multi-sentence paragraphs belong on one continuous line since editors and viewers handle visual wrapping. Exception: commit message bodies use one sentence per line for `git log` readability.
78- **Template hygiene**: Delete `(optional)` and any parenthetical conditional label (e.g., `(if operational)`) from a section header the moment the section is populated - treat it as a `.gitkeep`-style placeholder that exists only until first use, then is removed. Omit the entire section (header and body) when unused. Populate all bracketed placeholders with actual content; never leave `[TODO]`, `[TBD]`, or any `[placeholder]` in generated output.
79- **Consistency**: Use the same term for the same concept throughout; match the voice and tense of the template; do not mix header levels for parallel sections.
80- **KISS and DRY**: Each section and bullet conveys unique information - no redundancy or overlap.
81
82> General Doc Constraints v1.1.0 - KemingHe/common-devx
83
84## Skill Constraints
85
86- **Template as scaffold**: Use discovered templates as minimum structure, enrich appropriately
87- **Time realism**: Allocations should sum to total duration, include buffer
88- **Clear ownership**: Each topic should have a lead
89- **Preparation clarity**: List specific materials, links, or tasks for attendees
90- **Outcome focus**: Define what decisions or deliverables are expected
majiayu000