异步决策包

它解决什么问题

很多团队的会议并不是为了做决定，而是为了"对齐一下"。当有人问"这件事还需要开会吗"，真正缺失的往往是三样东西：谁有最终拍板权、最晚什么时候必须决定、有哪些可比较的选项。这个技能把"想聊聊"还原成一次结构化的书面决策：先让合适的人在期限内读同一份材料，只有当书面协作确实无法消解分歧时，才把问题升级为会议。

它是怎么工作的

核心流程 decide-sync-or-async 分四步：

• 把模糊诉求改写成一个有边界的待决定问题，并确认决策权归属、含时区的期限、材料范围与至少一个可行选项；
• 检查四项条件能否都在书面材料中获得：共同事实基础、可比较选项、可追踪的异议、清晰的决定权；
• 全部具备时输出 ASYNC_DECISION_PACK；若存在不可书面消解的关键分歧、依赖即时澄清的复杂信息、高影响权限或承诺，或书面反馈相互矛盾无法归并，则返回 MEETING_ESCALATION；
• 对升级会议只给出最小参会角色、待决定问题与退出条件，不自动建会、不拉人。

build-pack 负责整理材料，要求把事实（附来源）、待确认假设、建议默认项和未回应项分开写；每项选项都写明收益、成本/风险与所依赖的证据，证据不足就标记"待补充"，而不是伪造量化比较。异步反馈格式也由它设计，例如 同意 / 反对 / 替代项 + 原因或证据。

handle-urgent-decision 保证"紧急"不能成为跳过决定权的理由：仍须有唯一最终责任人、含时区的紧急期限、至少一个选项和材料范围。handle-deadline 处理到期未回的情况——沉默不等于同意，它会列出已收反馈与未回应角色，但不催办、不发消息、不替用户宣布通过。

状态契约固定为五种：MISSING_INPUT、ASYNC_DECISION_PACK、MEETING_ESCALATION、DEADLINE_REACHED、AUTHORITY_CONFLICT。当多人都被写成最终拍板人，或否决权与通过权相互冲突时，返回 AUTHORITY_CONFLICT，由用户确认唯一责任人与异议规则，技能不会按职级或发言频率自行排序。

适用边界

这是一套纯文本决策规则：不联网、不调用外部 API、不读取未授权的聊天或文档，也不向任何人自动发送、催办或创建任务，外发与写入都由用户和宿主另行确认。它不会替用户拍板，也不会虚构选项、利益相关者、数字或风险——信息不足时直接返回 MISSING_INPUT，逐项追问最少需要补什么。

宿主负责定时唤醒、重试、超时与投递，技能本身没有时钟和队列。宿主遇到网络、权限、解析或超时失败时返回 RUNTIME_RETRYABLE，只按原材料范围做只读重试；投递状态无法确认时返回 DELIVERY_UNCERTAIN，保留同一份决策包供核验，不重复投递，也不把草稿当作已生效的决定。