关于 continue-codex-work
供 Agent 在不同上下文中接手先前 Codex 会话的未完成工作。技能要求先验证历史读取结果,再核对项目现状与既有操作,并按原任务汇报进度。
主要功能
- 01要求验证 Codex 历史读取凭据
- 02重建任务目标与交付约定
- 03检查当前工作区和外部状态
- 04核实既有操作及中断中的工作
- 05汇报已完成与待完成结果
适用场景
- 01从另一个 Codex 上下文接手任务
- 02确认记录的修改是否实际生效
- 03在会话中断后继续未完成工作
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ daymade/ claude-code-skills --skill continue-codex-work安装后在 Claude Code 中输入/continue-codex-work确认已加载。
附带文件references/native-goal-reconciliation.md
详细介绍
继续 Codex 工作
继续意味着完成仍未履行的业务任务。阅读历史记录是强制性的证据阶段,而非交付成果。
入口条件:外部接手,而非原生恢复
| 当前情况 | 操作 |
|---|---|
| Codex 本身原生恢复了同一段对话,且恢复的轮次或压缩状态已在当前上下文中 | 不要调用此 Skill 或 read-codex-history。直接根据保留的上下文继续,然后在做出任何更改前核实当前工作区和外部状态。 |
| 新的/不同的 Agent 上下文必须接手先前的 Codex rollout,或者用户指出了另一个 Session ID,而该会话的连续性尚未保留在此处 | 使用此 Skill。步骤 1 中经过验证的历史回执仍为强制要求。 |
仅仅重启并不足以选择第二行。决定因素是当前对话是否为同一 Session 的宿主恢复后续,而不是 Codex 进程是否重启。
步骤 1:获取经过验证的 Codex 读取回执
针对准确的 Session ID 调用 daymade-claude-code:read-codex-history,并请求完整的按时间顺序排列的 Session 证据简报。如果 ID 未知,请先使用该 Skill 的清单或限定范围的搜索。
回执必须说明:
- 使用了哪些提示词账本、状态索引和 rollout 来源;
- 选定的
session_meta.id及其是否与请求的 ID 完全匹配; - 从根到子级的分叉沿袭关系及精确的继承字节边界;
- 选定和继承的、按时间顺序排列的用户/助手轮次;
- 已压缩的上下文、最新计划、结束原因、未解决的调用、文件和缺失项。
如果 rollout 不匹配、缺少子 rollout、物理副本不明确、缺少父项、字节边界断裂,或存在继续提示但无法恢复父级目标,则必须停止。绝不要从“最接近”的文件继续。
步骤 2:重建继续执行契约
在选择下一步行动或报告阶段完成之前,根据经过验证的读取回执和项目当前阶段的来源填写此内部契约。如果不存在项目阶段来源,则使用最新的人类请求。
| 字段 | 所需证据 |
|---|---|
| 原始业务成果 | 在继承和选定时间线中,仍然有效的最早人类请求 |
| 当前明确请求 | 最新的、并非仅为继续提示的人类请求 |
| 当前交付阶段/非目标 | 最新的人类更正,用以缩小当前要交付和要推迟的内容;不要将原始长期目标重新置于其上 |
| 已完成事项 | 独立的完成证据,而非 Agent 的叙述或助手的最终回复。将其绑定到工件/会话身份及输入条件;这些条件未变时可复用。重新读取易变的运行时和交付状态。 |
| 尚未履行事项 | 用户请求但没有完成证据的结果 |
| 用户更正/请勿重复 | 人类消息中否定某条路线、假设或输出的内容 |
| 已验证的资产和成功路线 | 现有代码、文档、Skills、输出、命令和先前成功的实验 |
| 下一项直接行动 | 一项能明显减少未完成业务成果的行动 |
如果子级上下文仅包含“继续”、“continue”或 /fork,则根据经过验证的父级快照继承任务。本地提示不能单独构成目标。
步骤 3:与当前实际情况核对
- 阅读当前目标项目的
AGENTS.md/CLAUDE.md。 - 确认当前工作目录、分支、工作树、相关文件和外部状态。
- 验证记录的补丁、提交、推送、下载、作业或 Agent 输出是否确实已生效;执行记录也会记录尝试过的操作。
- 在创建替代内容前,先找回并复用之前成功的成果。
- 对于用量限制或服务错误等暂时性故障,在重复工作前,确认原进程后来是否恢复并完成。对于现有的原生 Goal,请使用 原生 Goal 核对 区分未完成事项、运行时状态、受支持的恢复方式和已观察到的自动续行情况。在某个工具菜单中找不到恢复工具,并不能证明当前宿主没有恢复控制项。
- 检查会话中断时有哪些工作正在进行。前台长任务(远程诊断、下载、构建)会随会话结束而中止,其未持久化的输出也会随管道消失——执行记录只会表明任务已启动,不会记录结果。将这类结果视为尚未完成:探测远程进程或其输出文件是否仍然存在;重新运行前,为其设置一个分离的、将结果写入磁盘的通道(例如远程执行
( cmd > log 2>&1 </dev/null; echo $? > rc ) &,并通过 rc 文件轮询;如果目标环境支持,优先使用setsid/nohup,因为由 pty 支持的会话仍可能向裸子 shell 发送 SIGHUP),以免下一次中断再次带走结果。
步骤 4:执行业务任务
执行下一项直接操作并闭合其反馈环路。审查、Skill 工作、基础设施清理、格式润色和额外的安全机制,除非能直接解除原始结果的阻碍,或用户明确将其提升为优先事项,否则都应从属于原始任务。
每次进入重要分支前,先问:“如果这项操作成功,当前授权阶段中哪项尚未实现的结果会因此更接近完成?”若无法回答,这就不是延续原任务的工作。源、登录或提供商路线受阻,只会阻碍依赖它的工作;在宣告整个任务受阻前,先执行其他必要且已获授权的工作。
在用户实际使用结果的界面上验证结果:仅有可搜索的字节,并不能证明页面可读;生成了建议,也不能证明人工决策已保存。对于输入未变的情况,复用已通过的检查;只有出现新改动、故障或尚未解决的证据缺口时,才扩大验证范围。
不要运行 codex resume 或 codex --continue。不要覆盖无关改动。
步骤 5:根据约定报告
- 已恢复的目标:准确的 Session 沿袭关系和原始业务结果。
- 已执行:采取的操作及独立验证。
- 现已完成:实际已完成的约定条目。
- 剩余事项:尚未解决的条目及其具体阻碍。
- 未重复的操作:有意避免的相关无效路线。
恢复上下文、解析器成功、审查通过或子进程结束,本身都不代表延续任务成功。用户的业务结果才是完成单位。