背景知識寫好了，接下來的問題是：怎麼讓它變成一個可以重複呼叫、不用每次重新描述一次的流程？

Day14 把 PARA 分類判斷規則、Frontmatter 規範摘要、brain-cli 呼叫慣例寫進了 obsidian-agent-brain/CLAUDE.md，但這份背景知識目前只能在一般對話中被動等待 Agent 臨場套用——vault/00_Inbox/ 下的草稿筆記該歸到哪個資料夾、Frontmatter 該怎麼補齊，每次都得使用者重新描述一次流程。今天要把「草稿 → 結構化筆記」這個整理流程固定成一個可重複呼叫的 Agent 工作流：/refine-inbox。

為什麼是 slash command，不是 brain-cli 新指令

第一個要決定的問題：/refine-inbox 該寫成 brain-cli 的新 Go 子指令（例如 brain move），還是寫成一份 Claude Code 的 slash command 提示詞檔案？

PARA 分類判斷本質上是語意理解問題——「這篇筆記有沒有明確截止日期」「是不是需要長期主動維護的知識領域」，這些問題沒有辦法寫成關鍵字比對的決定性演算法，硬寫成 Go 邏輯只會變成一堆脆弱的規則比對，反而比 Agent 直接依 CLAUDE.md 的判斷問題推理更僵化。這跟 Day14 定下的既有邊界（不修改 brain-cli 程式碼處理判斷型任務）是同一個道理，所以 /refine-inbox 定義成 .claude/commands/refine-inbox.md，一份描述固定執行步驟的提示詞檔案，由 Agent 讀取後照步驟執行，不寫一行 Go 程式碼。

第二個問題接著出現：搬移筆記檔案、更新 Frontmatter，這個「動作」本身要不要封裝成一個新的 brain move <note> <target> 指令？考慮過，但目前只有一篇真實案例（PARA 筆記法.md），為了它去新增並測試一個 Go 子指令，成本相對於直接讓 Agent 用既有的檔案操作工具完成，效益不成比例，而且會把這次 change 的範圍一路擴大到 brain-cli-core。所以決定：搬移動作由 Agent 直接操作檔案系統，brain-cli 只負責掃描與健康檢查驗證，不負責搬移本身。等以後出現足夠多、規則明確到值得寫成程式碼的搬移邏輯，再回頭評估。

兩次驗證,各管各的事：搬移前 scan、搬移後 health

/refine-inbox 在搬移筆記前後各呼叫一次既有指令，但兩次呼叫的目的不同，不能合併成一次：

• 搬移前執行 brain scan：確認目標 PARA 資料夾存在、目的檔名不會跟既有筆記衝突。這對應 CLAUDE.md 行為守則裡「異動前先確認路徑存在」的要求——如果目的檔名已經有同名筆記，直接中止這篇筆記的搬移，不覆寫既有檔案。
• 搬移後執行 brain health：驗證搬移與 Frontmatter 更新完成後，沒有新增孤立筆記或斷鏈。

這裡有一個值得說清楚的原理：搬移筆記到別的資料夾，其實不是斷鏈風險的來源。brain-cli-core 的全庫索引（Index.Resolve）解析 Wikilink 時，是依筆記的 Frontmatter.Title 或 aliases 查找目標，完全不依賴檔案路徑。也就是說，只要搬移過程中 title 沒有被改壞，任何原本指向這篇筆記的 [[Wikilink]]，搬移後一樣能解析成功。所以 brain health 這道驗證，真正要抓的不是「搬移把連結弄斷了」，而是「Frontmatter 修正過程中不小心改壞了 title」，或是 vault 中原本就存在、跟這次搬移無關的斷鏈。搬移前用 scan 擋路徑問題、搬移後用 health 抓連結完整性，兩者時機不同、要抓的問題也不同，分開呼叫才不會把「該事前擋下的」跟「只能事後驗證的」混在一起。

實際跑一次：PARA 筆記法.md

vault/00_Inbox/ 目前唯一一篇草稿是 PARA 筆記法.md，Frontmatter 是 type: inbox-draft、status: seed，正文只有一句話說明什麼是 PARA，加上一段「之後要展開的內容」大綱（四個分類的判斷標準、跟 Zettelkasten atomic note 怎麼搭配、Inbox 多久清一次）。拿它實際跑一次 /refine-inbox：

依 CLAUDE.md 的四條判斷問題逐條檢查——沒有明確截止日期或完成狀態（排除 10_Projects）；是不是需要長期主動維護的知識領域？還是被動查閱的參考資料？這篇筆記的正文本身還停留在大綱階段，四個判斷問題都沒有足夠內容可以明確命中任何一條。

這正是 Day15 設計時預先考慮到的情況：草稿內容太薄，判斷問題套不上去時，/refine-inbox 不會硬套一個結論。它會把這篇筆記標記為「內容不足以判斷歸屬」，保留在 00_Inbox 不搬移，跳過 Frontmatter 修正、brain scan、搬移、brain health 幾個步驟，直接在輸出摘要裡記錄這個結果：

原路徑：vault/00_Inbox/PARA 筆記法.md
新路徑：未搬移（內容不足以判斷歸屬）
修正欄位：無
brain health 結果：未執行（未搬移）
分類依據：無——四條 PARA 判斷問題均未明確命中

執行前後，brain health 的結果都是「2 篇孤立筆記、0 筆斷鏈」——vault 狀態完全沒有變化，因為這次沒有任何一篇筆記真的被搬動。這驗證了一件事：/refine-inbox 面對模糊內容時，交出的是「誠實地說我判斷不出來」，而不是為了完成任務硬掰一個看起來合理的答案。之後等這篇筆記的內容展開得更完整（例如四個分類標準真的寫出來），同一個指令再跑一次，就有機會依內容命中某一條判斷問題，走完整套搬移流程。

銜接後續

今天把 Day14 建立的背景知識，串成了第一個可重複呼叫的 Agent 工作流指令。/refine-inbox 目前只處理「草稿 → 結構化筆記」這一段流程，而且刻意不做人工介入澄清的互動迴圈——遇到判斷不出來的內容，選擇的是誠實回報而不是強行歸類，覆核責任留給使用者事後檢視摘要。後續還有其他重複性高、值得固定成指令的整理流程（例如替新筆記建立雙向連結、或是為累積到一定數量的 atomic note 產生 hub-note），會用同樣的模式——依賴 CLAUDE.md 的背景知識、只在必要時呼叫 brain-cli 既有指令做驗證——逐步擴充成一組 Agent 工作流指令庫。