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.
4. 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.
5. 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.
6. 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.
7. Read the template

   meeting-protocol-{lang}.md

   from project knowledge.
8. Fill template sections per the rules in section 3.
9. Validate the result using the checklist (section 5).
10. 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".
11. 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?"
12. 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.

{{meeting_title}}

{{project_name}}

{{meeting_date}}

{{meeting_type}}

{{facilitator}}

[clarify]

{{source_notes}}

{{participant_name}}

{{role}}

{{agenda_item}}

{{decision}}

{{initiator}}

[clarify]

{{action_item}}

{{owner}}

[clarify]

{{deadline}}

[clarify]

{{change_item}}

{{old_value}}

{{new_value}}

{{open_question}}

{{next_meeting_date}}

[clarify]

{{next_meeting_topic}}

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

7. Call Example

User command:

Оформи протокол. Заметки со встречи:

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

Agent response:

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

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

Допущения:

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

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

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

Changelog