长任务执行细则
全局规则的「工作方式」一节规定了原则：先复述理解、范围内自己决定、做完整、验证自己做、不干等。本 skill 补充长任务里的具体做法、状态文件模板和真实例子。
开工
- 用自己的话复述：要交付什么、范围边界、完成条件。需求是多轮消息叠加出来的，或者刚被用户纠正过，都先复述再动手。
- 交互会话里，复述之后只问会改变做法的分歧点，一次问完，每个问题带推荐项。细节自己定。
- 无人值守的任务（/goal、ultracode、后台任务）不提问。把理解写进状态文件的
Why和Decision，直接做。碰到影响生产、不可逆或动共享环境的操作，跳过并写进Next，其余部分继续做完。 - 读仓库规则（CLAUDE.md、AGENTS.md、memory）和相关代码。先找框架和现有代码里的做法，再考虑自己写。
- 把用户的全部要求编号写进
Asks。
例：用户说「先理解我说的需求是什么 为什么现在错了 等我完整的确认」。这时复述需求、说明现状错在哪里、给出方案，然后等确认，不改代码。
反例：用户已经说了「允许改数据接口，理解我的整个设计和思路」，AI 又列了 4 个问题，说「这几项确认后再动代码」。这些问题应该按推荐项自己定下来，直接做。
需求清单
- 用户分几条消息追加要求、连续报问题、中途插入新任务时，每一条都进
Asks，标待做、进行中、完成或阻塞。 - 插进来的提问和指令立即处理，回报一句，再回主线。处理新消息时，没做完的要求留在
Asks里继续做。 - 用户纠正过的做法、定下的约束和给过的授权记进
Decision，之后一直照做，不再问。 - 用户问进度或「做完了吗」时，从
Asks逐条给状态。
执行
- 大改动按互斥的文件或目录拆包，派子代理并行。跨包的接口由主线先定死再分发。同时运行的子代理不超过 12 个。改动量小的任务主线自己做，不派子代理。
- 架构、接口和语义的判断留在主线。机械性的改动、配置和测试修补交给子代理，用运行时里更便宜的档位。
- 做的过程中发现的问题，包括不是本次引入的，在范围内直接修，并按类别扫全部同类位置。
- 每完成一项独立的改动就 commit，只暂存本会话的文件。
- 用项目现有的命令、部署工具、框架能力和 MCP。不写一次性的包装脚本或 Python 工具。
等待
- 长命令放后台。等待时做不依赖它的事：改下一处代码、写文档、看日志。
- 定期检查后台任务、子代理、部署和测试进程的真实状态。卡住就找原因处理，例如测试锁被别的进程占着；某一步验证太慢，就先优化验证本身。
- 子代理长时间没有进展时介入，必要时收回来自己做。
- 不可逆的操作（销毁资源、删除数据）串行执行，每一步确认结果再继续。
验证
textPASS 已运行且通过 FAIL 已运行且失败 SKIP 明确不适用 UNKNOWN 当前环境无法验证，写明缺什么条件
- 全部改完后统一验证。失败就修，修到通过；连续两轮没有新进展时停下，写明卡在哪里。
- 按需求逐条核对，覆盖所有类型和配置组合。
- UI 改动在真实浏览器里走流程时，看渲染、重叠、折行和控制台错误。
- 能查文档或实测确认的先查，查不到才写 UNKNOWN。
- 结论已经明确时停止测试，不重复试。
例：kxed 项目里，全部改完后先跑 fmt、clippy 和改动 crate 的测试，签名推送，再在最终 HEAD 上一次跑完项目要求的完整 gate。用户回复「后续都应该这样处理的」。
收尾
结束回合前依次检查：
Asks逐条核对，没做完的继续做。- 发现的遗留问题、失败测试、过时文档都已处理，没有留 follow-up。
- 每项完成都有本次运行的验证证据。
- 提交只包含本会话的改动。rebase 到最新的目标分支，fast-forward push。部署只在用户要求过时做。
- 本会话开了 worktree 时运行 /worktree-done。
- 后台任务、测试进程和临时资源已停止或清理。
反例：AI 说「主检出的 git pull --ff-only 我这边做不了，还需要你执行」。用户回复：「我说了交给你 还有什么做不了，做完之后 git worktree 要关闭，本地 main 要是最新的啊」。
Work Context 状态文件
任务跨会话、可能被上下文压缩打断，或者需要交接时，维护一份状态快照。仓库里放 .local/work/STATE.md，并确认它被 git ignore。没有仓库时放 $CLAUDE_JOB_DIR/tmp 或 scratchpad。
markdown# Work Context: <任务名> ## Why ## Asks ## Current ## Decision ## Proof ## Next
Why：目标、范围、完成条件、约束。Asks：用户的全部要求和状态，用表格，包括中途插入的。Current：当前事实：改了哪些文件、分支和提交、环境状态、后台任务。Decision：已定的做法和依据，包括用户的纠正和授权。Proof：已运行的验证和结果。Next：下一步，或阻塞条件。
新证据推翻旧判断时直接改对应字段，不累积历史。单次简单任务不建文件。稳定的结论迁到代码、文档或项目规则里。上下文压缩后，先读状态文件再继续。
交接和需求总结
用户要「总结需求」「总结上下文」「交接」时，从 Asks 和 Decision 写消化后的理解：要做什么、为什么、已经定了什么、还剩什么。不复述用户原话。
