Back to Details

ds-context-reset

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

ds-context-reset

ds-context-reset

Store the state of the work in a file, not in the chat, so a fresh context can continue without drift.
将工作状态存储在文件中，而不是聊天记录里，以便新的上下文能够继续推进而不发生偏离。

Steps

步骤

  1. At the start of a long task, create PROGRESS.md at the repo root with these sections:
    • Goal: one or two sentences, plus the acceptance check for the whole task.
    • Done: the verified steps, each with the command and result that proved it.
    • Next: the ordered steps that remain. The first item is the exact next action.
    • Open questions: unknowns and decisions that wait for the user.
    • Key facts: paths, commands, versions, gotchas, and approaches that failed (with the reason).
  2. Update PROGRESS.md after every verified step. Do not update it for unverified ones. Commit the code and PROGRESS.md together with a descriptive message.
  3. Watch for reset signals: you repeat an earlier answer, you forget a fact that is in Key facts, you retry a fix that failed, the same file gets reread many times, or the context is more than about half full.
  4. When a signal appears, finish or revert the current step so the tree is in a known state.
  5. Rewrite PROGRESS.md as a complete handoff. A reader who has only this file and the repo must be able to continue. Remove chatter and keep the facts.
  6. Start a fresh session or subagent. Give it one instruction: "Read PROGRESS.md and 
    git log -5
    , run the acceptance check for the last Done item, then do the first item in Next."
  7. In the new context, confirm that the baseline check passes before you make new edits. If it fails, fix that first.
  1. 在长任务开始时，在仓库根目录创建 PROGRESS.md，并包含以下部分：
    • 目标：用一两句话描述目标，并附上整个任务的验收检查。
    • 已完成：经过验证的步骤，每一步都记录用于证明其结果的命令和结果。
    • 下一步：按顺序列出尚未完成的步骤。第一项必须是准确的下一步操作。
    • 待解决问题：尚未明确的未知事项，以及需要等待用户决策的问题。
    • 关键事实：路径、命令、版本、注意事项，以及失败的尝试方案（包含失败原因）。
  2. 每完成一个经过验证的步骤，就更新 PROGRESS.md。不要记录未经验证的步骤。将代码和 PROGRESS.md 一起提交，并使用描述性提交信息。
  3. 留意重置信号：你重复了之前的回答、忘记了“关键事实”中记录的信息、重试了曾经失败的修复方案、反复读取同一个文件，或者上下文使用量已超过约一半。
  4. 出现重置信号时，完成或回滚当前步骤，使工作区处于已知状态。
  5. 将 PROGRESS.md 重写为一份完整的交接文档。任何仅阅读该文件和仓库的人，都应该能够继续工作。删除闲聊内容，只保留事实。
  6. 启动一个全新的会话或子 Agent，并且只给它一条指令：“读取 PROGRESS.md 和 
    git log -5
    ，运行最后一个‘已完成’项的验收检查，然后执行‘下一步’中的第一项。”
  7. 在新上下文中，确认基线检查通过后再进行任何新编辑。如果检查失败，应先修复该问题。

Stop when

停止条件

  • The goal's acceptance check passes and PROGRESS.md shows every item as Done.
  • You have done 3 resets on one Next item without progress. Stop and ask the user, with the file as your report.
  • 目标的验收检查通过，并且 PROGRESS.md 显示所有项目均已标为“已完成”。
  • 对“下一步”中的同一个项目已经进行了 3 次重置，但仍未取得进展。此时停止并询问用户，以该文件作为报告。

Rules

规则

  • PROGRESS.md holds facts and evidence, not plans that nobody has checked.
  • Keep it under about 150 lines. Move old Done items into a short summary line.
  • Never put secrets or tokens in it.
  • The fresh context reads the file, not the old transcript.
  • Pair with ds-plan-loop for the Next list and with ds-unstick for the failed-approach notes.
  • PROGRESS.md 记录事实和证据，而不是未经检查的计划。
  • 将文件长度控制在约 150 行以内。将较早的“已完成”项合并为一行简短摘要。
  • 绝不在其中存放密钥或令牌。
  • 新的上下文读取该文件，而不是旧的对话记录。
  • 将其与 ds-plan-loop 配合使用以维护“下一步”列表，并与 ds-unstick 配合使用以记录失败方案的说明。