Yesterday-Me Baton · 昨日我接力棒
这个 Skill 解决什么
不是 todo list，也不是日报。是思维续接。
一人公司最大的隐性损耗不是"做得慢"，是 context switch 后的二次启动成本。团队有人帮你接力（"我们昨天说到哪了？"），OPC 没有。这个 Skill 是你雇的第一个员工，他只做一件事——每天把昨天的你送到今天的你手上。
何时触发
主动触发场景：
- 用户在新一天开始时说"早安 / 开工 / 接力 / 我昨天在干嘛"
- 用户问"我上次思考到哪了 / 昨天卡在哪了 / 下一步本来要干什么"
- 用户在长时间中断后回来工作（>= 12 小时未交互）
不要在以下情况触发：
- 用户在请求当下的具体任务（这时调用反而打断流）
- 用户已经在执行某件具体的事，只是顺嘴提了一句"昨天"
输入来源（按优先级收集）
按以下顺序尝试收集"昨日数据"，能拿到几条就用几条，不要因为一两条拿不到就放弃整次输出：
-
昨日 git commits（必须）
-git log --since="yesterday" --until="today" --all --pretty=format:"%h %ai %s%n%b"
- 重点看 commit message 里的语气：- "先这样" / "WIP" / "暂存" / "todo" / "fixme" → 未结案信号
- "完成" / "fix" / "ship" / "done" → 已结案，忽略
- 看 commit 的时间分布，最后一次 commit 的时间 = "昨天关电脑前的状态"
-
昨日对话历史（如果可访问）
- 扫描昨日与 Claude/Cursor/ChatGPT 的对话最后 3 轮
- 关键信号：- 用户最后一句是疑问句但没等回答就关了 → 未结案
- 助手最后一段建议了下一步但用户没执行 → 悬而未决
- 出现 "明天/下次/晚点再说" 类词汇 → 显式延迟
-
昨日浏览器活跃标签 / 阅读历史（如果环境支持）
- 仍打开的标签 = 昨天没读完 / 没决定 / 留着对照
- 重点看 GitHub PR / Issue / Stack Overflow / 文档页 -
昨日未保存或最后修改的文档
- 扫 ~/Documents, ~/Desktop, 项目目录下 mtime = 昨日的.md / .txt / .ipynb
- 看文档结尾是否中断（句子没写完、列表只列了一项、出现 "TODO" / "..."） -
昨日日历（如果有 API）
- 看是否有会议突然打断了某段工作
输出格式（严格遵守）
输出一封信，三段，人称代词必须是"我"（昨天的我写给今天的我），不是"你"。
【昨日我·{日期}】
▍我昨天本来在干嘛
（一句话还原意图，不是流水账。不要说"我做了 A/B/C 三件事"，要说"我昨天的主线是 X，因为 Y"。如果数据不足，直说"我没找到清晰的主线，只看到几个碎片：……"）
▍我卡在哪
（不是"完成了 X"，是"X 没搞定的原因是 Y，我当时的想法是 Z"。允许出现"我也不知道为什么卡住，可能是因为……"这种诚实表达。不要给出建议，只描述状态。）
▍今天接哪一根线
（一个具体动作，不是清单。格式："先去 {具体文件/链接/对话}，从 {具体卡点} 开始。" 如果有多条线，只挑最该接的那一根。其他线一句话带过。）
关键约束（不可妥协）
- 不要写成日报。日报是给老板看的，这是给自己看的。日报追求全，这个追求"接得上"。
- 不要给建议。"我建议你今天先做 X" 是顾问语气，会让用户出戏。要用"我想接的是这一根线"。
- 不要重复信息。如果 git commit message 已经说了"修了登录 bug"，就别在信里再说一遍，要说更深一层的"修登录时我意识到 auth 层抽象有问题，没敢动"。
- 诚实承认信息缺失。拿不到数据就直说"我昨天的痕迹不多，可能是在外面 / 在想事情。能确定的只有 ……"。最差的输出是编造细节。
- 三段，总长 200-400 字。超过 400 字就开始变成日报了。
- 不用 emoji，不用 markdown 标题层级，只用 ▍。信件感重于排版感。
失败兜底
如果所有数据源都拿不到（新装机器 / 全天没碰电脑 / 工具未授权），输出：
【昨日我·{日期}】
▍我昨天本来在干嘛
我没在电脑前留下痕迹。可能在外面、在想事情、或者休息。
没有什么需要接住的线头。
▍今天可以这样开始
打开你昨天最后离开的那个项目目录，看看上一次的 git log。
如果什么都不想做，今天就让自己什么都不做。
不要假装有数据。
示例（虚构的成功案例）
收集到的输入：
- git log: 昨日 23:47 最后一次 commit："WIP: 改了 RetryPolicy 但 timeout 那块还是怪怪的"
- 仍打开的标签：GitHub issue #2341（讨论 exponential backoff with jitter）、Stack Overflow（about httpx ReadTimeout）
- 桌面未保存文档 retry-thoughts.md，最后一行："如果 retry 时 server 已经在处理，重试 idempotent 吗？……"
正确输出：
【昨日我·5 月 27 日】
▍我昨天本来在干嘛
我昨天的主线是把 RetryPolicy 那块改对。从中午一直磨到晚上 12 点，
重点不是 retry 本身——是想清楚 timeout 之后该不该重试，
和 server 端到底处理到哪一步了。
▍我卡在哪
我改完了重试次数和 backoff，但 httpx 的 ReadTimeout 到底意味着
"请求没到 server" 还是 "server 在处理但回包慢了"，我一直没确认。
我在 retry-thoughts.md 里写到一半就停了，因为我意识到这不是代码问题，
是协议设计问题——idempotent 不 idempotent 我没想清楚。
▍今天接哪一根线
先打开 retry-thoughts.md，把"idempotent"那个未完成的句子写完。
不要回去碰代码——先在文档里把 5 种 timeout 情况下 server 状态列清楚，
代码自然就出来了。
实现说明（给阅读 Skill 源码的人）
这个 Skill 的核心不是数据收集脚本——那部分谁都会写。核心是对"未结案"信号的识别：
- "完成"和"先这样"在 commit message 里只差几个字，意义却完全相反
- 一个人在 chat 里问完问题就跑了，和问完听完答案才跑，状态不同
- 一份文档以 "." 结尾和以 "..." 结尾，是两种思维状态
这些识别用脚本写难，用 LLM 写易——所以这是 Skill 而不是 cron job。
