recall

Recall

在开始或继续工作之前，先重建用户近期的工作上下文，并简明概述当前进展和下一步。

保持简洁，聚焦主题。只阅读范围内各个线程所需的内容，然后停止。

你的上下文保存在两份记录中。你自己的聊天记录记录了你做过什么、做了哪些决定。共享记录则记录了其他人围绕同一段代码所做的一切：用户反复报告的症状、已发布又被撤回的修复，以及生产环境中仍在出现的错误。why 技能会跨源代码管理、问题跟踪器、聊天和问题频道、长篇文档以及错误跟踪系统搜索这第二份记录。一个功能若积累了大量 Bug，其大部分来龙去脉都保存在那里，因此不要只靠自己的聊天记录来重建。

使用 pstack-harness 技能定位此工作区的聊天记录存储位置。在基于文件的存储中，每行都是一条聊天消息；数据库支持的存储会导出为相同格式。

1. 分类，然后分流。要继续某个特定的先前聊天，请使用 session-pickup 操作手册，而不是这个技能。若要将习惯转化为持久技能，请改用 automate-me 技能。用人类可读的方式总结工作是另一项任务。Recall 会在你采取行动前，从近期聊天中加载工作上下文。如果用户已经提供了完整的状态摘要（路径、分支、改动），就直接使用并跳过信息挖掘。
2. 搜索前锁定范围。明确时间窗口（“近期”是一个实际的范围，默认最近 7 天）、指定的主题（如有）以及工作区（默认为当前工作区。未经用户要求，绝不读取其他项目的聊天记录）。复述范围。绝不要擅自把“全部”改成“最近 N 天”。
3. 扩展搜索聊天记录。启动多个并行子 Agent，让它们各自按 how explorer 角色检查语料库。使用 pstack-harness 技能中“Spawn a role”一节确定该角色。告诉每个子 Agent 按实际修改时间（ls -t）而非 UUID 名称对候选项排序；先搜索主题，再只阅读匹配的聊天及相关部分；跳过当前聊天和明显的噪声（子 Agent、评估和测试聊天）。每个子 Agent 都要按相同格式返回结果，每个聊天一个区块，包含主题、用户目标、决定、未完成事项、困难和纠正，以及产物（PR、工单、分支），并引用聊天 UUID。若只有一两个聊天，就跳过并行分工，直接搜索。原始聊天记录保留在子 Agent 中。主线程只接收它们的发现。
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、聊天永久链接、错误跟踪问题），并在任何公开输出前清理私人信息。

**回复：**按上述规范撰写简报。