会议就绪度检查

你要解决什么问题

日历上的会议越来越多，邀请往往写得很漂亮：时间、地点、参会人一应俱全，但真正决定一场会议价值的东西——要回答什么问题、留下什么产出、谁对结论负责、依据是什么、什么时候必须交付——常常一句没有。这类会议的常见归宿是：开完两小时，没人知道结论归谁，下一步没人认领。

会议就绪门（Meeting Readiness Gate）要拦的就是这类会。它在会议进入日历之前，用一份“会议契约”逐项核对必要信息，给出明确结论，而不是靠感觉判断“这个会该不该开”。

它是怎么做的

核心流程分五步：

1. 确认会议类型：决策、规划、评审、工作坊或关系沟通，不同类型的就绪标准并不一样。
2. 收集契约字段：目标、期望产出、决策负责人（如适用）、主持人、时限、参会角色、议程、预读和开放问题。
3. 落盘为 JSON：把会议契约保存为 UTF-8 JSON，在 Skill 根目录运行检查器。
4. 解释三种状态：READY 可以保留或安排；CONDITIONAL 只有在截止前解决警告项才能保留；NOT READY 先延期、取消或转异步，直到阻塞项解决。
5. 只补缺失，重跑验证：基于就绪契约生成缺失的部分，不为追求外观重写已有材料；修改后重新运行检查器，展示前后状态与就绪度变化。

门禁规则上，决策会缺少可观察目标、具体产出或决策负责人时直接判未就绪；缺少主持人、有效时限、参会角色、决策预读或议程则给出明确警告。只有状态播报、没有任何实时专属问题的会议，建议取消或改成异步；预读中保留开放问题，不为显得“准备充分”而隐藏不确定性。

输出时第一行给结论，随后依次是阻塞项、警告项、最小准备计划、负责人、截止时间和可直接复制的邀请更新文本。

适用边界与注意点

• 不替你操作：先展示拟修改的内容和原因；未经明确授权，不创建、更新或取消会议，也不通知参会者。
• 腾讯会议相关流程走独立的“腾讯会议增强”流程，不在本技能范围内。
• 平台兼容：以 WorkBuddy 的 ZIP 上传与本地执行为首要场景，同一份核心结构兼容 Claude Code 与 Codex。
• 语言：默认输出中文，仅在用户或参会团队需要时补英文。