技能介绍

问题在哪

多步 Agent 任务最容易丢的是「状态」：上下文被截断、中途改方向、搜索和浏览器结果没落盘，最后只能重复失败或向用户复述一遍已经做过什么。纯靠对话记忆无法可靠地做 ≥2 步工具链（搜完再写、改多个文件、调研→产出），也缺少交付前的自检。

技能如何工作

本技能把 持久化 Markdown 当作磁盘上的工作记忆，用固定文件分工：

task_plan.md：目标、阶段、进度、决策与错误表
findings.md：调研、URL 与任何新发现（2-Action Rule：每两次 view/search 就写入）
progress.md：会话日志与测试结果

硬性流程要点：

先建计划：满足触发条件（多工具调用、多文件修改、非 trivial 的「帮我…」等）时先跑 init-session.sh，再执行具体动作。
阶段边界：每阶段完成后更新 plan、打 JSON checkpoint（.planning/checkpoints/，保留最近 10 个），必要时按 Pivot Rule 对照 findings.md 增删阶段，不硬撑原规划。
失败不重试同招：错误记入 plan 错误表，走 3-Strike（诊断→换方案→质疑假设→升级用户）。
断点恢复：上下文丢失用 resume.sh 一键拉齐当前阶段与发现，而不是逐个重读仓库文件。
交付前：validate-plan.sh 检查阶段状态与 checklist 是否一致；status.sh 可当进度仪表盘。
零配置维护：首次 auto-track.sh --now 若输出 AUTOTRACK_CRON_MISSING / REVIEW_CRON_MISSING，Agent 应注册定时任务做 plan 维护与完成后蒸馏归档。

适用边界

可跳过建计划的场景限于：纯问答、单文件扫一眼、单次搜索、寒暄。不要把大段外部内容塞进 task_plan.md（应进 findings.md）。本技能依赖你（或运行环境）能执行文档中的 shell 脚本与 cron 注册能力；没有 checkpoint 时恢复会降级为解析 plan 文件，精度会差一些。

截图预览

使用场景

Agent 需连续 web 搜索、抓取页面再撰写总结时，先 `init-session` 建 plan，每两轮检索把结论写入 `findings.md`。
一次改动涉及多个源码或配置文件，用 `task_plan.md` 分 phase 推进，错误记入计划表并遵守三次失败换方案。
长会话上下文被截断后，运行 `resume.sh` 对齐当前阶段与下一步，而不是逐个重读仓库文件。
交付前执行 `validate-plan.sh`，排查 phase 已 complete 但 checklist 未勾齐或多个 phase 同时 in_progress 的状态。

适合人员

在 Agent 运行时串联搜索、写文件、跑验证等多步工具调用的工程师，需要任务进度与错误落在 Markdown 而非对话上下文里。
维护 OpenClaw 等 Agent 环境、要在系统规则里强制「≥2 步先 init-plan」的平台或技能集成开发者。
长周期 agent turn 容易丢上下文，需要在 phase 切换时用 `snapshot.sh` 打 checkpoint 并响应 `auto-track.sh` 的 cron 注册信号。
经常下发「帮我调研/搭服务/批量改配置」类非 trivial 任务、执行中可能 pivot 的研发，要在阶段边界对照 findings 调整 plan。