Obsidian 工作日志与发版记录器は何をしますか？

此技能将已完成的工作转化为持久的 Obsidian 笔记。它是有意选择性的：目标不是保留聊天记录，而是保留那些对未来实施、发布、回滚或交接有帮助的一小部分事实。

前置条件

路径从配置解析，不绑定本机（与 PKB 的前置条件一致；这里不要写任何机器专属路径）：

vault 路径从 $OBSIDIAN_VAULT_PATH 或 ~/.config/agent-skills/obsidian-vault-path 解析得到 — 绝不硬编码
获取路径的规范方式：python3 ../obsidian-personal-knowledge-base/scripts/vault_path.py --explain
换机器或 vault 搬家只需修改上面两项配置，本技能与 PKB 都会跟随变更

必须的启动检查清单

在向 vault 写入任何内容之前，你必须：

加载 obsidian-personal-knowledge-base/references/vault-map.md — vault 的目录映射和放置约定。
加载 obsidian-personal-knowledge-base/references/writing-conventions.md — 命名、frontmatter、链接和 MOC 约定。
使用单层 ls 探测目标区域（参见位置决策）— vault-map.md 是快照，并非权威；以文件系统为准。

这些都是硬性要求，不是建议。如果未安装 obsidian-personal-knowledge-base，请告知用户先安装它并停止操作。不要基于对 vault 结构的假设来写入。不要为这个技能派生 vault 约定——当 PKB 的引用变更时，此技能会继承该变更。

范围

重用最近的现有项目、领域、资源笔记、MOC 或模板，而不是发明并行结构。当没有现有笔记涵盖该主题时，请遵循 obsidian-personal-knowledge-base/references/vault-map.md 中的放置规则。

触发信号

当以下一个或多个条件成立时，使用此技能：

一个任务已完成，并产生了实现决策、脚本、路径、配置、数据库变更、环境变量、验证步骤、回滚步骤或发布命令
用户要求将工作记录到个人知识库
用户要求提供周发版笔记、发版检查清单、部署记录或发版文档
在代码、SQL、配置、部署或运维工作后，需要更新项目或领域笔记
在完成任务后，某个重复性运维流程变得更清晰，应保留供将来使用

不要因普通的解释、头脑风暴、推测性计划、一次性聊天摘要或没有未来运维价值的小编辑而触发。

如果请求混合了记录已落地工作和编辑或组织现有笔记（例如“发版了，帮我整理一下”或“更新一下知识库里某块内容”），在行动前先询问用户想要哪一个，而不是猜测。两种意图都是合理的；只有用户知道是哪一个。

记录什么

只记录已落地的要点。已落地的要点是指现在为真、已执行、已更改、或准备好供其他人遵循的内容。

好的候选内容：

更改过的文件、模块、API、脚本、SQL 文件、路由、服务或部署路径
已运行或在发布期间必须运行的命令
重要的配置键、环境变量、端口、服务器路径、容器名称、cron 作业或功能开关
验证证据，如构建命令、冒烟测试、API 检查、截图、日志或已知跳过的检查项
回滚或备份步骤
执行顺序假设、依赖关系、前置条件和风险
影响未来工作的持久设计决策

不记录：原始对话；每个碰过的文件（当只需摘要时）；失败的实验（除非能防止未来的错误）；琐碎的格式或仅本地的噪音；密码、令牌、密码或完整凭据；未被接受的推测性计划。

如果某个细节看起来敏感但操作上很重要，请记录变量或配置名称及位置，而不是秘密值。

位置决策

选择最窄的稳定归属：

有明确终点的成果驱动型工作 → 01 Projects/<项目>/
长期责任、交付系统或运维知识 → 02 Areas/<领域>/
可复用的技术知识 → 03 Resources/<主题>/
不明确或不完整的捕获内容 → 00 Inbox/，但仅限于没有足够上下文进行安全分类时。

对于此技能，通过探测而不是凭记忆来解析路径。

在写入之前探测候选区域（ls "$VAULT/01 Projects", ls "$VAULT/02 Areas", ls "$VAULT/03 Resources"）。
选择涵盖该主题的现有最窄目录。
如果目标目录不存在，询问用户在哪里创建它 — 不要写入不存在的路径。例外：用户本轮已指名了确切路径（“放到 02 Areas/05 数据平台/ 下”）→ 使用那个路径，不要再问一遍（问的是“不知道放哪”，不是“用户说了不算”）。
在创建新的持久笔记后，更新最近的 MOC/索引。

常见场景：部署与运维类发布

这类发布（打包、上传、解压、配置拷贝、容器重启、前后端分开发布）通常归 02 Areas/<领域>/<子主题>/。没有匹配领域时：告知用户历史路径已不在，问清记录放哪再动手 —— 不要写进记忆中的旧路径，也不要假定某类项目一定有对应 Area。

模糊话“把这周做的事记一下”：不要自己判

它同时命中触发词（记一下）与排除项（笼统的本周汇总）。先问用户要哪一种：周报 → PKB（references/work-management.md）；本周已落地的发版事实 → 本技能。回答前不写任何笔记。

周发版笔记

当任务包含发布准备或与发布相关的变更时，在最相关的项目或领域文件夹中维护一个周发版笔记。

默认命名：

发版 - <系统或项目名> - YYYY-Www.md

示例：01 Projects/<项目名>/发版 - <项目名> - 2026-W18.md 或 02 Areas/<领域>/<子主题>/发版 - <系统或项目名> - 2026-W18.md。

使用 ISO 周编号，除非用户提供了不同的发布命名约定。如果当前周的笔记已存在，则更新它而不是创建另一个。在写入之前探测父文件夹；如果它不存在，询问用户发版笔记应放在哪里（同上：用户本轮已指名的路径就是答案）。

周发版笔记模板

阅读 references/release-note-template.md 并使用其结构，除非附近的现有笔记有更强的本地约定。

保持发版笔记简短。将完整的脚本或配置片段放在 04 发布依赖清单 下，但除非用户要求操作细节，否则避免将笔记变成详细的运行手册。

更新工作流程

确定任务结果。
- 总结实际更改或决定的内容。
- 将已落地的事实与猜测、选项和放弃的尝试分开。
选择笔记目标。
- 如果某个现有的项目/领域/资源笔记已涵盖该主题，则首先更新它。
- 仅当存在与发布相关的细节时，才创建周发版笔记。
- 当创建新的持久笔记时，更新最近的 MOC。
编写最小的、可持久且具有操作性的更新。
- 对于工作日志使用紧凑的项目符号；仅当未来的执行需要确切的命令时才使用命令块。
- 解释不明显的标志、配置字段、路径和执行顺序假设。
- 记录要运行什么、在哪里运行、它影响什么以及如何验证它。
- 明确包含跳过的验证，并在已知时为发版笔记包含备份和回滚步骤。
验证链接和结构完整性。
- 确保新笔记已从最近的 MOC 或父笔记链接。
- 运行 python3 scripts/check_release_note.py <笔记路径> — 它守护的是此技能自己写下的规则（文件名格式、ISO 周号、标题与文件名一致、frontmatter、模板里的章节骨架、同一系统同一周不重复、已挂到 MOC、没有明显密钥值）。章节骨架是从 references/release-note-template.md 读取的，模板改变了它也会跟着改变。
- 链接是否失效不归它管 —— 那是下面这条 PKB 脚本的事（两者互补，不重叠）。
- 在创建或移动笔记后，运行 python3 ../obsidian-personal-knowledge-base/scripts/check_links.py --ignore-template；期望退出码为 0（详细信息见 PKB 的 references/structural-checks.md）。
- 如果此操作更改了目录结构、文件计数或钩子行为，请在 同一操作中 更新 vault-map.md 或相关 SKILL.md 中的描述 — 不要留到下次探测才发现。
- 避免在多个地方重复相同的发布说明；改为交叉链接。
简要报告 — 保持交接简短；价值在于笔记。
- 创建或更新了哪些笔记。
- 记录了哪些已落地的要点。
- 是否创建或更新了周发版笔记。
- 任何假设、跳过的验证或缺失的发布细节。

写作风格

像运维记忆一样写，而不是日记：

直接、事实性、易于浏览
以中文为主，在规范术语处使用英文技术词汇
没有教导性语言，例如“第一次”、“可以先这样理解”或“接下来我们”
没有夸大的摘要；首选确切的命令、路径和约束
没有秘密

安装

通过仓库根目录的 npx skills add huangrx6/agent-skills 进行安装（参见仓库根目录 README.md）。

先安装 obsidian-personal-knowledge-base — 此技能依赖其 references/vault-map.md 和 references/writing-conventions.md，并在它们不可用时拒绝写入。

Obsidian 工作日志与发版记录器