mcpField
L
long-task-continuation

long-task-continuation

github.com/ganyuanranAgent 工作流1.4k49 次安装4 天前更新
代码仓库

关于 long-task-continuation

用于可能跨阶段、会话或交接的长期工作的连续性协议,帮助 Agent 和开发者保存检查点、核实继承状态并发现范围或基线偏移;它不执行计划,也不授予完成权限。

主要功能

  1. 01选择内联或持久检查点
  2. 02跟踪意图、待办与证据
  3. 03恢复时核对工作区与声明
  4. 04判断范围和基线偏移
  5. 05指导重试与交接状态记录

适用场景

  1. 01会话压缩后继续工作
  2. 02交接多阶段任务
  3. 03跟踪子 Agent 主导工作的进度

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/ganyuanran/aegis --skill long-task-continuation

安装后在 Claude Code 中输入/long-task-continuation确认已加载。

附带文件durable-work-guidance.md

详细介绍

长任务延续

概述

通过检查点让长时间运行的工作保持可恢复、可续接、能感知偏差,并受证据门控。本协议不执行计划、不分派子 Agent、不运行测试,也不授予完成权限。

权限边界

本方法包仅负责延续纪律。它不负责父计划、宿主的重试/看门狗行为、权威的 GateDecision、证据是否充分、需求验收或任务完成。

适用场景

当工作包含有意义的阶段、可能需要压缩/恢复或交接、使用子 Agent,或明确需要连续性和偏差控制时,使用此技能。架构、契约、共享工作流和验证门控变更也适用。不要将其强加给简短回答或单条命令检查。

恰好选择一种状态载体:

  • 在此延续工作流中,对于中等/高复杂度工作,或任何实际跨会话、需要交接或要求可恢复状态的复杂度工作,使用持久化的 work/ 记录;
  • 其他情况保留一个内联检查点。

多步骤、由待办事项驱动、可能发生上下文压缩以及使用子 Agent,本身并不足以要求低复杂度工作创建持久化记录。不要同时创建两种载体,也不要为每个切片创建一条记录。

必需产物

持久化任务在 docs/aegis/work/YYYY-MM-DD-<slug>/ 下保留一条流程轨迹。它包含逻辑意图/基线状态、最新待办/检查点/恢复状态、终结证据/偏差状态,以及适用时的完成回顾。这些是 TaskIntentDraft、BaselineReadSetHint、BaselineUsageDraft、ImpactStatementDraft、TodoCheckpointDraft、ResumeStateHint、DriftCheckDraft 和 EvidenceBundleDraft 视图,而非权威运行时记录或独立的计划所有者。

只阅读与生命周期匹配的 durable-work-guidance.md 部分:

  • 新建持久化工作记录时,阅读 ## Required Artifact Layout 和 ## Create A Durable Work Record;
  • 现有的、由辅助工具支持的记录需要更新附属文件时,阅读 ## Update A Slice;
  • 记录重试/尝试情况时,阅读 ## Retry Convergence Detail;
  • 准备暂停、交接或完成材料包时,阅读 ## Pause, Handoff, And Completion Bundle;以及
  • 仅当自然语言检查点内容含糊不清时,才阅读 ## Expanded State Fields。

参考文档负责产物布局和 <aegis-workspace-helper> 命令细节;本文负责载体选择、恢复顺序、偏差决策和停止条件。

Execution Readiness View 可记录在意图或当前检查点中,适用于中等/高复杂度、容易交接、长时间运行、由子 Agent 驱动,以及涉及架构、契约、兼容性或退役敏感的工作。它呈现已有的意图、范围、基线、负责人、测试、审查和偏差约束;它不是新的 JSON 产物,也不授予完成权限。

无计划切片通道:

  • 当现有父计划/规范负责有界任务时,复用该计划和当前检查点。对于没有父级、直接且有界的请求,如果无需创建新持久化记录且验证边界明确,则使用内联检查点。
  • 编写一张精简的 Slice Card:目标、Parent plan/spec(或 none — direct bounded request)、文件、边界、验证和停止条件。
  • 切片目标只关闭该切片。最终完成时,通过 verification-before-completion 返回父计划或直接有界请求。
  • 不要仅为给微型切片指定父级而创建计划/规范,也不要为每个切片创建计划/规范或工作记录。
  • 若出现新的负责人、契约、架构、公开 API、架构设计、迁移、持久化、安全/权限、分发/发布界面、含糊的验证边界,或与父级范围或验收要求不一致的情况,则升级处理。

当工作涉及持久化架构决策时,这些工作记录是 ADR 自动回填的首选来源。保留决策信号、来源引用、备选方案、兼容性、退役、偏差和基线同步问题。

启动协议

执行前:

  1. 记录请求的结果、范围、非目标、风险、父计划/目标、成功证据和停止状态(done | blocked | needs-verification | scope-exceeded)。
  2. 确定所需的基线引用,并记录已确认、已引用和缺失的引用。缺少权威依据时,暂停并进入 needs-baseline-readback。
  3. 只选择一次内联状态或持久状态,然后记录待办映射、当前切片、已完成切片/证据、阻碍项、下一步以及当前分支/HEAD。
  4. 如果存在 Execution Readiness View,保留其中的意图锁定、范围边界、基线锁定、兼容性/退役边界、测试、审查、证据和回退规则。
  5. 对于由辅助工具支持的新记录,使用 durable-work-guidance.md 创建记录,并在实施前进行结构检查。

重试收敛协议

验证失败属于当前切片中的又一次尝试,不是新切片。不要将失败尝试的遥测信息纳入最终证据或常规提交。只有 evidence-finalized、blocked 或 abandoned 才是终止状态。当重试状态达到 process-artifact-pressure 时,停止自动重试,并转交给 systematic-debugging 或 verification-before-completion。只有在需要尝试/证据命令或旁置文件规则时,才加载持久参考资料。

分片协议

每个切片开始前,说明当前目标/待办、计划编辑内容、明确不编辑的内容、验证方式以及与就绪状态的对齐情况。对于有范围界定的父计划切片或无父计划切片,使用精简版 Slice Card,而不是新建计划/规格说明。

每个切片完成后,更新已完成的待办、证据引用、新使用的基线引用、阻碍项、下一步和偏移决策。当存在由辅助工具支持的活动工作记录时,阅读 durable-work-guidance.md 并更新同一条记录;不要为了记账而创建另一个工作流。

触发补丁形态/影响范围分诊、H 类发现或有范围界定的兼容性缓解措施后,局部测试通过并不意味着问题方向已经解决。保留 PatchShape、CanonicalOwner、UpwardDrillSignal、最新结果和一条有范围界定的证据引用;不要复制原始日志或完整差异。如果没有新的证据,状态应为 needs-verification 或 partial。对于修复或优化,在同一检查点中保留因果范围、证据引用、可能改变解决方案的未解决影响因素以及验证覆盖情况。压缩信息时,不得将单一已确认原因写成完整的根因结论,也不得抹去反证;恢复保留的更改前,重新检查这些未知因素。不要添加并行的因果记录。

恢复协议

按以下顺序恢复:

  1. 阅读原始意图、父级计划/目标、最新检查点和恢复提示。 对照当前用户指令进行协调:继续、修订、暂停或替换。保留尚未完成的交付内容;在将有效修订视为偏离之前,先更新获授权的范围。内部里程碑不能替代交付给用户的结果。
  2. 重新阅读必需的基线引用和相关的有效 CONTEXT.md 内容。
  3. 如有 Execution Readiness View,请阅读。
  4. 将检查点中的分支/HEAD、已完成的提交、证据引用和声明与当前工作树进行比较。 在工作树确认之前,将继承的完成声明视为未经验证。更正检查点中的矛盾,在最终报告中披露,不要将过时声明重新发布为当前状态。保留声明的对象、范围和恢复时状态;将其与后续修复以及无法验证的历史执行区分开来。一项准确的更正可以涵盖相关声明。记录必须采纳该更正,其他地方不得否认该更正,也不得将其归到其他范围。审核者的分类可以提出异议:如果检查证据后仍存在重大分歧,则保留 needs-verification,不要强求认可。如果证据已解决分歧,则保留有依据的结论并正常验证。
  5. 将当前切片与意图锁定、范围边界、基线锁定、兼容性/退役边界、测试、审核和非目标进行比较。
  6. 重新执行偏离判定,然后指出获授权的下一项最小操作。

计划、检查点、基线、上下文、就绪视图或工作树之间的任何分歧都会暂停执行。语义冲突应转交至 establishing-project-context;未计划的修复应重新读取保留的不变量、所有者边界、补丁形态和因果拓扑,然后将路由比较转交至 systematic-debugging。仅出现新的载体名称并不能证明方向改变。切勿仅凭记忆恢复。

偏离检查

检查原始意图和停止条件、父级范围/验收标准、兼容性、新所有者/回退方案/适配器/分支、退役、证据时效性以及任何就绪锁定状态。允许的判定为 continue、pause-for-user、needs-baseline-readback、needs-verification 和 blocked。

切勿输出 gate-passed、completion-granted 或 authoritatively-safe。

完成候选流程

在声明完成之前:

  1. 使用 aegis:verification-before-completion。
  2. 确认每项待办均有状态、阻塞项已解决或明确标记为外部依赖、证据涵盖验收标准,且偏离状态不构成阻塞。
  3. 如果存在持久记录,加载 durable-work-guidance.md,以获取完成材料包和工作区结构检查要求。
  4. 对于持久架构工作,将工作记录、证明材料包和 ADR 信号提交验证,以进行 ADR Backfill Check。

生成的材料包仅供未来运行时使用。Method Pack 的输出仍是经过验证的证据和建议性判断,不代表权威完成结论。

最简报告格式

自然地报告并省略空结构。确保以下语义槽位清晰可见:Aegis Visibility;当前待办/进行中/已完成/下一步;基线使用判定;存在时的就绪状态;最新证据;恢复后记录夸大状态时对继承声明的更正;相关时的重试/收敛状态;偏离判定;风险/未知项;以及下一项最小安全操作。

评论

支持 Markdown