recall

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Recall

回忆

Before you start or resume work, you rebuild the user's recent working context and hand back a tight capsule of where things stand now and what to do next. Use for "recall my work on X", "catch me up", "what have I been working on", or "where did I leave off".

Keep it tight and on-topic. Read only what the in-scope threads need, then stop. The heavy reading fans out to parallel subagents. The main thread keeps only their findings and the final brief.

Your context lives in two records. Your own chat history holds what you did and decided. The shared record holds everything that happened around the same code under other names: the symptoms users keep reporting, the fixes that shipped and got reverted, the errors still firing in prod. That second record is what the why skill searches, across source control, the issue tracker, chat and issue channels, long-form docs, and error tracking. A feature with a long bug tail keeps most of its story there, so don't reconstruct it from your transcripts alone.

Transcripts live at

~/.cursor/projects/<slug>/agent-transcripts/<uuid>/<uuid>.jsonl

, where

<slug>

is the workspace path with the leading slash dropped and each "/" turned into "-" (so

/Users/you/proj

becomes

Users-you-proj

). Every line is one chat message.

Classify, then route. One specific prior chat to resume is the
```
session-pickup
```
playbook, not this. Turning habits into a durable skill is
```
automate-me
```
. A human-readable summary of your work is a different task. Recall loads working context across recent chats before you act. If the user already gave you a full state capsule (paths, branch, the change), use it and skip the mining.
Lock the scope before searching. Pin the window ("recent" is a real range, default the last 7 days), the topic if named, and the workspace (default the active one; never read another project's transcripts without being asked). State the scope back. Never quietly turn "all" into "recent N".
Fan out across your chat history. Spawn parallel subagents on a fast, cheap model, each taking a slice of the corpus, since searching transcripts is grunt work. Tell every subagent to order candidates by real modification time (
```
ls -t
```
) and never by UUID name, grep the topic first and then read only the matching chats and only their relevant regions, and skip the current chat plus obvious noise (subagent, eval, and test chats). Each returns the same schema, one block per chat: topic, the user's goal, decisions, open threads, struggles and corrections, and artifacts (PRs, tickets, branches), each citing the chat UUID. For one or two chats, skip the fan-out and search directly. The raw transcripts stay in the subagents. The main thread gets only their findings.
Sweep the shared record whenever the topic names a feature, file, subsystem, area, or bug. This is the default, not a judgment call, and "my work on X" does not exempt it. A named target carries history you never see in your own transcripts, and that history is the point of the sweep. Hand it to the why skill's source investigators, but steer their question from "why was this built this way" to "what's the current state, what's been tried and didn't hold, and what are users still reporting". Reuse its per-source playbooks so you don't reinvent each query vocabulary, run the investigators in parallel with the chat-history mining, and inherit its posture: one investigator per source, null results are findings, skip an unavailable MCP and say so. Fold what comes back into the brief. Skip this step only for pure activity recall with no named target ("what did I do this week"), where your own history and live state are the entire answer.
Verify against live state. A transcript or a stale ticket is history, not current truth, so take the PRs, branches, and tickets that the mining and the sweep surfaced and check them with
```
git
```
and
```
gh
```
. When the answer hinges on what an agent actually did (the tools it ran, files it read, errors it hit), read the full transcript, not just a trimmed local copy.
Write the brief to the contract below. Group by thread. Stay on the named topic.

在你开始或恢复工作前，重建用户近期的工作上下文，并返回一份简洁的简报，说明当前进展以及下一步行动。 适用于“回忆我在X项目上的工作内容”、“帮我了解最新进展”、“我之前一直在做什么”或“我上次做到哪儿了”这类场景。

内容务必简洁且紧扣主题。仅阅读相关线程所需的内容，然后停止。繁重的阅读工作由并行子代理（subagents）完成。主线程仅保留它们的发现结果和最终简报。

你的上下文存储在两类记录中。你自己的聊天历史记录了你所做的操作和决策。共享记录则包含了同一代码在其他场景下发生的所有事件：用户持续反馈的问题症状、已上线又被回滚的修复方案、生产环境中仍在触发的错误。第二类记录正是why技能的搜索范围，涵盖版本控制系统、问题追踪系统、聊天和议题频道、长篇文档以及错误追踪工具。一个存在长期bug的功能，其大部分相关信息都存储在共享记录中，因此不能仅从你的对话记录中重建上下文。

对话记录的存储路径为

~/.cursor/projects/<slug>/agent-transcripts/<uuid>/<uuid>.jsonl

，其中

<slug>

是去掉开头斜杠并将每个 "/" 替换为 "-" 的工作区路径（例如

/Users/you/proj

会变为

Users-you-proj

）。每一行代表一条聊天消息。

分类并路由。如果是要恢复某一特定的过往聊天会话，应使用
```
session-pickup
```
剧本，而非本技能。将习惯转化为持久技能的场景对应
```
automate-me
```
。生成工作内容的人类可读摘要则是另一项任务。“回忆”技能会在执行操作前加载近期聊天中的工作上下文。如果用户已经提供了完整的状态信息（路径、分支、变更内容），则直接使用该信息，跳过挖掘步骤。
搜索前锁定范围。明确时间窗口（“近期”指具体的时间范围，默认过去7天）、指定的主题（如有）以及工作区（默认当前激活的工作区；未经请求绝不要读取其他项目的对话记录）。将范围告知用户。绝不能悄悄将“全部”默认改为“近期N条”。
遍历你的聊天历史。使用快速、低成本的模型生成并行子代理，每个子代理处理一部分对话记录，因为搜索对话记录是重复性工作。告知每个子代理按实际修改时间排序候选记录（
```
ls -t
```
），而非按UUID名称排序；先筛选主题相关内容，仅阅读匹配的聊天记录及其相关部分；跳过当前聊天以及明显的噪音内容（子代理、评估、测试类聊天）。每个子代理返回相同的结构，每条聊天记录对应一个模块：主题、用户目标、决策、未完成线程、遇到的问题及修正、产物（PR、工单、分支），每个部分需注明聊天UUID。如果只有1-2条聊天记录，无需生成子代理，直接搜索即可。原始对话记录保留在子代理中，主线程仅接收它们的发现结果。
当主题涉及某个功能、文件、子系统、领域或bug时，务必扫描共享记录。这是默认操作，而非主观判断；即使是“我在X上的工作”也不例外。指定的目标对象存在你在自身对话记录中看不到的历史信息，而这些历史正是扫描的重点。将该任务交给why技能的源调查模块，但要将问题从“为什么要这样构建”调整为“当前状态如何、哪些尝试过的方案未能持久、用户仍在反馈哪些问题”。复用其针对各数据源的剧本，无需重新设计查询规则；与聊天历史挖掘并行运行调查模块；遵循其工作模式：每个数据源对应一个调查模块，无结果也是一种发现；跳过不可用的MCP并告知用户。将返回的结果整合到简报中。仅当是纯活动回忆且无指定目标（如“我这周做了什么”）时，才跳过此步骤，此时你自身的历史记录和实时状态就是全部答案。
对照实时状态验证。对话记录或过期工单属于历史信息，而非当前事实，因此需使用
```
git
```
和
```
gh
```
检查挖掘和扫描过程中发现的PR、分支和工单。当答案取决于代理实际执行的操作（运行的工具、读取的文件、遇到的错误）时，需阅读完整的对话记录，而非仅查看修剪后的本地副本。
按照以下输出规范撰写简报。按线程分组。紧扣指定主题。

Output contract

输出规范

Lead with the capsule, then the thread status, then the problems, then the next move. Deeper detail goes below or gets cut.

Capsule. At most 5 bullets. What this work is and where it stands overall.
Threads. One line each, prefixed with exactly one status tag:
```
[merged #N]
```
,
```
[open PR #N]
```
,
```
[in flight <branch>]
```
,
```
[verified, uncommitted]
```
,
```
[reverted #N]
```
, or
```
[planned, not started]
```
. A thread with no tag is not done yet, so tag it.
Problems. At most 5, the recurring ones. Include the symptoms users keep reporting and any fix that shipped and was reverted, so the next attempt starts where the last one failed.
Next move. The single most useful next action, concrete.

An adjacent feature or ticket stays out unless it blocks this one. When the capsule and thread lines outgrow a screen, cut detail before you cut threads. Write the brief through the unslop skill, cite chat findings by UUID and shared-record findings by their source (PR #, ticket ID, chat permalink, error-tracker issue), and sanitize private context before any public output.

Reply: the brief, to the contract above.

先写核心摘要，再写线程状态，然后是问题，最后是下一步行动。更详细的内容放在下方或直接删减。

核心摘要：最多5个要点。说明此项工作的内容及整体进展。
线程状态：每条线程一行，前缀为唯一的状态标签：
```
[merged #N]
```
、
```
[open PR #N]
```
、
```
[in flight <branch>]
```
、
```
[verified, uncommitted]
```
、
```
[reverted #N]
```
或
```
[planned, not started]
```
。未标记的线程视为未完成，因此必须添加标签。
问题：最多5个，为反复出现的问题。需包含用户持续反馈的症状以及任何已上线又被回滚的修复方案，以便后续尝试能从之前失败的地方重新开始。
下一步行动：唯一最有用的具体行动。

除非相邻功能或工单会阻碍当前工作，否则不要提及。当核心摘要和线程状态内容超出一屏时，先删减细节，而非删减线程。通过unslop技能撰写简报；聊天记录的发现结果需注明UUID，共享记录的发现结果需注明来源（PR编号、工单ID、聊天永久链接、错误追踪系统议题）；在公开输出前需清理私密上下文。

回复：符合上述规范的简报。