recall

回顾

在开始或恢复工作前，重建用户近期的工作上下文，并简洁地说明当前进展和下一步该做什么。

保持简洁，切题。只阅读相关线程所需的内容，然后停止。

你的上下文保存在两份记录中。你自己的聊天历史记录了你做过什么、做过哪些决定。共享记录则记录了其他人围绕同一代码所做的一切：用户反复报告的问题、已上线又被回退的修复，以及生产环境中仍在出现的错误。第二份记录是 why 技能的搜索对象，涵盖源代码管理、问题跟踪器、聊天和问题频道、长篇文档以及错误跟踪。一个功能如果遗留了许多错误，其大部分历史都保存在那里，所以不要只根据自己的聊天记录重建情况。

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

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

输出约定

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

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

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

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