decide-next-action

name	decide-next-action
description	汇总全部治理层飞书 Profile 的任务与近期日历、Obsidian 仪表盘以及已登记 Agent 项目状态，判断用户现在最值得执行的一个下一步，并给出可立即开始的行动、完成标准、建议投入时长、选择依据和少量备选。用于用户询问“下一步做什么”“现在该干什么”“先做哪个”“当前最值得推进什么”，或面对多个项目和任务难以判断轻重缓急时。默认只读，不创建任务、不修改项目、不写 Obsidian、不生成完整日程、不写日历；需要记录任务时转交 feishu-task，需要规划或重排一段时间时转交 personal-schedule-planner。

决定下一步行动

从用户现有系统中取得足够而不过量的实时证据，给出一个明确、可立即执行的下一步。不要把结果退化为待办清单、完整日程或泛泛建议。

职责边界

• 默认由{{GENERAL_ASSISTANT_PROJECT}}的“个人时间管理员”承接；已有等价岗位或窗口时复用，不新增重复岗位。暂时无法调用长期岗位时，由当前会话完成，不得因此阻塞。
• 本 Skill 只做即时决策和只读建议，不修改任何来源。
• 用户要安排今天、未来几天或本周时，调用 personal-schedule-planner。
• 用户要创建、更新或记录飞书任务时，调用 feishu-task。
• 用户只问某个明确项目内部的下一步时，以该项目为主，其他来源只用于发现硬冲突；不要无意义地全局采集。

工作流程

1. 确定决策窗口

读取当前带时区时间，识别下一项固定日程和此前对话中用户刚刚说明的地点、精力、可用时长或临时要求。

• 默认回答“从现在开始先做什么”，不自动生成全天时间表。
• 默认观察未来七天的截止、依赖和冲突，但只选择当前一个行动。
• 只有地点、精力或可用时长会实质改变首选时，才询问一个最小问题；否则明确合理推定并继续。

2. 只读采集

需要全局判断且环境支持会话内临时子智能体时，并行启动三条只读分支；规模很小或无并发能力时顺序执行，保持相同范围。

飞书

1. 读取 GLOBAL 的 LARK_PROFILES.md，覆盖其中全部治理层 Profile，不以当前 active Profile 代替全量范围。
2. 每个 Profile 显式使用对应身份，读取当前用户负责或实际需要执行的未完成任务、开始/截止时间、可靠工作量，以及当前至观察窗口内的日历占用。
3. 不把仅关注、由他人执行或只是等待反馈的任务误判成用户当前行动；不默认读取无关附件或任务全文。

Obsidian

1. 先按 GLOBAL 的 OBSIDIAN_LINK.md 定位并读取 仪表盘.canvas。
2. 只对与候选行动有关的 Wikilink、Canvas 文件节点和受限 Dataview 查询范围选择性读取；需要 .base 时按 obsidian-bases 规则理解。
3. 不递归遍历 Vault，不写入 Obsidian，不把愿景或长期方向直接当作当前承诺。

项目

1. 从 GLOBAL 的 PROJECTS.md 获取活跃项目。
2. 读取候选项目的 AGENTS.md、README.md、STATUS.md；只有需要验证明确下一步、阻塞或验收标准时，才读取具体任务文件。
3. 以项目实时文件为事实，不用历史摘要代替当前状态，不对项目目录做递归普查。

三条分支使用同一个采集截止时间，并回报实际覆盖、候选事项、固定冲突、风险和准确错误。主 Agent 等待所需分支回报后统一去重和判断；来源缺失会改变结论时，先安全补采，仍失败则说明缺口和置信度。

3. 归一化候选事项

• 以飞书任务 GUID、项目路径、日历事件 ID 和明确交付语义去重；同一事项跨来源出现时保留全部证据，但只形成一个候选项。
• 区分“用户现在可执行”“等待他人”“固定承诺”“长期方向”“仅供参考”。只有第一类进入行动选择，固定承诺用于限制时间窗口。
• 每个候选至少保留：来源、项目、截止、依赖、阻塞对象、建议投入时长及置信度、战略价值、当前环境适配度和可验证完成标准。
• 没有可靠时长时给出保守估时并标明低置信度，不把“尽快”“有空”自行转换为硬截止。

4. 做出选择

完整读取 下一步决策模型。先排除当前不可执行、非用户职责、已被固定日程挤占或证据不足以行动的事项，再结合：

1. 已存在且即将发生的固定承诺。
2. 已逾期或临近截止的用户责任。
3. 会阻塞他人、解除关键依赖或降低重大风险的事项。
4. 用户刚刚明确强调的目标与高战略价值推进。
5. 当前可用窗口、精力、地点、所需工具和切换成本。
6. 能否在建议时间内产生清晰、可验收的阶段结果。

不要使用机械总分替代判断。最终必须选择一个首选；只有证据确实无法区分且一个最小问题会改变结论时才暂停询问。

5. 给出结论

回答应短而具体，先给结论：

现在建议先做：<一个行动>
建议投入：<时长或直到下一固定日程>
完成标准：<本轮可验收结果>
为什么是它：<最关键的 2–4 条依据>
开始动作：<第一步，能够立刻执行>
置信度：高 / 中 / 低；<必要推定>

备选：
1. <只在首选暂时无法执行时使用>
2. <可选；没有合格备选时不硬凑>

• 备选最多两个，并说明切换条件；不要输出未经筛选的长清单。
• 如果下一固定承诺已经很近，首选可以是准备、通勤、吃饭或短暂恢复，而不是强塞工作任务。
• 简要说明一两个看似紧急但未被选择的事项及原因，避免用户误以为遗漏。
• 不展示内部采集流水、完整任务正文、客户秘密、人员隐私、凭据或无关项目细节。

后续联动

• 用户接受建议并准备直接执行时，结束于清晰的开始动作，不做外部写入。
• 用户要求“把它加入任务”“改到明天”等任务维护时，把已确认行动交给 feishu-task，由其完成去重、写入和回读。
• 用户要求“按这个安排今天”“给我排一下时间”或需要调整多个时间块时，把候选、依据、固定冲突和用户选择交给 personal-schedule-planner，重新执行其采集、协商与确认流程；本 Skill 的建议不构成日历写入授权。

安全边界

• 默认只读。没有用户对具体写入的明确要求，不创建或更新任务、日历、项目文件和 Obsidian 内容。
• 不把跨 Profile 汇总误解为可以改变任务所属 Profile、负责人、状态或业务归属。
• 不因某个来源暂时不可用而伪造“已完整检索”；明确缺口、影响和结论置信度。
• 不把“下一步建议”表述为已承诺完成，也不擅自通知他人或公开业务信息。