workflow_continuous_task_advancement
道-方法 · 道层 skill 全文
本页是 <code>rules/skills/drafts/workflow_continuous_task_advancement.md</code> 的逐字投影（仅隐私清洗，零改写）。
时点提示：本页是仓内文件 rules/skills/drafts/workflow_continuous_task_advancement.md 的逐字投影（仅做隐私清洗：仓库根绝对路径→相对路径、家目录→~/；除此零改写）。若源文件后续有修订，以仓内真源为准。
Skill：复杂任务持续推进
元数据
- 类型：Workflow / Draft
- 适用场景：active task / Controller closure / 用户授权补缺场景下，复杂任务已经超过一次线性执行，涉及多文件、多阶段、多 agent、审查、补齐、Hook / Skill 设计，或用户明确要求“继续闭环”“补齐缺口”“确认是否真的完成”。只读历史审查默认转
workflow_post_loop_critical_review或workflow_recursive_agent_review。 - 输出位置：正式复盘和重要发现放
contexts/survey_sessions/；任务产物放对应业务目录；方法沉淀放rules/skills/drafts/。 - 创建日期：2026-05-11
- 来源：2026-05-10 到 2026-05-11 对三个 Codex 审查 Claude Code session 的复盘。
- 当前定位：Controller closure / advancement guard draft。它提供 claim ledger、证据等级和补缺检查，不作为独立 root Loop。
目标
这个 skill 的目标是让 agent 在复杂任务中持续推进到可验收状态，而不是完成一轮分析、一轮实现或一轮自评后就停止。成功状态不是“agent 说完成”，而是用户需求被还原、完成声明被验证、缺口被补齐或明确挂起、证据落盘、验收边界清楚。
如果任务已经进入 workflow_controller_loop，本文件只作为 review/closure guard 使用：帮助 Controller 检查完成声明、补缺和过度声称。它不拥有 runtime、scheduler、聊天记录检索或外部审查流程。
触发条件
出现以下任一情况时使用：
前提：当前任务仍在推进，或用户明确授权发现缺口后直接补齐。若用户只要求冻结历史结果并判断可信度，转 post-loop / recursive review。
- 用户要求检查一个 Claude Code / Codex / OpenCode session 是否真的完成。
- 用户指出“不要只看它自己声称完成”“先提取我的 prompt”“基于纠正后的内容继续闭环”。
- 任务涉及多个文件、多个目录、多个 agent、多个阶段或大 context 记录。
- 已有 report / PROGRESS / HANDOFF / TODO 声称完成，但仍存在
PARTIAL、NOT_READY、open item 或截断记录。 - 用户要求发现缺口后直接补齐，而不是只写审查报告。
- 用户要求总结复杂任务 prompt、sub-agent 使用、Hook 或注入方案。
边界
本 skill 是持续推进控制层，不替代具体领域 skill。
不要用它自动做这些事：
- 不自动 commit、merge、打 tag 或安装真实 Hook。
- 不把简单问题升级成多 agent loop。
- 不用 sub-agent 数量证明质量。
- 不把 final answer、recap、
PASS字样或文件存在当成充分证据。 - 不把抽查写成全量验证。
- 不让 sub-agent 做最终裁决；最终取舍、写作和质量把关由主 agent 完成。
涉及文件操作、调研或 workflow 时，仍先查 rules/skills/INDEX.md。工具路径按名查 tools/INDEX.md，不要在长期 skill 中硬编码工具路径。
核心输出
复杂任务最终应至少留下这些信息：
- 用户原始需求和后续纠偏。
- 执行 agent 的完成声明 claim ledger。
- 每条 claim 的证据等级：
self-report、artifact exists、source-linked、verified、independently reviewed、committed。 - 缺口和补齐动作矩阵：
需求 -> 原缺口 -> 补齐动作 -> 当前状态。 - sub-agent 分工与主 agent 裁决。
- 可验收边界和不能过度声称的边界。
- 重要发现落盘路径。
提示词编写协议
给 agent 的 root prompt 应明确这些约束：
- 先从原始聊天记录或用户 prompt 还原需求，不从 final answer 或 recap 倒推需求。
- 把完成声明拆成可验证 claim，逐条找原始记录、产物文件、diff、测试、日志或 source path。
- 审查过程行为：任务分派是否合理、sub-agent 是否独立、工具输出是否截断、截断后是否补救、结果是否被主 agent 整合。
- 发现可补缺口时直接补齐；不可补时写 blocker、已尝试动作和下一步。
- 大 context 或多维判断必须使用 sub-agent、新 session 或等价独立复核。
- 最终输出必须写明哪些可验收、哪些不能声称完成。
可复用骨架：
请审查 <target> 是否真正满足我在原 session 中提出的需求。
要求：
1. 从原始聊天记录提取我的需求和后续纠偏，形成需求清单。
2. 把执行 agent 的完成声明拆成 claim，逐条用原始记录、产物、diff、测试或日志验证。
3. 审查过程行为：任务分派、sub-agent prompt、工具调用、截断处理、补救动作和产物整合。
4. 如果发现缺口，能补则补；补完后写清“需求 -> 原缺口 -> 补齐动作 -> 当前状态”。
5. 使用 sub-agent 或新 session 做独立复核；主 agent 负责冲突裁决和最终写作。
6. 最终区分可验收范围、不能过度声称范围、证据路径和后续事项。Sub-agent 隔离协议
Sub-agent 的价值来自信息隔离和交叉验证，不来自数量。
每个 sub-agent prompt 必须包含：
- 任务背景：为什么做、被审对象是什么、用户真正关心什么。
- 负责范围：只查需求、只查行为、只查产物、只查验证、只查版本边界等。
- 禁止越界：不修改文件，或只写指定文件；不基于 final answer 下结论；不把抽样外推。
- 输出格式：必须给 source path、line anchor、命令或产物路径。
- 验收标准：什么证据能支撑 PASS / PARTIAL / NOT_READY。
推荐分工：
| 角色 | 适用问题 |
|---|---|
| 需求审查员 | 用户原始需求、纠偏点、成功标准是否被还原。 |
| 行为审查员 | agent 是否正确分派任务、处理截断、整合 sub-agent。 |
| 产物审查员 | 文件、diff、report、catalog、workpad 是否真实存在且内容匹配需求。 |
| 验证审查员 | 测试、抽查、交叉审查、source path 是否能支撑结论。 |
| 边界审查员 | 落盘、tracked、staged、committed、deployed 等状态是否被混淆。 |
主 agent 必须抽查高风险 sub-agent 结论。多个 sub-agent 有分歧时，回源文件裁决，不投票。
持续推进控制
每轮结束前检查：
- 需求是否已经还原为可检查条目。
- 完成声明是否逐条验证。
- 证据是否足够支撑当前 verdict。
- 是否存在可补缺口；如果有，是否已补。
- 补齐后报告是否同步更新，避免旧
PARTIAL或旧数字残留。 - 是否仍有开放项；如果有，是否写成明确后续工程任务，而不是伪装成完成。
允许停止的条件只有三类：
- 验收标准全部满足，并且边界写清。
- 存在 blocker，已写明原因、尝试过的动作和下一步。
- 用户明确暂停或只要求报告，不要求继续补齐。
Hook / 注入草案
现阶段优先使用 advisory injection，不实现真实 Hook。
触发信号：
- 用户 prompt 命中“检查是否完成”“验收”“审查完成声明”“补齐”“不要只信 recap/final answer”“sub-agent / Codex 子进程”等。
- 任务涉及多个 session、多个产物、多个 agent 或大 context 截断。
- final answer 准备声称完成，但缺少需求矩阵、证据路径、验证记录或未完成边界。
- 现有
PROGRESS、HANDOFF、report 或 TODO 中还有PARTIAL、NOT_READY、open item。
注入内容应短：
复杂任务持续推进检查：
- 是否还原用户原始需求和后续纠偏？
- 是否把完成声明拆成可验证 claim？
- 是否读取实际产物/日志/diff/test，而不是只信 final answer？
- 大 context / 截断是否已分段读取或用 sub-agent 补救？
- sub-agent 输出是否有 source path / line anchor，主 agent 是否抽查？
- 发现缺口后是否已补齐，或写明 blocker？
- 最终是否区分可验收范围与不能过度声称范围？未来若实现 Hook，优先选择轻量提醒或 Stop 前检查，不让 Hook 自动继续执行长任务、自动修改文件、自动 commit 或自动安装其他 Hook。
裁决
使用分层 verdict，避免把边界抹平：
PASS：需求满足，证据足够，边界内无重要开放项。PASS_WITH_NOTES：主体可验收，但存在 commit/deploy/full-review 等边界不能过度声称。PARTIAL：主体有进展，但用户当前需求仍有未补缺口。NOT_READY：产物缺失、证据不足或 claim 与事实冲突。NEEDS_MORE_EVIDENCE：源记录缺失或关键证据不可访问，不能裁决。
常见分层：
artifact exists不等于verified。verified by sample不等于全量验证。file written不等于tracked / committed.fixture pass不等于live hook deployed.research delivery closed不等于engineering implementation deployed.
已知失败模式
1. 一轮浅扫后声称完成
表现：读了 report、看到 PASS、列了目录，就回答“完成”。
处理：回到原始需求和实际产物；至少建立 claim ledger。
2. Sub-agent 自报被当成验证
表现：执行 agent 自己说修完，被主 agent 写成独立审查者通过。
处理：降级为 self-report；只有 fresh 审查者或可复验测试才算更高证据。
3. 抽查外推为全量验证
表现：3/12 抽查通过，被写成 12/12 全量验证。
处理：报告中保留抽样范围和不可外推边界。
4. Review 不转 Repair
表现：发现缺口后只写报告，用户还要再催“把它补齐”。
处理：root prompt 明确授权能补则补；补后更新报告。
5. 旧错误拖住新验收
表现：用户已纠正早期方向，agent 继续围绕旧错误审查。
处理：建立纠偏时间线；当前验收以最新纠偏后的需求为准，旧错误只作为过程教训。
6. 落盘、入库、部署混淆
表现：文件在工作区存在，却说已入库；fixture pass，却说 live hook 已部署。
处理：把状态拆开写，分别验证 file exists、tracked、staged、committed、deployed。
验收标准
使用本 skill 后，任务完成必须满足：
- 有用户需求清单，且来源不是执行者 final answer。
- 有 completion claim ledger 或等价矩阵。
- 每个关键结论都有 source path、line anchor、命令或产物路径。
- 大 context / 多 session / 用户明确要求时，至少有一个 sub-agent 或新 session 独立复核。
- 发现可补缺口时已经补齐；未补的必须写成 blocker 或明确后续任务。
- 最终结论有可验收范围和不能过度声称范围。
- 重要发现已写入文件，而不是只留在对话中。