respawn（复活点）：断点续作

旧会话因 token 耗尽或中断"阵亡"，本技能让你在新窗口从存档点复活，接着上次的进度继续玩。

核心原则：旧会话历史一个字都不全量重读，只取结论；磁盘上的代码才是真相，摘要只当线索。

流程

1. 拿到会话 ID

• 用户消息里有 sess_xxx，直接用。
• 没有就问用户要。这是唯一必须来自用户的信息；可同时请用户用一句话描述任务（可选，用于聚焦检索）。
• 例外：用户已经手写了完整交接（任务目标 + 已完成改动 + 断点 + 剩余步骤）且质量足够时，直接用它，跳过第 2 步——现成手写摘要是 token 最省的路径。

2. 一次性取回断点上下文

调用宿主环境的会话上下文检索工具一次（ZCode 中为 ReadSessionContext，其他客户端用其等价工具；全任务只调这一次）：

• 取回策略选聚焦检索（strategy=relevant），摘要上限约 4000 token（maxTokens=4000）
• query 用下面这个模板（可按任务改写措辞，但保留五个要点）：

我要在新会话续作这个任务，请提取：
1) 任务目标与验收标准
2) 已完成的改动：按文件列出，每个文件做了什么关键改动
3) 断点：最后停在哪一步，卡点的根因，已定位但尚未执行的修复方案
4) 剩余待办：按执行顺序排列
5) 验证状态：哪些构建/测试/接口已验证通过，哪些还没验
不要贴大段代码，只要结论和文件路径。

3. 信任但要验证（必须先做，成本很低）

摘要是二手信息，且从旧会话结束到现在代码可能又变了。动手改之前先花最小成本核对：

• git status / git diff --stat 看工作区有哪些改动
• 对摘要声称"已完成"的 1-2 个关键点用 grep 抽查（如函数是否存在、路由是否注册）
• 构建命令重跑一次（如 go build ./... / npx tsc --noEmit，有缓存很快）
• 摘要与实际不符时以磁盘实际为准，继续前告诉用户差异在哪

4. 续作

• 把剩余待办建成任务清单（如 TodoWrite），逐项执行
• 读文件只读目标行段（offset/limit），不整文件重读
• 不重复已验证通过的步骤（如已跑通的耗时 E2E），除非相关代码又改了
• 完成后汇报：从哪里接续的、本次新增改动、验证结果

省 token 红线

• 会话检索全任务只调一次；取回的摘要不完整时，靠核对磁盘补齐，不要再查旧会话
• 不重读摘要里提到的所有文件全文，只读要改的行段
• 不重跑已验证通过的耗时测试
• 委派 subagent 时只把结论传给它，旧会话全文由本流程一次性取回，subagent 不再访问