organizing-meeting-reports

Organizing meeting reports (整理会议报告)

Overview

When organizing meeting content, by default the executor has almost zero context about the current project and business background. Organize the raw materials provided by the user (meeting transcripts, meeting documents, meeting minutes,*.srt) into a semantic document that can be distributed directly.

By default, first complete the organization based on the meeting materials themselves; only when the materials contain clear signals strongly related to the current workspace (such as repository names, module names, file paths, PR/Issue numbers) should code context be associated. If the above signals are lacking, do not force a code association. The document needs to be complete enough that development members who did not attend the meeting can quickly understand "what happened, what was decided, and who does what next". The output must be clearly chunked, semantically clear, and quickly scannable, avoiding redundancy (DRY), avoiding irrelevant expansion (YAGNI), and retaining only information valuable for execution.

By default, assume the executor has good writing and engineering skills, but is unfamiliar with the current project terminology, personnel division of labor, and context. Therefore, necessary background must be supplemented, and implicit information that "everyone understands" must not be relied upon. Since the text may be transcribed from speech content, some content may be recognized inaccurately. You need to write specific professional names correctly based on your understanding. For anything uncertain or potentially disputed,must be listed one by one for the executor to confirm。

• State at the beginning：我正在使用 organizing-meeting-reports 技能整理会议内容并生成报告。
• Context: It is recommended to execute the organization task in an independent workspace to avoid mutual interference with parallel development tasks.

User input

Before continuing, youmust prioritize handlingthe user input (if not empty).

• If the user explicitly specifies the output target, language, format, or structure, the user's requirements have the highest priority and may override the default template and field order.
• If the user does not provide analyzable meeting materials (text, documents,*.srt or accessible paths), you must first request supplementary materials and must not guess or generate conclusions.
• If the user provides only partial materials, first output "confirmed content + missing information list" based on the existing information, and clearly state the minimum supplementary input required to continue producing output.

When to use

• The user proposes document organization needs based on meeting content, such as "organize project documents".
• The user provides *.srt and other meeting record files and needs content analysis and summarization.
• The user provides meeting transcript text and needs to extract key information.
• The user provides meeting minutes or meeting documents and needs them reorganized into a clearer report.
• The user needs to extract action items, owners, time points, or launch decisions from meeting materials.
• The user needs to correct terminology/person-name recognition errors and form an actionable list of questions to be confirmed.

Workflow

1. Read the meeting materials provided by the executor, combine them with the current code repository and workspace, and understand the meeting content and structure.
2. Merge duplicate information, unify expressions such as person names, module names, and dates, and convert vague expressions into clear expressions.
3. Analyze the meeting content and determine the core topics of the meeting.
4. Confirm with the executor key information such as uncertain professional terminology, personnel assignments, and meeting conclusions to ensure accurate understanding. (If there is no uncertain information, skip this step; if there is uncertain information, the "Confirmation Interruption Protocol" must be executed.)
5. Output the organized results according to the template below; when a "Meeting Sections (Outline)" is needed,you must reusethe section template in the template reference. The template is the default output structure; if the user explicitly requests another delivery format (such as only action items, only conclusions, or only speakers' viewpoints), the output may be trimmed without losing key information.

Confirmation Interruption Protocol (dedicated to Step 4)

• Trigger condition: There is any information that cannot be 100% confirmed (terminology, names, role assignments, attribution of conclusions, etc.).
• Mandatory behavior: Once triggered, routine output must be interrupted immediately, and only the "List of Questions to Be Confirmed" should be output; do not continue generating the main body of the final report.
• Output format: List the questions by number; the questions must be specific and directly answerable; prefer using options (A/B/C) to reduce communication costs.
• Waiting rule: After raising the questions, stop immediately and wait for the executor's reply; before receiving the reply, do not continue outputting the organized results.
• Continuation condition: After receiving the executor's reply, first fill in the confirmation results; if there are still unconfirmed items, continue outputting only the remaining questions until the confirmable information meets the production standard.

## 待确认问题列表（请按编号回复）
1. 术语确认：这里的「XXX」是否指「YYY」？
2. 责任人确认：行动项 A 的负责人是 @甲 还是 @乙？
3. 结论确认：本段讨论最终是否已决定“本期上线”？

收到你的回复后，我会继续输出完整会议整理结果。

Template Reference

• Meeting Sections (Outline):
  • Template:meeting-chapter-outline.md
  • Purpose: Split the meeting content into sections by time period to quickly produce a structured outline.
  • Field specification: Each section must contain at least 标题、时间范围、参与人、概要。
  • Splitting suggestion: Split according to natural turns in the discussion; 3-10 sections are recommended, avoiding being too detailed or too coarse.
  • Content requirements:标题Summarize the core conclusions of that time period;概要2-4 sentences are recommended, covering background, disagreements, conclusions, and impact.
  • Viewpoint requirements: The end must include 发言人观点, summarizing the core viewpoint items by speaker.
  • Note: The template file itself is a complete demonstration example; when actually producing output, please reuse its structure and do not directly copy the example content;

When to Stop and Seek Help

Stop execution immediately in the following situations and ask for clarification instead of guessing:

• The meeting content involves multiple projects or multiple meetings, and it cannot be determined which project the current meeting is related to.
• Unfamiliar terminology, abbreviations, or names appear in the meeting content, and their meanings cannot be inferred from the context.
• The meeting content may be impossible to judge due to ASR errors or transcription errors.
• There is obvious semantic ambiguity, logical contradiction, or missing information in the meeting content, making it impossible to determine the meeting's core topics, participant roles, or meeting conclusions.
• There are multiple possible ways to split the meeting content or multiple possible conclusions, and the most reasonable structured output cannot be determined.

Quality Standards

• If there is unconfirmed key information, the "Confirmation Interruption Protocol" must be executed first, and the final meeting report must not be output directly.
• Questions to be confirmed must be actionable and answerable, avoiding vague questions (for example, "What does this section mean?").
• In the final report after confirmation by the executor, ambiguous expressions of the same question must not remain again.