不是 todo list，也不是日报。是思维续接。
一人公司最大的隐性损耗不是"做得慢"，是 context switch 后的二次启动成本。团队有人帮你接力（"我们昨天说到哪了？"），OPC 没有。这个 Skill 是你雇的第一个员工，他只做一件事——每天把昨天的你送到今天的你手上。
主动触发场景：
不要在以下情况触发：
按以下顺序尝试收集"昨日数据"，能拿到几条就用几条，不要因为一两条拿不到就放弃整次输出：
git log --since="yesterday" --until="today" --all --pretty=format:"%h %ai %s%n%b".md / .txt / .ipynb输出一封信，三段，人称代词必须是"我"（昨天的我写给今天的我），不是"你"。
【昨日我·{日期}】
▍我昨天本来在干嘛
（一句话还原意图，不是流水账。不要说"我做了 A/B/C 三件事"，要说"我昨天的主线是 X，因为 Y"。如果数据不足，直说"我没找到清晰的主线，只看到几个碎片：……"）
▍我卡在哪
（不是"完成了 X"，是"X 没搞定的原因是 Y，我当时的想法是 Z"。允许出现"我也不知道为什么卡住，可能是因为……"这种诚实表达。不要给出建议，只描述状态。）
▍今天接哪一根线
（一个具体动作，不是清单。格式："先去 {具体文件/链接/对话}，从 {具体卡点} 开始。" 如果有多条线，只挑最该接的那一根。其他线一句话带过。）
如果所有数据源都拿不到（新装机器 / 全天没碰电脑 / 工具未授权），输出：
【昨日我·{日期}】
▍我昨天本来在干嘛
我没在电脑前留下痕迹。可能在外面、在想事情、或者休息。
没有什么需要接住的线头。
▍今天可以这样开始
打开你昨天最后离开的那个项目目录，看看上一次的 git log。
如果什么都不想做，今天就让自己什么都不做。
不要假装有数据。
收集到的输入：
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 的核心不是数据收集脚本——那部分谁都会写。核心是对"未结案"信号的识别：
这些识别用脚本写难，用 LLM 写易——所以这是 Skill 而不是 cron job。
共 1 个版本