recall

回顾

在开始或恢复工作之前，重建用户近期的工作上下文，并简要说明当前进展和接下来要做什么。

保持简洁，紧扣主题。只阅读当前范围内各个主题所需的内容，然后停止。

你的上下文存在两份记录中。你自己的聊天历史记录了你做过什么、做过哪些决定。共享记录则记录了围绕同一代码、以其他名称发生的一切：用户反复报告的症状、已发布又被撤回的修复，以及仍在生产环境中触发的错误。第二份记录正是 why 技能要搜索的内容，涵盖源代码管理、问题跟踪器、聊天和问题频道、长篇文档以及错误跟踪系统。某项功能如果遗留了大量 Bug，其大部分历史都在那里，所以不要只靠自己的聊天记录重建。

聊天记录位于 ~/.cursor/projects/<slug>/agent-transcripts/<uuid>/<uuid>.jsonl，其中 <slug> 是去掉开头斜杠，并将每个 "/" 替换为 "-" 后的工作区路径（因此 /Users/you/proj 会变成 Users-you-proj）。每一行都是一条聊天消息。

1. 先分类，再路由。要恢复某一段具体的先前聊天，应使用 session-pickup 操作手册，而不是本技能。将习惯转化为持久技能，应使用 automate-me。以人类可读的方式总结工作，是另一种任务。Recall 会在你采取行动前加载近期聊天中的工作上下文。如果用户已经提供了完整的状态摘要（路径、分支、改动），就直接使用并跳过挖掘。
2. 搜索前锁定范围。明确时间窗口（“近期”是一个实际范围，默认最近 7 天）、指定的主题以及工作区（默认为当前工作区。未经允许，绝不读取其他项目的聊天记录）。明确告知用户范围。绝不要悄悄把“全部”缩小为“最近 N 天”。
3. 并行挖掘聊天历史。派出多个子 Agent，使用快速、低成本的模型，各自负责语料库的一部分。指示每个子 Agent 按真实修改时间排序候选项（使用 ls -t），绝不要按 UUID 名称排序；先搜索主题，再只读取匹配的聊天及其中相关部分；跳过当前聊天和明显的噪声（子 Agent、评估和测试聊天）。每个子 Agent 都要对每条聊天按相同格式返回一个区块：主题、用户目标、决策、未解决事项、困难与修正，以及成果（PR、工单、分支），每项都要注明聊天 UUID。对于一两条聊天，跳过并行分发，直接搜索。原始聊天记录留在子 Agent 中，主线程只接收其发现。根据任务选择子 Agent 的推理级别和快速或标准速度，遵循 poteto-mode 技能的“Subagents”部分。
4. 只要主题提及某项功能、文件、子系统、领域或 Bug，就要检查共享记录。这是默认要求，不由你自行判断；“我在 X 上的工作”也不例外。交由 why 技能的来源调查员处理，但要把问题从“为什么会这样构建”调整为“当前状态如何、尝试过哪些但未奏效的方案、用户仍在报告什么”。复用其针对各来源的操作手册，与聊天历史挖掘并行运行调查员；遵循其原则：每个来源安排一名调查员，无结果本身也是发现；跳过不可用的 MCP 并说明情况。将调查结果纳入摘要。只有在纯粹回顾活动、没有指定目标（“我这周做了什么”）时才跳过此步骤，此时自己的历史记录和实时状态就是全部答案。
5. 对照实时状态进行核实。使用 git 和 gh 检查挖掘和调查中发现的 PR、分支和工单。如果答案取决于某个 Agent 实际做过什么（运行过哪些工具、读取过哪些文件、遇到过什么错误），就读取完整聊天记录，而不是精简后的本地副本。
6. 按以下规范撰写摘要。按主题分组。始终围绕指定主题。

输出约定

先写摘要，再写线程状态，然后写问题，最后写下一步。更深入的细节放在下面，或直接删掉。

• 摘要。 最多 5 个项目。说明这项工作是什么，以及整体进展如何。
• 线程。 每项占一行，并且必须以且仅以一个状态标签开头：[merged #N]、[open PR #N]、[in flight <branch>]、[verified, uncommitted]、[reverted #N] 或 [planned, not started]。没有标签的线程尚未完成，请添加标签。
• 问题。 最多 5 项，列出反复出现的问题。包括用户持续报告的症状，以及已发布后又回退的修复，让下一次尝试能从上次失败之处继续。
• 下一步。 最有价值的单一后续操作，具体说明。

除非相邻功能或工单会阻碍当前事项，否则不要提及。当摘要和线程行超出一屏时，应先删减细节，而不是删减线程。使用 unslop 技能撰写简报；引用聊天发现时注明 UUID，引用共享记录发现时注明其来源（PR #、工单 ID、聊天永久链接、错误跟踪器问题），并在任何公开输出前清理私人上下文。

回复： 按照上述约定撰写简报。