ds-context-reset

ds-context-reset

将工作状态保存到文件中，而不是聊天记录中，这样新的上下文就能无偏差地继续工作。

步骤

1. 开始一项长期任务时，在仓库根目录创建 PROGRESS.md，并包含以下部分：
   • 目标：用一到两句话说明目标，并给出整个任务的验收检查。
   • 已完成：已验证的步骤，每项都要包含证明其结果的命令和结果。
   • 下一步：按顺序列出剩余步骤。第一项必须是确切的下一步操作。
   • 待确认问题：未知事项和需要等待用户决定的事项。
   • 关键信息：路径、命令、版本、注意事项，以及失败的方法（附原因）。
2. 每完成一个已验证的步骤，就更新 PROGRESS.md。未经验证的步骤不要更新。使用描述性提交信息，将代码和 PROGRESS.md 一起提交。
3. 留意重置信号：重复先前的回答、忘记「关键信息」中已有的事实、重试失败的修复方案、反复读取同一个文件，或上下文使用量超过约一半。
4. 出现信号时，完成或回滚当前步骤，使工作树处于已知状态。
5. 将 PROGRESS.md 重写为完整的交接文档。只看此文件和仓库的读者必须能够继续工作。删除无关内容，只保留事实。
6. 开始一个新的会话或子 Agent，并只给它一条指令：「读取 PROGRESS.md 和 git log -5，运行最后一项「已完成」的验收检查，然后执行「下一步」中的第一项。」
7. 在新上下文中，先确认基线检查通过，再进行新的修改。如果检查未通过，先修复问题。

停止条件

• 目标的验收检查通过，且 PROGRESS.md 中的所有事项都已标记为「已完成」。
• 对同一项「下一步」重置 3 次仍无进展。此时停止并询问用户，并将该文件作为报告。

规则

• PROGRESS.md 用于记录事实和证据，而不是未经验证的计划。
• 文件长度控制在约 150 行以内。较早的「已完成」事项合并为一条简短摘要。
• 切勿在其中写入机密或令牌。
• 新上下文应读取该文件，而不是旧的聊天记录。
• 将其与 ds-plan-loop 搭配使用来维护「下一步」列表，并与 ds-unstick 搭配使用来记录失败方案。