Obsidian 工作日誌與發布記錄器
此技能將已完成的工作轉化為持久的 Obsidian 筆記。它具有選擇性：目標不是保留對話記錄，而是保留對下一次實施、發布、回滾或交接有幫助的少量事實。
先決條件
路徑從配置解析，不綁定本機（與 PKB 的先決條件一致；這裡不要寫任何機器專屬路徑）：
- vault 路徑從
$OBSIDIAN_VAULT_PATH或~/.config/agent-skills/obsidian-vault-path解析 — 永遠不要硬編碼 - 取路徑的規範方式：
python3 ../obsidian-personal-knowledge-base/scripts/vault_path.py --explain - 換機器或 vault 搬家只需改上面兩項配置，本 skill 與 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）；本週已落地的發版事實 → 本 skill。回答前不寫任何筆記。
每週發布筆記
當任務包含發布準備或發布相關變更時，在最有關聯的專案或領域資料夾中維護一個每週發布筆記。
預設命名：
發版 - <系統或項目名> - YYYY-Www.md
範例：01 Projects/<項目名>/發版 - <項目名> - 2026-W18.md 或 02 Areas/<領域>/<子主題>/發版 - <系統或項目名> - 2026-W18.md。
使用 ISO 週數編號，除非使用者提供了不同的發布命名慣例。如果當前週的筆記已存在，請更新它而不是建立新的。在寫入之前探測父資料夾；如果它不存在，請詢問使用者發布筆記應放在哪裡（同上：使用者本輪已指名的路徑就是答案）。
每週發布筆記範本
讀取 references/release-note-template.md 並使用其結構，除非附近的現有筆記有更強的本地慣例。
保持發布筆記簡短。將完整的腳本或配置片段放在 04 發布依賴清單 下，但除非使用者要求營運深度，否則避免將筆記變成詳細的 runbook。
更新工作流程
-
識別任務成果。
- 總結實際變更或決定的事項。
- 將已落地的事實與猜測、選項和放棄的嘗試分開。
-
選擇筆記目標。
- 當現有專案/領域/資源筆記已擁有該主題時，優先更新它。
- 僅當存在發布相關細節時建立每週發布筆記。
- 當建立新的持久筆記時，更新最近的 MOC。
-
撰寫最小的、保持可操作性的持久更新。
- 工作日誌使用簡潔的項目符號；僅在將來的執行需要確切命令時才使用命令區塊。
- 解釋不明顯的旗標、配置欄位、路徑和排序假設。
- 記錄要執行什麼、在哪裡執行、它影響什麼以及如何驗證它。
- 明確包含跳過的驗證，以及發布筆記中已知的備份和回滾步驟。
-
驗證連結和結構完整性。
- 確保新筆記已從最近的 MOC 或父筆記連結。
- 執行
python3 scripts/check_release_note.py <筆記路徑>— 它守的是本 skill 自己寫下的規則（檔名格式、ISO 週號、標題與檔案名一致、frontmatter、範本裡的章節骨架、同一系統同一週不重複、已掛到 MOC、沒有明顯金鑰值）。章節骨架是從references/release-note-template.md讀的，範本改了它跟著改。 - 連結是否失效不歸它管 —— 那是下面這條 PKB 腳本的事（兩者互補，不重疊）。
- 在建立或移動筆記後，執行
python3 ../obsidian-personal-knowledge-base/scripts/check_links.py --ignore-template；預期 exit 0（細節見 PKB 的references/structural-checks.md）。 - 如果此操作更改了目錄結構、檔案計數或鉤子行為，請在同一操作中更新
vault-map.md或相關 SKILL.md 中的描述 — 不要留給下一次探測去發現。 - 避免在多個地方重複相同的發布說明；改為交叉連結。
-
簡短回報 — 保持交接簡短；價值在筆記中。
- 哪些筆記被建立或更新。
- 記錄了哪些落地要點。
- 是否建立或更新了每週發布筆記。
- 任何假設、跳過的驗證或遺失的發布細節。
寫作風格
像營運記憶一樣書寫，而不是日記：
- 直接、基於事實且易於掃讀
- 以中文為主，在規範英文術語處保留英文
- 沒有教練式語言，如「第一次」、「可以先這樣理解」或「接下來我們」
- 沒有誇大的總結；偏好確切的命令、路徑和約束
- 沒有機密
安裝
透過 repo 根目錄的 npx skills add huangrx6/agent-skills 安裝（參見 repo 根目錄 README.md）。
先安裝 obsidian-personal-knowledge-base — 此技能依賴其 references/vault-map.md 和 references/writing-conventions.md，並在這些檔案不可用時拒絕寫入。