meeting-agenda-creation
Skill10 starsChanged 6 months agoMITView on GitHub
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".
In this repository12 other files it gives its agents.
- commit-message-creationSkill
- contacts-managementSkill
- documentation-reviewSkill
- dot-gitlab-syncSkill
- issue-creationSkill
- living-design-documentsSkill
- meeting-memo-creationSkill
- next-session-handoffSkill
- pull-merge-request-creationSkill
- readme-creationSkill
- senior-mentorSkill
- skill-creationSkill
The file
We split this skill into the rules it gives an agent
10 rules. About 0 are common, 7 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 28
Check ./assets/agenda-template.md for standard meeting agendas
- Very specific: line 29
If not found, search /agenda-template.md in repository
- Distinctive: line 30
If still not found, ask user for template or use minimal structure
- Distinctive: line 42
Search for agenda template in repository
- Distinctive: line 43
Ask user for meeting purpose, attendees, duration
- Distinctive: line 45
Check contacts.md for attendee information
- Very specific: line 81
Inline formatting: Use _underscore_ for italics, not *single-star*.
- Distinctive: line 83
Prose: Do not insert hard newlines to simulate visual wrapping.
- Distinctive: line 85
Consistency: Use the same term for the same concept throughout.
- Distinctive: line 92
Template as scaffold: Use discovered templates as minimum structure, enrich appropriately
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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.mdfor standard meeting agendas - If not found, search
**/agenda-template.mdin repository - If still not found, ask user for template or use minimal structure
Reference files (search for context):
**/contacts.mdfor 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. Exceptions:↑for ToC navigation; Unicode box drawing characters fortree-style directory rendering. - 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: Do not insert hard newlines to simulate visual wrapping. Keep each prose paragraph on one continuous physical line and let editors or viewers wrap it visually. Exception: commit message bodies use one sentence per line for
git logreadability. - 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.2.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
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

