关于 recall
recall 是一项在开始或恢复工作前重建近期工作上下文的技能，面向需要跨对话继续推进项目的 Agent。它结合限定范围的聊天记录检索、共享项目记录调查和当前状态验证，输出简明进展摘要与下一步。
主要功能
- 01限定工作区、主题与时间范围
- 02并行检索近期对话记录
- 03调查共享记录中的当前状态与旧尝试
- 04核对 PR、分支和工单的实时状态
- 05按固定结构整理进展与下一步
适用场景
- 01从先前对话恢复项目进度
- 02查明某项功能或错误的当前状态
- 03开始工作前汇总相关讨论、问题与后续动作
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/recall确认已加载。
详细介绍
Recall
在 GitHub Copilot 上，遵循此技能前，请先阅读平台映射，包括其中针对各技能的说明。
在 Muse 上，遵循此技能前，请先阅读平台映射，包括其中针对各技能的说明。
开始或恢复工作前，先重建用户最近的工作上下文，并用简洁的摘要说明当前进展和下一步要做什么。
保持简洁，紧扣主题。只阅读当前范围内的线程所需内容，然后停止。
你的上下文保存在两份记录中。你自己的聊天历史记录了你做过的事和作出的决定。共享记录则记录了其他人以不同身份围绕同一代码所做的一切：用户反复报告的症状、已发布又被撤回的修复，以及生产环境中仍在触发的错误。why 技能会跨源代码管理、问题跟踪器、聊天和问题频道、长篇文档及错误跟踪系统搜索第二份记录。一个功能若留下了大量 bug，其大部分来龙去脉都保存在那里，因此不要只根据自己的对话记录来重建情况。
对话记录位于 ${CLAUDE_CONFIG_DIR:-$HOME/.claude}/projects/<encoded-cwd>/<uuid>.jsonl。每一行都是一条聊天消息。运行 node <plugin>/skills/reflect/scripts/claude-project-dir.mjs，即可打印本次会话的目录，而不必手动构造 <encoded-cwd>。Claude Code 会将每个非 ASCII 字母或数字字符替换为 "-"（因此 /Users/you/my_app.web 会变为 -Users-you-my-app-web），名称超过 200 个字符时会使用哈希缩短；如果设置了 CLAUDE_CODE_PROJECT_DIR_NAME 和 CLAUDE_CONFIG_DIR，则会改用前者。
- 先分类，再路由。要恢复某段具体的历史聊天，应使用
session-pickup操作手册，而不是这个。要把习惯转化为持久技能，应使用automate-me。生成一份供人阅读的工作摘要是另一项任务。Recall 会在你采取行动前，加载近期聊天中的工作上下文。如果用户已经提供了完整的状态摘要（路径、分支、变更），就直接使用，跳过挖掘。 - 搜索前先锁定范围。确定时间窗口（“近期”应是一个明确范围，默认最近 7 天）、指定的话题，以及工作区（默认当前工作区。未经请求，绝不读取其他项目的聊天记录）。向用户复述范围。绝不擅自把“全部”改成“最近 N 条”。
- 全面检索聊天记录。使用快速、低成本的模型并行启动子 Agent，让每个子 Agent 负责一部分语料。告知每个子 Agent：按实际修改时间排序候选项（使用
ls -t），绝不按 UUID 名称排序；先 grep 话题，再只阅读匹配的聊天及其中相关部分；跳过当前聊天和明显的噪声（子 Agent、评估和测试聊天）。每个子 Agent 对每段聊天都返回相同的结构化信息：话题、用户目标、决策、未解决的问题、遇到的困难与修正，以及产物（PR、工单、分支），每项都注明聊天 UUID。对于一两段聊天，跳过并行分派，直接搜索。原始记录留在子 Agent 中。主线程只获取它们的调查结果。根据任务，为每个子 Agent 选择合适的推理级别，参照 poteto-mode 技能的 Subagents 部分。 - 只要话题提到某项功能、文件、子系统、领域或 bug，就全面检查共享记录。这是默认要求，不由你自行判断；“我在 X 上做的工作”也不例外。交给 why 技能的来源调查员处理，但要将其问题从“为什么要这样构建”引导为“当前状态是什么、尝试过什么但未能奏效、用户仍在反馈什么”。复用该技能针对每类来源的操作手册，在检索聊天记录的同时并行运行调查员，并沿用该技能的做法：每个来源安排一名调查员，空结果也要记录，跳过不可用的 MCP 并说明原因。将调查结果纳入简报。报告某项内容从未被记录之前，还要检查项目常规规则指定的所有待办或记录位置（记忆目录、决策日志、
.planning/目录树、项目的 CLAUDE.md 指针）。如果跳过项目规则指定的位置，就不能算检索完毕。只有在纯粹回顾活动且没有指定目标（“我这周做了什么”）时才跳过此步骤；此时你自己的历史记录和实时状态就是完整答案。 - 对于有关人工裁定的说法，请遵循 关于人工决策的说法。当精确范围很重要时，保留可归属的原始措辞和来源，区分 Agent 的解读，并将复制的摘要视为同一条证据链。
- 对照实时状态进行核实。使用
git和gh检查挖掘和检索中发现的 PR、分支与工单。如果答案取决于 Agent 实际做了什么（运行了哪些工具、读取了哪些文件、遇到了什么错误），请阅读完整记录，而非经过删减的本地副本。 - 按照下方的要求撰写简报。按话题串归类。紧扣指定话题。
输出约定
先写摘要，再写线程状态，然后写问题，最后写下一步。更深入的细节放在下面，或直接删掉。
- 摘要。 最多 5 个项目。说明这项工作是什么，以及整体进展如何。
- 线程。 每项占一行，并且必须以且仅以一个状态标签开头：
[merged #N]、[open PR #N]、[in flight <branch>]、[verified, uncommitted]、[reverted #N]或[planned, not started]。没有标签的线程尚未完成，请添加标签。 - 问题。 最多 5 项，列出反复出现的问题。包括用户持续报告的症状，以及已发布后又回退的修复，让下一次尝试能从上次失败之处继续。
- 下一步。 最有价值的单一后续操作，具体说明。
除非相邻功能或工单会阻碍当前事项，否则不要提及。当摘要和线程行超出一屏时，应先删减细节，而不是删减线程。使用 unslop 技能撰写简报；引用聊天发现时注明 UUID，引用共享记录发现时注明其来源（PR #、工单 ID、聊天永久链接、错误跟踪器问题），并在任何公开输出前清理私人上下文。
回复： 按照上述约定撰写简报。