| name | task-resumption-guard |
| description | 防中断断点续作技能 — 为长任务、复杂任务、多阶段任务提供系统化的防中断保护机制。 当用户要求执行需要较长时间、多步骤、或可能因Token/网络/会话中断的任务时激活。 提供：进度追踪模板、断点续作协议、静默前置条件检查（C1-C6）、双经济检查点、 长任务分段执行指南、防中断措施声明规范。 触发词："防中断" / "断点续作" / "分阶段执行" / "长任务" / "保存进度" / "暂停" / "恢复" / "checkpoint" / "resume" / "分段" / "分批" / "防止中断"
|
Task Resumption Guard — 防中断断点续作技能
核心原则
任何可能因以下原因中断的任务，都必须启动防中断保护：
- Token耗尽 — 上下文窗口溢出或配额耗尽
- 网络断开 — 网关重启、连接超时
- 会话超时 — 长时间无交互被系统回收
- 用户主动暂停 — 用户需要离开或切换任务
- 系统级中断 — 服务器维护、进程重启
触发条件（满足任一即激活）
- 用户明确说"防中断" / "断点续作" / "保存进度"
- 任务预估需要 >10 分钟连续执行
- 任务涉及 >3 个独立阶段或子任务
- 任务涉及文件创建/修改 >5 个
- 用户历史记录中有此任务类型中断的先例
防中断措施执行协议（6步法）
Step 1: 任务结构化拆分
将长任务拆分为最小可执行单元（Unit），每个单元满足：
- 可在 3-5 分钟内完成
- 有明确的完成判定标准
- 可独立保存进度
输出: 任务分解清单（编号格式 U1, U2, U3...）
[任务总览] {任务名称}
━━━━━━━━━━━━━━━━━━━━
总单元数: N
预估总时间: XX 分钟
保存路径: A-manyige/对话/YYYY-MM-DD/进度追踪.md
[U1] {单元名称} — 预计X分钟 — [待执行]
[U2] {单元名称} — 预计X分钟 — [待执行]
...
Step 2: 创建进度追踪文件
在任务开始时立即创建进度追踪文件：
A-manyige/对话/YYYY-MM-DD/{任务名}-进度追踪-YYYY-MM-DD-HHMM.md
文件必须包含:
- 任务总览与目标
- 单元清单（含状态）
- 已完成单元的交付物清单
- 当前执行位置
- 下次恢复时的入口点
- 已消耗的Token估算
Step 3: 每单元完成后立即保存
强制动作（每个单元完成后必须执行）:
- 更新进度追踪文件（标记该单元为完成）
- 确认该单元的交付物已落盘（文件存在、内容完整）
- 记录该单元实际耗时与Token消耗
- 汇报当前进度给用户
汇报格式:
✅ [U{n}] 完成 — {单元名}
📊 进度: {n}/{N} ({百分比}%)
⏱️ 本单元耗时: X分钟
💾 已保存至: {文件路径}
🔄 下一单元: [U{n+1}] {单元名}
Step 4: 静默前置条件检查（C1-C6）
长任务恢复执行前，必须验证以下静默前置条件：
| 条件 | 检查项 | 验证方式 |
|---|
| C1 | memory已追加 | 检查当日memory文件存在 |
| C2 | MEMORY.md指针同步 | 确认最新关键更新已写入 |
| C3 | TASK_MASTER.md已更新 | 确认任务状态为最新 |
| C4 | 当日代码可运行 | 快速验证关键脚本无语法错误 |
| C5 | Git已快照 | 确认有未提交变更或已提交 |
| C6 | 重启恢复自检通过 | 检查关键文件完整性 |
阻塞规则: 任一条件未通过，任务状态标记为 [BLOCKED]，不得进入执行阶段。
Step 5: 双经济检查点（每单元后）
每个单元完成后自问：
触发熔断的条件:
- Token预估不足以完成剩余单元 → 保存进度并报告
- 已完成部分无外部价值 → 重新评估任务必要性
- 连续3个单元效率<50% → 任务复盘，考虑终止
Step 6: 断点恢复协议
当任务因任何原因中断后恢复时：
- 读取进度追踪文件 — 找到最后完成的单元
- 验证交付物完整性 — 确认已完成单元的文件存在且未损坏
- 报告恢复状态 — 向用户汇报：
🔄 任务恢复: {任务名}
📍 断点位置: [U{n}] 已完成，准备执行 [U{n+1}]
📊 总体进度: {n}/{N} ({百分比}%)
⏸️ 中断原因: {原因}
✅ 已验证: 交付物完整，可安全继续
- 执行下一单元 — 从中断处无缝继续
长任务分段执行模板
见 references/long-task-template.md 获取完整的任务分解模板和进度追踪文件模板。
工具使用规范
- 创建进度文件: write 工具
- 更新进度: edit 工具（追加或修改状态标记）
- 验证交付物: read 工具（抽样检查）
- Git快照: exec 工具（git add + git commit）
反模式（禁止行为）
❌ 不创建进度追踪文件直接开始长任务
❌ 多个单元完成后才一次性更新进度
❌ 使用"稍后继续""下次再说"等模糊表述代替明确的断点标记
❌ 恢复时不验证交付物完整性直接继续
❌ 忽略双经济检查点导致Token耗尽在中途
最佳实践
✅ 任务开始时第一句就声明防中断措施已启动
✅ 每个单元完成后的第一句就是更新进度
✅ 进度追踪文件路径在对话中明确告知用户
✅ 中断恢复时先给用户一个清晰的"状态摘要"
✅ 使用编号格式（U1, U2...）让进度一目了然
