foundation-meeting-agenda

会议议程

会议议程是一份面向参会者的结构化文档，用于在会议开始前明确预期。它回答“我们将讨论什么、每个主题由谁负责、时间将如何分配，以及怎样才算完成？”与会议简报不同，会议简报是用户私下进行的策略准备；议程则与参会者共享，重点在于结构和流程。

此技能属于会议技能系列。它符合会议技能系列契约，该契约规定了所有会议技能共用的 frontmatter、文件命名、go 模式行为模式和通用输出要求。

适用场景

• 组织或主持跨职能工作会议、项目启动会、利益相关方评审会或决策会议
• 参会者超过 3 人或时长超过 30 分钟的任何会议
• 需要每次重新明确结构的定期会议（1 对 1、团队同步会）
• 项目推进过程中需要明确预期成果以避免偏离方向的对齐时刻

不适用场景

• 用户的准备工作属于私下、战术性的内容（立场、对利益相关方的判断、诉求）。请改用 foundation-meeting-brief。
• 会议已经结束。请改用 foundation-meeting-recap 进行会后总结。
• 用户想向未参会者传达会议成果。请在会议结束后使用 foundation-stakeholder-update。

零阻碍执行

根据系列契约，此技能不会因询问而阻塞。默认流程：

1. 阅读所有已提供的输入（主题、引用的文件、参会者名单、限制条件）
2. 推断缺失值（根据主题关键词判断会议类型、采用默认时长、根据主题措辞判断目标、根据上下文推断参会者角色）
3. 简要呈现推断摘要，并接受单词 go 或用户的更正
4. 生成议程

如果使用 --go 调用，则跳过推断摘要，直接使用默认值生成输出（时长 30 min、会议类型 other 等）。如果用户一开始就提供了所有值，则不会出现检查点。

仅当关键输入的推断置信度明显偏低且没有合理的默认值时，才会提出阻塞性问题。这种情况应当很少出现。

会议必要性检查

此技能会以一个明确的问题开场：“这件事需要开会吗，还是可以异步处理？”

v1.1.0：现在需要明确说明同步讨论的价值，才能通过检查。 只有满足以下至少一项，会议才能通过检查：

• 需要讨论的取舍。存在多个选项，且偏好尚不明确
• 需要解决的冲突。明确指出存在意见分歧的利益相关方
• 共同创作。在会议中共同进行白板讨论或撰写文档
• 建立关系。首次与利益相关方会面、相互校准
• 升级处理阻碍。需要及时排除阻碍

如果以上均不适用，此技能会建议采用异步方式（书面更新、文档评审、Slack 投票），并生成一页简短的“如何异步处理此事”说明，而不是会议议程。

v1.0.0 版的这项检查（“没有取舍的单负责人决策”“纯信息广播”“超过 5 人的纯状态同步”）太容易被绕过。用户会把参会者人数控制在 5 人，或在主题中加上“决策”。更严格的 v1.1.0 版倾向于异步处理；用户仍可覆盖此建议。

此检查也适用于 foundation-meeting-brief，但会后技能（recap、synthesize、stakeholder-update）不会运行此检查。

说明

当用户要求创建会议议程时，请遵循以下步骤：

1. 进行反会议检查 应用上述触发模式。如果用户的目标符合条件，提出异步替代方案并询问是否覆盖。只有在用户明确要求覆盖后，才继续执行第 2 步。

2. 解析并加载输入 阅读主题或目的。加载提供的所有 @file 引用。提取参会者名单、时间限制或关联文档。

3. 推断缺失值 应用以下推断规则：

   值	推断依据	默认值
   会议类型	主题关键词、参会者资历组合	other（低置信度）
   时长	主题文档中的明确说明（少见）；当会议类型的推断置信度达到中等或更高时，采用该类型专属的默认时长	v1.1.0：按类型设定（参见类型契约）。仅 other、1-on-1、exec-briefing、customer-call 为 30 分钟。Kickoff = 60 分钟，working-session = 60 分钟，decision-making = 45 分钟，等等。
   目标	主题措辞	进行推断；在摘要中说明
   参会者 RACI	资历、主题归属线索	标记所有推断
   预期成果	目标加会议类型启发规则	提供初步方案

   关键推断门槛（v1.1.0）：当参会者 RACI 或预期成果的推断置信度低于高置信度时，必须在执行模式摘要中用 ⚠ 标记。参见类型契约中的“零摩擦执行”部分。

4. 提供执行模式推断摘要 显示带置信度标记的推断值。用户可以输入 go 继续，也可以提出修改。任何修改后都要重新进行推断并再次提供摘要。

5. 设计限时议题列表 应用相应的会议类型变体（见下文）。安排各议题时长，使其总和等于会议时长。如果议题列表超出可用时间，必须明确标出并要求协调（不得悄悄删减）。

   每个议题都必须包含：

   • 类型标签：Discussion | Decision | Information | Working
   • 负责人（姓名或团队）
   • 目标（完成后的状态）
   • 时间分配
   • 预读链接（如有）

6. 指定参会者准备事项 列出必要的准备事项，附上链接和预计准备时间。为希望深入了解背景的参会者补充建议阅读的背景材料。添加“请准备好……”要求，明确每位参会者需要贡献什么。

7. 添加待议事项和后勤占位符 待议事项用于记录会议中提出的题外内容。后勤部分涵盖加入链接、所需材料和录制负责人。

8. 填写 TEMPLATE.md 并渲染 删除最终文档中的所有指导性引用块。

9. 验证输出

   • Frontmatter 结构符合类型契约的通用基础字段以及议程专属字段（meeting_duration_minutes、desired_outcomes）
   • 议题时长总和与会议时长一致（容差为 +/- 2 分钟）
   • 至少列出一项预期成果
   • 在 Generation context 中记录反会议检查结果

会议类型变体

在步骤 5 中应用。每种变体都会调整主题列表，以匹配会议目的。

• 1-on-1：滚动式结构。上次的事项、本次的主题、成长或发展、阻碍。默认 30 min。
• standup：轮流汇报状态、升级事项、需要做出的决策。默认 15 min。
• planning：聚焦承诺、检查容量、梳理依赖关系。默认 60 min。
• review：优先演示、充分的会前阅读材料、明确的反馈收集机制。默认 60 min。
• decision-making：预先列出选项和决策标准，并明确提出决策请求。必须提供提案作为会前阅读材料。默认 45 min。
• brainstorm：议程精简、使用激发创意的提示词、不施加决策压力。默认 45 min。
• stakeholder-review：先给出 TL;DR，以业务影响为框架，并在开头明确提出请求。默认 45 min。
• project-kickoff：范围、角色、成功标准、风险、沟通计划。默认 60 min。
• working-session：议程精简、必须完成会前准备、明确交付成果。默认 60 到 90 min。
• exec-briefing：先给出 TL;DR，之后再提供支持性细节。默认 30 min。
• other：通用主题结构，默认 30 min。

项目记忆约定

仅当 .claude/pm-skills.local.md 存在时启用。如果没有该文件，请完全忽略本节， 并严格按照上述说明执行。

• 读取：active_initiative 和近期的 decision 产物，让议程反映已确定的事项，不再安排时间重新讨论。
• **写入：**无。议程是尚未举行的会议计划；会后总结才是需要长期留存的内容。
• **处理方式：**提出条目并等待确认后再写入，除非 设置了 memory_auto_append: true，此时追加内容并复述写入的内容。

此约定与系列内基于文件名的串联方式互为补充，而非取而代之：文件名仍用于定位单次会议的关联产物，而项目记忆则在多次会议之间保留持久的产品背景信息。

质量检查清单

交付议程前，请确认：

• 已执行并记录反会议检查
• 已设置会议类型（或明确设为 other，并标记为低置信度）
• 已设置时长（未提供时默认为 30 min，并标记为默认值）
• 预期成果具体且可验证（不是“讨论 X”，而是“决定是否发布 X”）
• 每个主题都有类型标签、负责人、目标和时长
• 各主题时长之和等于会议时长
• 已列出会前阅读材料的准备时间（未注明时长时，与会者会跳过准备）
• 后勤安排部分包含加入链接和材料引用
• 可分享摘要为 5-6 行，可直接粘贴到 Slack
• Sources and References 部分包含 Generation context，列明已应用的默认值和作出的推断

另请参阅

• 会议技能系列约定。共享的行为与结构要求
• foundation-meeting-brief。用户的私人会前准备（共享反会议检查）
• foundation-meeting-recap。后续步骤：从本议程的主题列表自动填充会后总结
• foundation-stakeholder-update。后续步骤：向未参会者传达会议结果