一句话

开工或复工前，从你自己的聊天记录加共享记录（工单、PR、报错）重建近期工作上下文，交一份紧凑的当前状态简报。

何时用

• 适合：「catch me up」「我上周做到哪了」；在老话题上开新活先装载旧上下文。
• 不适合：恢复某一个具体 chat/分支（Session pickup 剧本）；只问本 chat 进度的用 pstack-ketchup。

怎么用

/recall 我上周在导出功能上做到哪了，然后看一下这份新的 bug 报告

1. 先分类路由；用户已给全状态就直接用不挖。
2. 锁定范围：时间窗（默认近 7 天）、话题、workspace（只读当前项目的 transcripts），并复述确认。
3. 并行子代理分片挖 chat 历史，每片返回统一 schema：主题、目标、决定、未结线索、卡点、产物，各引 chat UUID。
4. 话题点了名的功能/文件/bug 时，默认再扫共享记录：复用 pstack-why 的 source investigators 查工单、历史修复、线上报错。
5. 用 git、gh 对照活状态验证；写简报：Capsule（至多 5 条）、Threads（每条带状态标签）、Problems、Next move。

产出

• 一份简报：capsule、按线索分组的状态、反复出现的问题、最该做的下一步。

要点与坑

• 「没人写下原因」也是答案，null 结果要报告；raw transcripts 留在子代理，主线程只收结论。
• 严格按真实修改时间排序文件，不按 UUID；不读别的项目的 transcripts。
• 依赖 Cursor transcripts 目录和 MCP；Devin CLI 里可借鉴「自己的历史加共享记录两路扫描」。

关联

• 同类：pstack-ketchup · 依赖：pstack-why · 宿主：pstack-poteto-mode
• 所属：00-pstack-概览