adhd-daily-start git:20261031.cc8c1c0A

Immutable. This exact content never changes and is served at /api/v1/blob/a2fe8592d6f10aab.

---
name: adhd-daily-start
description: "任务太大不知从哪开始、容易分心、想把今天的任务拆成可启动的三步。普通聊天容易排满一天；本技能依据今天的精力、硬约束和卡点，交付能立即启动且允许中断恢复的三步计划。"
---

# ADHD 友好日计划

## 一句话主餐

普通聊天容易排满一天；本技能依据今天的精力、硬约束和卡点，交付能立即启动且允许中断恢复的三步计划。

## 输入

- 读取现有待办、日历、未完草稿或用户随口描述，不要求先整理。
- 确认今天必须发生的事情、真实截止时间和可用时段。
- 请用户用低、中、高描述当前精力，可不提供诊断信息。
- 识别卡点是任务含糊、材料缺失、难以取舍还是环境干扰。
- 未知时间采用顺序清单；未知精力采用低负担起步，不假装获得日历访问权。

输入处理顺序：
1. 从原始待办提取外部截止、自定期待、等待项，不把三者混排。
2. 未知日历权限时只使用用户给的时段，不声称已同步。
3. 时间不明先给动作顺序；精力不明先选可在两分钟内启动的动作。
4. 不要求用户证明诊断或讲病史；只问当前阻碍和今天可用时间。

## 核心判断

1. 硬截止与自我期待分开；先保护真实承诺，再安排可选推进。
2. 启动动作必须包含动词、对象和结束标志；“研究项目”不能直接排入。
3. 估时仅作起点，以用户实际耗时调整，不作为自律评分。
4. 优先减少任务切换，将找材料与正式制作分开。
5. 日计划用于任务支持，不诊断 ADHD，也不提供用药或治疗建议。
6. 中断视为可恢复状态，保留文件位置和下一动作，不惩罚性补排。

判断落地检查：
- 多件硬截止冲突时先列最迟启动时间，不能用唯一主任务掩盖另一承诺。
- 对每步检查动词、对象、结束信号；任一缺失就再拆一次。
- “低精力”只降低启动负担，不推定用户能力或治疗需要。

## 编号工作流

### 1. 收拢今天的承诺

- 从原始材料列出任务和截止。
- 最多提出一个会改变排序的问题。
- 把不影响今天的任务放入停车区。
- 标记等待他人回复的事项。
- 交付：今天必须做、可做、等待三类清单。

### 2. 选一个推进目标

- 按截止、后果和前置依赖选主任务。
- 目标写成可见成果，如一页汇报初稿。
- 把完美版本降成今天够用的版本。
- 说明本轮暂缓的任务。
- 交付：唯一主目标及取舍原因。

### 3. 拆成今天三步

- 第一步应能在几分钟内完成。
- 第二步产出粗糙但可看见的中间稿。
- 第三步只做最低限度核对或交接。
- 每一步都注明完成信号和需要的材料。
- 交付：动作、时间盒、结束标志三列表。

### 4. 安排启动环境

- 指出要打开哪个文件或页面。
- 只移走一个最明显的干扰源。
- 提供用户可拒绝的短时间盒。
- 时间不足时保留第一步和草稿保存动作。
- 交付：现在这一分钟的具体行动。

### 5. 准备中断恢复

- 每一步结束保存一句“下一步做什么”。
- 被打断后先读恢复句，不重新整理全部计划。
- 卡住时把当前动作再拆小一次。
- 材料未到则改做不依赖它的部分。
- 交付：一张可直接复制的恢复卡。

### 6. 用实际反馈重排

- 接收完成、卡住、没开始中的任意状态。
- 记录实际阻碍而非评价态度。
- 只调整剩余步骤和估时。
- 当天无法完成时说明最低交接成果。
- 交付：下一动作及是否移到明天的明确结论。

## 直接交付与下一步

- 今天三步计划、停车区和一张中断恢复卡。
- 用户现在只执行第一步，不同时启动三个任务。
- 完成标准是得到约定的最低成果，允许后两步按真实反馈调整。
- 用户反馈一句“做到了哪里、卡在哪里”即可续接。
- 提醒工具不可用时提供手动闹钟文字，不声称会主动催办。

交付前验收：
- 逐个硬截止检查是否覆盖；容量不足时给缩减成果与协商草稿。
- 时间盒总和加缓冲不得超过用户时段；顺序计划不伪造钟点。
- 第一步必须能在用户现有工具与材料下开始。
- 恢复卡包含已保存的位置和下一具体动作，不能只写“继续加油”。
- 只交付任务支持；不宣称能诊断、治疗或保证生产力。

## 外部参考与延展

- 比较已有日程清单方法与用户成功记录：日历用于保护硬约束，三步拆分用于降低启动成本，两者不能相互替代。
- 可检索大学学习支持中心 executive function task initiation implementation intentions，比较“何时何地做何动作”与纯优先级清单。
- 只采用用户可拒绝、现有工具可执行的动作支持；不把通用效率方法包装为临床结论。
- 用同一未启动任务验证：能否指出要打开的文件、第一行写什么、中断后从哪里回来；用户实际反馈到来前不声称已改善。

### 排不下与启动失败的处理

- 先扣除会议、通勤等不可挪时段，再计算可行动容量。
- 两件必须交的任务冲突：比较错过后的后果与依赖，逐项说明取舍。
- 不替用户悄悄取消硬承诺；给需要协商的对象、最迟联系时点和消息草稿。
- 三步是同一主目标的推进，不是要求同时完成三个大项目。
- 第一步仍未开始：把“写汇报”降为“打开已有文件并写一个标题”。
- 找不到材料：先建立目录和缺口单，避免把全时段耗在搜索。
- 时间盒造成压力：改用“写一行后可停”的完成信号。
- 中断回来：从保存位置继续，已经完成的步骤不重排。
- 当天容量用尽：保存粗稿与恢复句，再决定是否需要协商截止。
- 案例见 [低精力计划与中断续接](references/example.md)。

材料已经足够时直接交付；引用外部资料只帮助选择机制，不替代用户输入。
收到同类失败反馈时保留原输入与旧输出，修订判断后以原案例重跑，并同步 README 与示例。
本轮案例采用明确模拟材料，不包含用户个人事实，也不宣称验证真实使用效果。