会话日志
写入一份持久的工作会话记录。这些日志会被后续阅读者（包括六周后、已失去所有当前上下文的你）视为事实依据。准确性比文采更重要。
何时运行此技能
- 构建、修复、审计或研究阶段刚刚完成
- 会话即将结束，且存在下一个会话需要了解的状态
- 已找到根因，且其机制值得保留
对于琐碎工作不要运行此技能。一行代码的修复不需要日志。
记录存放位置
项目保存会话记录的位置——例如 docs/sessions/ 目录、笔记库、wiki。如果不明显，先询问一次，之后保持一致。
文件名包含日期和简短描述便于排序和扫描：YYYY-MM-DD Short Description.md。
步骤
1. 撰写前先收集事实
不要仅凭对话记忆撰写。 收集：
- PR编号、提交SHA、迁移时间戳、部署ID
- 实际验证了什么、通过什么命令验证
- 哪些操作失败、哪些问题仍未关闭
- 任何仅能由人类完成的事项
如果某项事实无法确认，应标记为“未确认”，而不是放弃或断言。
2. 撰写正文
# YYYY-MM-DD — <根因分析或交付的内容>
<简要说明工作如何运行：谁规划、谁构建、谁审查。>
## 发生了什么
- 首先是机制。说明为什么会发生，而不仅仅是发生了什么。
- 具体证据：PR编号、SHA、时间戳、行数、日志行。
- 明确区分已证明与推断的内容。
## 修复
1. 编号步骤。每一步说明已验证的内容及其验证方式。
## 永久禁止规则
<仅在会话产生了禁止性规则时使用。每条规则需基于引发该规则的事件。>
## 剩余事项——需要人工处理
- [ ] 仅能由人类完成的事项
链接：<相关文档>
如果笔记系统使用frontmatter，请包含 outcome 字段：一个完整的句子，说明现在为真而之前不为真的内容。 这是文件中阅读最多的行。请使其成为真实的断言，而非标签。
3. 两个每个人都会遗漏的章节
## 剩余事项 和链接页脚是必填项。 它们是承载未来价值的两个章节，也是经常被省略的——在一个包含230条现有日志的笔记库中，它们分别只出现在约21%和28%的日志中。
每次都写这两个章节。如果确实没有需要人工处理的事项，请写“无——没有任何事项被保留。”而不是删除标题。
4. 在线标记每个声明
在线为每个声明添加标签：VERIFIED（如何验证） 或 ASSUMED（为何未检查）。不要模糊处理。
“已验证”意味着由人类或命令实际确认。关于生产环境的声明需要针对生产环境执行查询——而不是通过测试、合入的PR或成功的部署。
5. 保存前解析每个链接
在写入前，对照真实文件检查每个链接目标。笔记系统很快会积累大量失效引用，而充满死链接的日志没人会信任。
6. 更新项目状态
如果工作改变了项目状态，在项目主文档中添加一个带日期的状态节——新内容放在最前面，只添加，绝不覆盖历史。
如果工作推进了一个带有交接文档的项目，请就地更新，以便下一个会话正确获取。
7. 反馈教训
如果用户在会话过程中纠正了某些内容，请将教训写入持久位置——规则文件、记忆存储或本技能本身。这样纠正措施才不会重复发生。
文体规范
- 具体且可证伪。模糊的总结比没有更糟。
- 永远不要声明状态而不说明如何检查。
- 先写坏消息。不要将其掩藏。
- 为没有你任何上下文的读者撰写。
禁止行为
- 不要覆盖现有日志。先读取，然后编辑。
- 不要写入机器生成的目录。
- 不要在笔记旁边创建临时文件或构建输出。