用途
ds-context-reset 的核心做法是把工作状态存进文件而非聊天记录，使新的上下文能无漂移地继续任务。适用于任务跨会话、上下文过长或信息过时的长任务场景。
主要能力与使用方式
1. 建立进度文件
在长任务开始时，于仓库根目录创建 PROGRESS.md，包含以下部分：
- Goal：一到两句话说明目标，以及整个任务的验收检查。
- Done：已验证的步骤，每条附上证明它的命令和结果。
- Next：剩余步骤的有序列表，第一项即下一个确切动作。
- Open questions：等待用户决定的未知项与决策。
- Key facts：路径、命令、版本、易错点，以及失败过的方法（附原因）。
2. 更新与提交
每完成一个已验证步骤后更新 PROGRESS.md；未验证的步骤不更新。代码与 PROGRESS.md 一起提交，并使用描述性提交信息。
3. 识别重置信号
出现以下情况时应考虑重置：重复先前的回答、忘记 Key facts 中的事实、重试已失败的修复、同一文件被反复读取，或上下文占用超过约一半。
4. 执行重置
信号出现时，先完成或回滚当前步骤，使工作树处于已知状态；然后把 PROGRESS.md 重写为完整交接文档——仅有该文件和仓库的读者也应能继续，删除闲聊、保留事实。随后启动新会话或子代理，给它一条指令："Read PROGRESS.md and git log -5, run the acceptance check for the last Done item, then do the first item in Next." 在新上下文中，先确认基线检查通过再开始新编辑；若失败，先修复。
停止条件
- 目标的验收检查通过，且 PROGRESS.md 中所有项均为 Done。
- 同一 Next 项已重置 3 次仍无进展：停止并询问用户，以该文件作为报告。
规则与限制
- PROGRESS.md 保存事实与证据，而非无人验证的计划。
- 保持在约 150 行以内，旧 Done 项合并为简短摘要行。
- 绝不写入密钥或令牌。
- 新上下文读取文件，而非旧对话记录。
- 可与 ds-plan-loop 配合生成 Next 列表，与 ds-unstick 配合记录失败方法的笔记。
适用场景
适合跨越多个会话的长任务、需要保持状态一致性的开发工作，以及上下文接近饱和时需要交接继续的场景。具体支持的平台和安装方式暂未提供。