generate-meeting-protocol

Triggers

Russian: «оформи протокол», «протокол встречи», «обработай заметки со встречи» English: "generate meeting protocol", "meeting notes", "meeting minutes"

Language Detection

Determine the language of the user's request:

• If the request is in Russian → use templates with -ru suffix
• Otherwise → use templates with -en suffix

All output (headings, labels, comments, instructions) must match the detected language.

1. Input Data

If required data is missing — request it (system-prompt-draft.md §3 p.2):

To generate a protocol, meeting notes are required — in any format:
bullet points, free text, chat copy, voice dictation (as text).
Minimum to start: what was discussed and what decisions/tasks were recorded.
Available data: [list what is available].
Missing: [specify].

2. Execution Algorithm

1. Validate input data. Check if notes are present. If not → request using the template from §1. Do NOT generate a placeholder protocol — respond ONLY with the data request.
2. Extract meeting metadata. From notes or context: date, participants, topic, meeting type, facilitator. What cannot be extracted — ask the user specifically. Minimum to proceed: meeting date.
3. Structure the content. Extract from notes and categorize:

• Agenda — topics that were discussed.
• Decisions — recorded decisions (IDs: D001, D002, ...).
• Action items — actions with owners and deadlines (IDs: A001, A002, ...).
• Plan changes — if notes imply changes to timelines, scope, or resources.
• Open issues — unresolved questions requiring further discussion.

1. Verify action item completeness. Each action item (A00x) must include: description, owner, deadline. If deadline/owner is missing from the notes — mark as [clarify] and record in assumptions.
2. Determine plan changes (section 5). Rules:

• If project plan is available in knowledge → find affected elements, specify IDs (WP-xxx, Mx). Columns: "Was" (from plan) → "Becomes" (from notes) → "Basis" (decision ID D00x).
• If project plan is NOT available → describe changes as text without IDs. Record assumption: "Project plan not provided — element IDs not specified."
• If no plan changes → delete section 5.

1. Determine conditional sections (5, 6, 7). Delete a section if no data is available for it:

• Section 5 "Plan Changes" — delete if notes contain no plan-level changes.
• Section 6 "Open Issues" — delete if all issues are resolved.
• Section 7 "Next Meeting" — delete if date/topic were not discussed.

1. Read the template meeting-protocol-{lang}.md from project knowledge.
2. Fill template sections per the rules in section 3.
3. Validate the result using the checklist (section 5).
4. Show the result in chat. Format (system-prompt-draft.md §3 p.4):

• What was done: "Protocol generated for meeting [date] based on: [notes source]."
• Key outcomes: N decisions, M action items, K plan changes (or "no changes").
• Assumptions: list all.
• [clarify] markers: list if any.
• Next step: "Approve, provide feedback, or reject."
• Do not include system paths. Use filename only: "Protocol: meeting-protocol-YYYY-MM-DD.md".

1. Wait for user response (system-prompt-draft.md §3 p.5).

• Approval → produce final text.
• Feedback → revise, show updated version. After 3rd iteration — ask: "Continue revising or finalize current version?"

1. After approval:

• Propose text for insertion into log.md and project-state.md (system-prompt-draft.md §11).
• If section 5 contains changes — recommend: "The protocol includes project plan changes. Consider updating project-plan.md."

3. Section-Filling Rules

Header Metadata

• meeting_title: meeting topic — extract from notes or ask.
• project_name: from session context.
• meeting_date: YYYY-MM-DD.
• File: meeting-protocol-YYYY-MM-DD.md (substitute meeting date).
• Document status: draft (at generation). After approval — approved.
• meeting_type: meeting type (see type reference below). If not specified — infer from note content, record as assumption.
• facilitator: from notes. If not specified — [clarify].
• Scribe: AI agent (always).
• source_notes: where the notes came from (e.g. "PM notes", "Slack copy", "voice dictation").

Meeting type reference (guidance):

The reference is a guide, not a constraint. Sections are determined by note content, not meeting type.

Section 1. Participants

• Extract from notes: names, roles.
• Attendance: default "yes" if mentioned in notes. If absence is noted — "no".
• If participant list is not in the notes — ask the user.

Section 2. Agenda

• Extract discussed topics from notes.
• Statuses: discussed (has a decision/conclusion), deferred (not discussed, postponed), dropped (closed/no longer relevant).
• Sequential numbering: 1, 2, 3...

Section 3. Key Decisions

• IDs: D001, D002, ... — sequential numbering.
• Decision: exact formulation — what was decided. Specific, no vague language.
• Initiator: who proposed/championed the decision (from notes). If unknown — [clarify].
• Status: accepted (final) or deferred (needs more information/discussion).

Section 4. Action Items

• IDs: A001, A002, ... — sequential numbering.
• Each action item: a specific action (not a process).
• Owner: from notes. If not specified — [clarify].
• Deadline: specific date (YYYY-MM-DD) or relative deadline. If not specified — [clarify].
• Priority: H (high) / M (medium) / L (low). Determined by context: proximity to next milestone, criticality, urgency mentions. If cannot be determined — M (assumption).

Section 5. Project Plan Changes (conditional)

• Delete the section if notes contain no changes to timelines, scope, resources, or project milestones.
• If project plan is available: in the "What changed" column, specify the plan element ID: WP-xxx (work package) or Mx (milestone). "Was" — value from plan. "Becomes" — from notes. "Basis" — decision ID (D00x) that triggered the change.
• If plan is NOT available: describe the change as text (without IDs). Assumption: "Plan element IDs not specified — project plan not provided."

Section 6. Open Issues (conditional)

• Delete the section if all agenda items are resolved and there are no deferred topics.
• Format: bulleted list. Each item — a specific question requiring a decision or information.

Section 7. Next Meeting (conditional)

• Delete the section if next meeting date/topic were not discussed.
• If only date or only topic was discussed — fill in what is known, mark the other as [clarify].

4. Placeholder Reference

Placeholders {{}} in the template are filling guides, not auto-substitution variables. Replace each one with the corresponding value from the input data.

5. Validation Checklist

Before showing the result to the user — verify:

• [ ] All required placeholders replaced with values
• [ ] No {{}} placeholders remaining in text (except [clarify])
• [ ] Meeting date is present and correct
• [ ] Agenda: ≥1 item, each with a status
• [ ] Decisions (if any): IDs sequential (D001, D002, ...), formulations specific
• [ ] Action items (if any): IDs sequential (A001, A002, ...), each with owner, deadline, priority (or [clarify])
• [ ] Section 5: deleted if no changes. If present and plan is available — plan element IDs (WP-xxx/Mx) specified. Each change linked to a decision (D00x)
• [ ] Section 6: deleted if no open issues
• [ ] Section 7: deleted if not discussed
• [ ] All agent assumptions and [clarify] markers listed when delivering the result
• [ ] Document status = draft
• [ ] Filename in header = meeting-protocol-YYYY-MM-DD.md

6. Dependencies

Consumes (input):

• Meeting notes — from user (via chat or knowledge)
• project-plan.md — project plan (optional, for ID linking)

Produces (output): meeting protocol → consumed by (system-prompt-draft.md §7):

• generate-project-plan — if section 5 contains changes, the plan needs updating
• Does not block other skills. Independent artifact.

Note: this skill is not part of a fixed chain. It can be invoked in any project phase when meeting notes are available.

After approval, the user needs to upload meeting-protocol-{date}.md to project knowledge (if required by other tasks).

7. Call Example

User command:

Оформи протокол. Заметки со встречи: - были Алексей, Елена, я - обсудили результаты прототипа — решили идти с вариантом B - Елена подготовит финальный дизайн до 15 апреля - сроки MVP сдвигаются на 2 недели из-за доработок - следующая встреча — 10 апреля, обсуждение плана

Agent response:

Сформирован протокол встречи 2026-04-03 на основе: заметки PM (чат).

>

Итоги: 1 решение, 1 задача, 1 изменение в плане.

>

Допущения: - Тип встречи: «Демо/ревью» (определён по содержанию — обсуждение результатов прототипа). - Ведущий: [уточнить] (не указан в заметках). - Приоритет задачи A001: В (привязана к ближайшей вехе MVP). - План проекта не предоставлен — изменения описаны текстом, ID элементов не указаны.

>

Требуется: утвердить, внести замечания или отклонить. Уточнить: ведущий встречи.

>

[текст протокола]

Changelog