recall

Recall

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

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

你的上下文保存在两份记录中。你自己的聊天历史记录了你做过的事和作出的决定。共享记录则记录了围绕同一代码、以其他名称发生的一切：用户反复报告的问题、已发布后又回滚的修复，以及生产环境中仍在触发的错误。第二份记录正是 why 技能要搜索的内容，涵盖源代码管理、问题跟踪器、聊天和问题频道、长篇文档以及错误跟踪。一个功能如果积累了大量错误记录，其大部分来龙去脉都在这份记录里，所以不要只根据自己的对话记录来重建。

对话记录保存在你的运行环境存放它们的位置。每个文件都是 JSONL 格式。找到当前工作区对应的运行环境目录。如果你无法判断自己使用的是哪种运行环境，请检查当前工作区中以下哪些目录存在：

• Cursor： ~/.cursor/projects/<slug>/agent-transcripts/<uuid>/<uuid>.jsonl。<slug> 是移除开头斜杠，并将每个 "/" 替换为 "-" 后的工作区路径（/Users/you/proj 会变成 Users-you-proj）。
• Claude Code： ~/.claude/projects/<slug>/<session-id>.jsonl。<slug> 是将工作区路径中所有非字母或数字字符替换为 "-" 后的结果（/Users/you/proj 会变成 -Users-you-proj）。
• Pi： ~/.pi/agent/sessions/--<slug>--/<timestamp>_<id>.jsonl。<slug> 是移除开头斜杠，并将每个 "/" 替换为 "-" 后的工作区路径（--Users-you-proj--）。
• Codex： ~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl，文件不会按工作区分组。只保留首行中 payload.cwd 等于工作区路径的文件。
• OpenCode： ~/.local/share/opencode/storage/。会话是 session/<project-id>/ 下的 JSON 文件，其消息位于 message/ 和 part/ 下。

1. 先分类，再路由。要继续某段特定的过往对话，应使用 session-pickup 操作手册，而不是本流程。要把习惯转化为持久技能，应使用 automate-me。以便于人阅读的方式总结你的工作，是另一项任务。Recall 会在你采取行动前，从最近的对话中加载工作上下文。如果用户已经提供了完整的状态摘要（路径、分支、改动），就直接使用并跳过挖掘。
2. 搜索前先锁定范围。明确时间窗口（“最近”是一个确切范围，默认为过去 7 天）、指定的主题（如有）以及工作区（默认为当前工作区。未经请求，绝不读取其他项目的对话记录）。向用户复述范围。绝不悄悄把“全部”改成“最近 N 天”。
3. 并行检索聊天记录。使用快速、经济的模型启动并行子 Agent，让每个子 Agent 负责语料库的一部分。要求每个子 Agent 按实际修改时间排序候选项（ls -t），绝不按 UUID 名称排序；先搜索主题，然后只阅读匹配的聊天及其中相关片段，并跳过当前聊天和明显的噪声（子 Agent、评估和测试聊天）。每个子 Agent 都按相同的结构返回内容，每段聊天占一个区块：主题、用户目标、决策、未解决事项、遇到的困难及纠正，以及产物（PR、工单、分支），并为每项注明聊天 UUID。只有一两段聊天时，跳过并行检索，直接搜索。原始记录留在子 Agent 中。主线程只接收其发现。根据 poteto-mode 技能的“子 Agent”部分，为任务选择每个子 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、聊天永久链接、错误跟踪器问题）；向公众发布前，先清理私密上下文。

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