用途
long-session-check 用于评估或处理长会话中的上下文管理问题。其核心理念是：上下文窗口是工作台，不是仓库；压缩（compaction）解决的是“当前放不下”的问题，记忆（memory）解决的是“下次是否还记得”的问题，两者都是有损的。因此安全模式是尽早把重要内容沉淀到人类可读的文件中，并把压缩当作整理工作台，而不是唯一的安全网。
该技能是 MCode Engineering Notes 03《Keeping long sessions sharp》的配套材料，附带纯文本清单 checklists/long-session.md。
两种模式
技能提供两种模式，按请求选择对应的一种。
模式 A：处理当前所在的会话
第一步，把上下文中的内容分入三个类别：
- 丢弃：可以再次获取或已不再需要的内容，例如大文件读取、测试日志、搜索结果、已放弃的尝试。
- 摘要：仅限本会话的故事，例如当前进展、下一步、未解决的 bug 与线索、最近修改的文件。
- 写入文件：一旦丢失会造成损失、或后续会话仍需要的内容，例如决策及其理由、进度、待办事项、验收标准、长期有效的规则。
第三步类别应当立即写入项目的进度文档或设计文档，或通过 handoff-doc 写入。
第二步，选择下一步动作：
- 同一任务、只是历史过长：执行压缩，并说明接下来做什么、必须保留什么（例如“聚焦 auth 重构，丢弃测试调试部分”）。
- 新任务：开启新会话。
- 已压缩多次且出现漂移、重复询问已回答过的问题、或违反先前约束：编写交接文档，并基于该文档重新开始。
- 走错了方向：回退到出错之前，而不是压缩，以免错误尝试进入摘要。
模式 B：审查智能体的设计
阅读智能体的代码与配置，对每一项以证据作答（文件与行号、配置键或观察到的行为）：
- 是否在诉诸完整摘要之前先清理旧的工具结果？
- 清理结果时，工具调用与对应结果是否成对保留？许多模型 API 会拒绝孤立的调用。
- 关键决策与约束是否写入文件，而非仅保留在对话中？
- 手动压缩是否接受关于保留什么、接下来做什么的指令？
- 自动压缩是否触发得足够早，为输出和摘要本身留出空间？压缩失败（配额、更小的模型）时会话能否继续？
- 压缩请求能否复用提示缓存？压缩是否过于频繁以至于不断使缓存失效？
- 压缩是否只改变模型所见内容，而保持用户可见历史完整？是否不占用面向用户的预算（如步数限制）？
- 是否告知模型上下文由系统自动管理，以免它中途停下等待“下一轮继续”？
- 项目记忆（AGENTS.md 或类似文件）是否简短且仅限稳定规则？
- 记忆是否按范围区分（会话、项目、用户）？临时进度和待办是否排除在长期记忆之外？
- 记忆超出注入预算时，截断是否可见，最重要的规则是否保证加载？
- 人类能否打开、编辑和关闭记忆？必须强制执行的规则应放在 hooks 中，而非记忆里。
输出
- 模式 A：三个类别的内容、写入了哪个文件的什么内容，以及选定的下一步动作。
- 模式 B：各检查项及通过/失败/未知结论、证据，以及按优先级排序的首要修复建议。
适用场景与限制
适用于需要维护长对话质量的智能体开发与评审场景。资料未提供安装命令、收费信息或支持的平台范围，相关内容暂未提供。