recall

回顾

以粗体或反引号标记的技能名称，或以 /<name> 形式运行的技能，对应于此技能目录旁的 ../<name>/SKILL.md 文件；不带前缀的原则名称对应于 ../principle-<name>/SKILL.md 文件。阅读该文件并遵循其中的指引。大多数 pstack 技能仅供用户使用，因此你的技能工具无法加载它们。每次 delegate_task 调用都遵循 ../poteto-mode/SKILL.md 的 Subagents 部分中的默认设置。

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

保持简洁、切题。只阅读当前范围内线程所需的内容，然后停止。

你的上下文保存在两份记录中。你自己的聊天记录保存了你做过的事和作出的决定。共享记录则保存了其他人围绕相同代码开展工作的所有情况：用户反复报告的问题、已发布又被撤回的修复，以及仍在生产环境中出现的错误。第二份记录正是 why 技能要搜索的内容，涵盖源代码管理、问题跟踪器、聊天和问题频道、长篇文档以及错误跟踪系统。一个功能若积累了大量历史缺陷，其大部分背景都记录在那里，因此不要只根据自己的对话记录重建情况。

本项目的聊天记录就是 T3 线程。t3_thread_list 按时间倒序列出线程（includeSubagents: true 会包含委派任务的子线程），t3_thread_search 可按文本查找线程，t3_thread_read 可按时间线读取线程（view: "activity" 会包含工具调用）。

1. 先分类，再路由。要恢复某个具体的过往聊天，应使用 session-pickup 操作指南，而不是此流程。要把习惯转化为可长期复用的技能，应使用 automate-me。以便于人阅读的方式总结工作，则是另一项任务。Recall 会在你采取行动前，加载近期聊天中的工作上下文。如果用户已经提供了完整的状态摘要（路径、分支、变更），就直接使用，无需挖掘。
2. 搜索前先锁定范围。明确时间窗口（“近期”是一个实际范围，默认最近 7 天）、指定的主题（如有）和工作区（默认当前工作区。未经请求，绝不读取其他项目的聊天记录）。向用户复述范围。绝不要悄悄把“全部”改成“最近 N 条”。
3. 全面检索聊天记录。针对这个项目翻页调用 t3_thread_list，直到超出时间窗口；排除当前聊天和明显的噪声（子 Agent、评测和测试聊天），再按 t3_thread_list 的顺序（依据真实的最近活动时间，绝不按 thread id）将其余 thread id 分成若干组。t3_thread_search 的结果范围有限，命中项只能作为线索，不能代表完整语料。使用 orchestrator_capabilities 中快速、低成本的模型，并行启动多个 delegate_task 子任务，每组一个；每个子任务的 title 要注明所属分组，任务说明中要明确列出 thread id。每份任务说明都要写明“只读：仅检查，不写入，不运行 git 命令”和“不要委派”，并要求子 Agent 对每个 thread id 调用 t3_thread_read，只保留与主题相关的聊天及相关片段；持续跟进 nextPosition，直至 hasMore 为 false；并使用 itemId 和 textOffset 获取被截断的条目。每个子任务都要按相同结构返回结果，每个聊天单独成块：主题、用户目标、决策、未解决事项、遇到的困难及修正，以及产物（PR、工单、分支），每项都注明 thread id。只有一两个聊天时，跳过并行分组，直接搜索。原始聊天记录保留在子 Agent 中。主线程只接收其调查结果。根据工作需要，参照 poteto-mode 技能的 Subagents 部分，为每个子 Agent 选择推理级别以及快速或标准速度。
4. 如果主题指向某项功能、文件、子系统、领域或 Bug，务必检索共享记录。这是默认要求，不由自行判断；“我在 X 上的工作”也不例外。交由 why 技能的资料调查员处理，但要将问题从“为什么要这样构建”调整为“当前状态如何、试过什么但未奏效，以及用户仍在反馈什么”。复用该技能针对各来源的操作指南，让调查员与聊天记录挖掘并行运行，并沿用其做法：每个来源安排一名调查员；无结果也属于调查发现；跳过无法使用的 MCP 并说明原因。将返回的结果纳入摘要。只有在不涉及具体目标的纯活动回忆（“我这周做了什么”）中，才跳过此步骤；此时，自己的历史记录和当前状态就是全部答案。
5. 对照当前状态核实。通过 git 和 gh 检查挖掘及共享记录调查中发现的 PR、分支和工单。如果答案取决于 Agent 实际做过什么（运行了哪些工具、读取了哪些文件、遇到了哪些错误），应使用 t3_thread_read 读取完整聊天，设置 view: "activity"，持续跟进 nextPosition 直至 hasMore 为 false，并使用 itemId 和 textOffset 获取被截断的条目；不要只看摘要。
6. 按照下方约定撰写摘要。按 thread 分组。只围绕指定主题。

输出约定

依次写出概述、线程状态、问题，再写下一步。更深入的细节放在下方，或直接删去。

• 概述。 最多 5 条要点。说明这项工作的内容及整体进展。
• 线程。 每个线程单独占一行，并且必须以且仅以一个状态标签开头：[merged #N]、[open PR #N]、[in flight <branch>]、[verified, uncommitted]、[reverted #N] 或 [planned, not started]。没有标签的线程就还没完成，请为其添加标签。
• 问题。 最多列出 5 个反复出现的问题。包括用户持续反馈的症状，以及已发布后又回滚的修复，让下一次尝试能从上次失败的地方继续。
• 下一步。 最有用的一项下一步行动，具体明确。

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

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