ingest

Ingest：把新來源整合進 wiki

目標是把一份來源「消化」進知識庫，而不只是丟一頁摘要——一份來源動到 10–15 頁是正常的，因為它會牽動既有的實體與概念頁。

動手前先讀專案根目錄的 CLAUDE.md（這個 wiki 的實際慣例與結構，以它為準）與 wiki/index.md（現有內容）。若兩者不存在，代表尚未初始化——改用 init skill 先建庫。

流程

1. 讀來源。 讀使用者指定的檔案（通常在 raw/ 根層——那裡是待處理收件箱）；沒指定就掃 raw/ 根層列出未處理檔案讓他挑（raw/archive/ 裡的都是已處理過的，不要重複 ingest）。若是含內嵌圖片的 markdown，先讀文字、再視需要單獨檢視 raw/assets/ 被引用的圖片補足脈絡（LLM 無法在一次讀取中同時吃下 markdown 與內嵌圖）。若使用者給的是網址，先抓取內容轉成 markdown 存入 raw/（或建議他用 Obsidian Web Clipper 剪藏）再開始——來源一律先落地到 raw/，才有 source of truth 可回溯。若使用者只給主題沒給檔案，先問檔案在哪／請他放進 raw/——不要自己編來源內容，這會污染 source of truth 的可信度。

2. 先討論、後大量寫入。 用幾句話講這份來源的關鍵 takeaway，說明你打算建立／更新哪些頁。等使用者確認或調整方向後再大量寫入（除非他說「直接做」）。這一步讓使用者能引導你強調什麼——他才是決定重點的人。

   多份來源時先問監督程度：要「逐份討論」（每份走完整流程）還是「批次直接做」（列出全部檔案、確認一次後連續處理，最後一次總結報告）。批次模式下其餘步驟不變，每份來源仍各自寫摘要頁、歸檔、記 log。

   量太大就分批。 待處理檔案超過約 5 份時，不要一口氣全吃——把清單切成每批約 5 份，一批完整走完（歸檔、摘要頁、跨頁更新、index、log）再開下一批，每批結束簡短回報進度。這樣就算中途斷掉，log 與已歸檔的檔案能明確標出做到哪，剩下的照樣從 raw/ 根層接續。一次讀太多來源會讓每份的消化品質下降，寧可多跑幾輪。

3. 歸檔來源——先搬、後記帳。 把來源檔 mv 到 raw/archive/（不存在就建），內容一個位元組都不改。一定要在寫任何 wiki 頁之前搬，這樣後面所有 source:／sources: 記的都是最終路徑，溯源永遠有效。

4. 寫來源摘要頁。 在 wiki/sources/<slug>.md 建摘要頁：含 type: source frontmatter、source: 指向歸檔後的 raw/archive/ 路徑。摘要要能獨立閱讀，並用 [[wikilink]] 連到相關實體／概念頁。

5. 更新跨頁。 找出這份來源涉及的實體與概念：

   • 已存在 → 更新該頁，併入新資訊，更新 updated: 與 sources:。
   • 不存在但重要 → 在 wiki/entities/ 或 wiki/concepts/ 新建頁。
   • 與既有主張衝突 → 在頁面明確標註矛盾與雙方來源。不要默默覆蓋——保留分歧本身就是知識庫的價值，之後的來源可能會解開它。

6. 更新總論。 若這份來源改變了整體判斷或主論點，更新 wiki/overview.md。只是補充細節就跳過——不要每次 ingest 都重寫總論，否則它會變成又一頁流水帳而非真正的 synthesis。

7. 更新 index。 在 wiki/index.md 把新頁登錄到對應分類（[[連結]] + 一句話摘要）。

8. 追加 log。 在 wiki/log.md 追加一筆，格式固定以便日後用 grep 撈：## [YYYY-MM-DD] ingest | <來源標題>，底下條列建立／更新了哪些頁與來源歸檔到哪。

9. 回報。 簡短列出你動過的頁（用 [[連結]] 或路徑）與來源歸檔位置，方便使用者在 Obsidian 裡點開檢查。

慣例

• raw/ 根層＝待處理收件箱；raw/archive/＝已處理歸檔（扁平、不分類——知識的組織在 wiki/ 那層，raw 只負責溯源）。來源檔只能 mv，永遠不改內容（source of truth）。
• 頁間連結一律用 [[wikilink]]（Obsidian 語法），graph view 才連得起來。連結是知識庫的核心資產，寧可多連。
• 每頁開頭放 YAML frontmatter：type（source/entity/concept/note）、created、updated、sources、tags。
• 日期一律用今天的實際絕對日期。
• 若過程中發現值得固定下來的新慣例（如新頁型），主動提議更新 CLAUDE.md。