meeting-minutes

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Meeting Minutes Skill — Short Internal Meetings

会议纪要Skill — 短时长内部会议

Purpose / Overview

用途/概述

This Skill produces high-quality, consistent meeting minutes for internal meetings that are 60 minutes or shorter. Output is designed to be clear, actionable, and easy to convert into task trackers (e.g., GitHub Issues, Jira). The generated minutes prioritize decisions and action items so teams can move quickly from discussion to execution.

本Skill为时长60分钟及以下的内部会议生成高质量、格式统一的会议纪要。输出内容清晰、可执行，便于转换为任务追踪工具（如GitHub Issues、Jira）。生成的纪要会优先突出决议和行动项，帮助团队快速从讨论过渡到执行阶段。

When to Use

使用场景

Use this skill when:

Internal syncs, standups, design reviews, triage, planning or ad-hoc meetings with short duration
Situations that require a concise record of decisions, assigned action items, and follow-ups
Creating a standardized minutes document from a live meeting, transcript, recording, or notes

在以下场景中使用本Skill：

短时长的内部同步会、站会、设计评审会、问题分类会、规划会或临时会议
需要简洁记录决议、分配的行动项及后续跟进内容的场景
根据实时会议、转录文本、录音或笔记创建标准化纪要文档的场景

Operational Workflow

操作流程

Phase 1: Intake (before drafting)

阶段1：信息收集（起草前）

Obtain meeting metadata: title, date, start/end time (or duration), organizer, and intended audience.
Confirm available inputs: agenda, slides, recording, transcript, or raw notes.
If key details are missing, ask up to 3 clarifying questions before producing minutes (see "Discovery" below).

获取会议元数据：标题、日期、开始/结束时间（或时长）、组织者及目标受众。
确认可用输入材料：议程、幻灯片、录音、转录文本或原始笔记。
如果关键信息缺失，在生成纪要前最多提出3个澄清问题（详见下方“信息确认”部分）。

Phase 2: Capture (during / immediately after meeting)

阶段2：信息记录（会议期间/结束后立即）

Record attendees and absentees.
Capture brief notes per agenda item with time markers if available.
Record explicit decisions, rationale summary (1–2 sentences), and action items (owner + due date).

记录参会人员和缺席人员。
按议程项记录简要笔记，若有可用时间标记则附上。
记录明确的决议、理由摘要（1-2句话）及行动项（负责人+截止日期）。

Phase 3: Drafting

阶段3：起草

Generate minutes following the Strict Minutes Schema (below).
Ensure every action item includes owner, due date (or timeframe), and acceptance criteria when applicable.
Mark unresolved issues or items requiring follow-up in the Parking Lot.

按照严格纪要模板（见下文）生成纪要。
确保每个行动项都包含负责人、截止日期（或时间范围），适用时还需包含验收标准。
将未解决的问题或需要跟进的事项标记在“待办停车场”中。

Phase 4: Review & Publish

阶段4：审核与发布

If possible, send draft to meeting organizer or a designated reviewer for quick verification (within 24 hours).
Publish final minutes to the agreed channel (shared drive, repo, ticket, or email) and optionally create tasks in the team's tracker.

若可行，将草稿发送给会议组织者或指定审核人进行快速验证（24小时内）。
将最终纪要发布至约定渠道（共享驱动器、代码仓库、工单或邮件），并可选择在团队任务追踪工具中创建任务。

Discovery (required clarifying questions)

信息确认（必填澄清问题）

Before generating minutes, the agent MUST ask up to three clarifying questions if any of these are missing:

What is the meeting title, date, start time (or duration), and organizer?
Is there an agenda or transcript/recording to reference? If yes, please provide.
Who should be assigned as the reviewer or approver for the minutes?

If the user responds "no transcript" or "no agenda," proceed but mark source material as "ad-hoc notes" and flag potential gaps.

在生成纪要前，如果以下任何信息缺失，Agent必须最多提出3个澄清问题：

会议标题、日期、开始时间（或时长）及组织者是什么？
是否有可参考的议程或转录文本/录音？若有，请提供。
谁将被指定为纪要的审核人或批准人？

如果用户回复“无转录文本”或“无议程”，可继续生成纪要，但需将源材料标记为“临时笔记”并标注可能存在的信息缺口。

Strict Minutes Schema (Output Structure)

严格纪要模板（输出结构）

You MUST produce meeting minutes following this exact structure. If information is unavailable, use

TBD

Unknown

and explain how to obtain it.

你必须严格按照此结构生成会议纪要。若信息不可用，使用

TBD

或

Unknown

标注，并说明如何获取该信息。

1. Metadata

1. 元数据

Title:
Date (YYYY-MM-DD):
Start Time (UTC):
End Time (UTC) or Duration:
Organizer:
Location / Virtual Link:
Minutes Author (agent or person):
Distribution List (who receives the minutes):

标题:
日期（YYYY-MM-DD）:
开始时间（UTC）:
结束时间（UTC）或时长:
组织者:
地点/虚拟链接:
纪要作者（Agent或人员）:
分发列表（接收纪要的人员）:

2. Attendance

2. 参会情况

Present: [list of names + roles]
Regrets / Absent: [list]
Notetaker / Recorder: [name or "agent"]

出席: [姓名+角色列表]
缺席/请假: [列表]
记录员: [姓名或“Agent”]

3. Agenda

3. 议程

Bullet list of agenda items, in order:

Item 1: short title
Item 2: short title
...

按顺序列出议程项的项目符号列表：

项1：简短标题
项2：简短标题
...

4. Summary

4. 会议摘要

A concise one-paragraph summary (1–3 sentences) of the meeting's objective and high-level outcome.

一段简洁的摘要（1-3句话），说明会议目标和主要成果。

5. Decisions Made

5. 已做出的决议

Each as a separate bullet:

Decision 1: statement of decision.
- Who decided / approved: [name(s) or group]
- Rationale (1–2 sentences): brief reason.
- Effective date (if applicable): YYYY-MM-DD
Decision 2: ...

每个决议单独列为项目符号：

决议1: 决议内容说明。
- 决议制定/批准人: [姓名或团队]
- 理由（1-2句话）: 简要说明原因。
- 生效日期（如适用）: YYYY-MM-DD
决议2: ...

6. Action Items

6. 行动项

Table-style bullets; must include owner and due date:

[ID] Action: short description
- Owner: Name (team)
- Due: YYYY-MM-DD or "ASAP" / timeframe
- Acceptance Criteria: (what completes this action)
- Linked artifacts / tickets: (optional URL or ticket id)

Example:

[A1] Draft deployment runbook for feature X
- Owner: Alex (Engineering)
- Due: 2026-02-05
- Acceptance Criteria: runbook includes steps for rollback, health checks, and monitoring links
- Linked artifacts: https://github.com/owner/repo/issues/123

表格式项目符号；必须包含负责人和截止日期:

[ID] 行动: 简短描述
- 负责人: 姓名（团队）
- 截止日期: YYYY-MM-DD 或 “ASAP” / 时间范围
- 验收标准:（完成该行动的判定条件）
- 关联工件/工单:（可选URL或工单ID）

示例:

[A1] 为功能X起草部署运行手册
- 负责人: Alex（工程团队）
- 截止日期: 2026-02-05
- 验收标准: 运行手册包含回滚步骤、健康检查及监控链接
- 关联工件: https://github.com/owner/repo/issues/123

7. Notes by Agenda Item

7. 各议程项详情

Brief, factual, timestamp optional:

Agenda Item 1: title
- Key points:
  - Point A (timestamp 00:05)
  - Point B (timestamp 00:12)
- Open issues / questions:
  - Q1: question text (owner if assigned)
Agenda Item 2: ...

简要、客观的记录，可选择性添加时间戳：

议程项1: 标题
- 关键点:
  - 要点A（时间戳00:05）
  - 要点B（时间戳00:12）
- 未解决问题/疑问:
  - Q1: 问题文本（若已分配负责人则标注）
议程项2: ...

8. Parking Lot / Unresolved Items

8. 待办停车场/未解决事项

Item: short description
- Why parked / next step:
- Suggested owner or next meeting to resolve

事项: 简短描述
- 搁置原因/下一步行动:
- 建议负责人或拟解决的下次会议

9. Risks / Blockers (if any)

9. 风险/阻塞点（如有）

Risk 1: short description, impact, mitigation owner
Risk 2: ...

风险1: 简短描述、影响、缓解措施负责人
风险2: ...

10. Next Meeting / Follow-up

10. 下次会议/后续跟进

Proposed date/time (if any)
Objectives for next meeting

拟议日期/时间（如有）
下次会议目标

11. Attachments / References

11. 附件/参考资料

Agenda document: URL
Slides: URL
Transcript / Recording: URL
Related tickets: list of URLs or IDs

议程文档: URL
幻灯片: URL
转录文本/录音: URL
相关工单: URL或ID列表

12. Version & Change Log

12. 版本与变更日志

Version: 1.0
Last updated: YYYY-MM-DDTHH:MM:SSZ
Changes: short notes on edits and who made them

版本: 1.0
最后更新时间: YYYY-MM-DDTHH:MM:SSZ
变更内容: 编辑内容及编辑者的简短说明

Style & Quality Rules

格式与质量规则

Keep minutes concise: total length should typically be under 1 A4 page for meetings <= 30 minutes and under 2 pages for meetings close to 60 minutes.
Use plain language and bullet lists for readability.
Prioritize decisions and action items at the top of the document.
Do NOT include speculative language or unverified claims. If something is uncertain, label it
```
TBD
```
and note the missing info source.
Use consistent timestamps and ISO 8601 dates (YYYY-MM-DD or full UTC timestamp).

保持纪要简洁：对于时长≤30分钟的会议，总长度通常不超过1页A4纸；对于接近60分钟的会议，总长度不超过2页。
使用平实语言和项目符号列表提升可读性。
在文档顶部优先突出决议和行动项。
不得包含推测性语言或未经验证的内容。若有不确定信息，标记为
```
TBD
```
并注明缺失信息的来源。
使用统一的时间戳和ISO 8601格式日期（YYYY-MM-DD或完整UTC时间戳）。

DO / DON'T

注意事项

DO:

Include owner and due date for every action item.
Provide acceptance criteria for action items when possible.
Link to artifacts (tickets, slides, recordings) for traceability.
Send draft for quick review if minutes contain significant decisions.

DON'T:

Omit decisions or action items — these are the primary value of minutes.
Mix personal opinions with facts. Keep commentary clearly marked as "Opinion" or exclude it.
Publish raw PII gathered during discussion unless required and authorized.

需执行：

每个行动项都包含负责人和截止日期。
尽可能为行动项提供验收标准。
关联工件（工单、幻灯片、录音）以确保可追溯性。
若纪要包含重要决议，发送草稿进行快速审核。

禁止：

遗漏决议或行动项——这些是纪要的核心价值所在。
将个人观点与事实混淆。若需保留评论，需明确标记为“观点”或直接排除。
除非必要且获得授权，否则不得发布讨论中收集的原始个人身份信息（PII）。

Example Prompts (for Copilot / Agent)

示例提示词（适用于Copilot/Agent）

Prompt to generate minutes from transcript:

"Generate meeting minutes from the following meeting transcript. Meeting title: 'Platform Weekly Sync'. Date: 2026-02-10. Duration: 45 minutes. Organizer: Priya (Platform Lead). Transcript: <paste transcript>. Follow the Strict Minutes Schema. Highlight decisions and create action items with owners and due dates where implied."

Prompt to generate minutes from notes:

"I have raw notes from a 30-minute design review. Title: 'Feature Y Design Review'. Date: 2026-02-11. Notes: <paste notes>. Produce concise minutes following the Strict Minutes Schema. Ask up to 3 clarifying questions if critical fields are missing."

根据转录文本生成纪要的提示词：

“根据以下会议转录文本生成会议纪要。会议标题：‘平台每周同步会’。日期：2026-02-10。时长：45分钟。组织者：Priya（平台负责人）。转录文本：<粘贴转录文本>。遵循严格纪要模板。突出决议并创建带有负责人和截止日期的行动项（如文本中有隐含信息）。”

根据笔记生成纪要的提示词：

“我有一份30分钟设计评审会的原始笔记。标题：‘功能Y设计评审会’。日期：2026-02-11。笔记：<粘贴笔记>。遵循严格纪要模板生成简洁的会议纪要。若关键字段缺失，最多提出3个澄清问题。”

Quick Templates (copyable)

快速模板（可复制）

Concise minutes template (short):

简洁纪要模板（短版）：

- Title:
- Date:
- Organizer:
- Present:
- Summary:
- Decisions:
  - Decision 1 — Who — Effective:
- Action Items:
  - [A1] Action — Owner — Due — Acceptance Criteria
- Next Steps / Next Meeting:

- 标题:
- 日期:
- 组织者:
- 出席人员:
- 摘要:
- 决议:
  - 决议1 — 制定人 — 生效日期:
- 行动项:
  - [A1] 行动内容 — 负责人 — 截止日期 — 验收标准
- 下一步行动/下次会议:

Detailed minutes template (full schema):

详细纪要模板（完整版）：

Use the Strict Minutes Schema above.

使用上述严格纪要模板。

Verification & Acceptance Criteria for Generated Minutes

生成纪要的验证与验收标准

A generated minutes document is acceptable if:

It contains Metadata, Attendance, Decisions, and Action Items sections.
Every action item has an assigned owner and a due date or a clear timeframe.
All significant decisions are captured with at least 1-line rationale.
Attachments or references are listed or explicitly marked
```
None
```
.
The document is factual; uncertain items are labeled
```
TBD
```
.

生成的纪要文档符合以下条件即为合格：

包含元数据、参会情况、决议及行动项部分。
每个行动项都已分配负责人，并设有截止日期或明确的时间范围。
所有重要决议都已记录，并至少包含1行理由说明。
附件或参考资料已列出，或明确标记为
```
None
```
。
文档内容客观；不确定的内容已标记为
```
TBD
```
。