c2638668e3
leo 2026-08-20:「同一個 plugin 你用,薄殼也用,保證兩邊同步」
「我要你幫雲端做薄殼,永遠都有問題,你要做的就是這組設定
你自己可以 dogfooding」
搬進來:41 支 hook(51 條註冊)/7 支 command/2 支 skill/23 支腳本。
不搬 .env、wiki、docs——那些是知識不是環境。
51 條 hook 路徑全部從 $CLAUDE_PROJECT_DIR/.claude/hooks/ 改成 ${CLAUDE_PLUGIN_ROOT}/hooks/,
零漏網。那正是薄殼一直壞掉的根:雲端 cwd 不是真身,寫死路徑就斷。
尚未驗證:Claude Code 能不能從私有 Gitea repo 裝 marketplace(要憑證)。
下一步就是在本機實際裝一次,通了才動雲端 bootstrap.sh。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
6.1 KiB
6.1 KiB
name, description
| name | description |
|---|---|
| deep-recall | 內部 deep research:把散落在 Gitea 票、各 repo wiki、KBDB 裡的枝葉,**還原成一棵 leo 讀得懂的樹**。 在下列時機必讀、必用:leo 問「現在做到哪」「有什麼還沒完成」「幫我看現況」「列今天的大項」; 要交任何橫跨 3 個以上票或 repo 的回報;重裝/遷移前後要拍對帳快照;接關後要向 leo 交待全局。 核心判準:**leo 要的是「他能讀的資訊」,不是「拆得更細的知識」**—— 交出沒有分組的清單、或沒有邏輯鏈的散文,兩者都算沒交付(2026-08-14 一個 session 內連犯兩次)。 收齊:為什麼「靠記得提綱挈領」必定失敗的機械原因/三步流程(分頭讀→只回 schema→先分群再下筆)/ 輸出樹的硬格式(每格必須有出處+狀態)/五條禁令/快照落地位置與對帳用法。 |
deep-recall — 內部 deep research
這支存在的原因(先讀,否則你會以為自己不需要它)
leo 2026-08-14:「給你大量資訊時,你有 2 種反應:1)列出瑣碎資訊沒有分組、重組; 2)總結成幾段缺邏輯鏈的散文。總管需要提綱挈領。」
這不是能力問題,是流程問題。 對外 deep research 能從枝葉還原樹,靠的是三件事—— 而「自己一頁一頁讀完再憑印象寫」這三件一件都沒有:
| deep research 做的 | 自己硬讀會發生什麼 |
|---|---|
| 每個來源由獨立的讀者讀完,只把結構化摘要帶回來 | 原文全湧進同一個 context,讀到第 30 筆時前面的細節已在跟新細節爭位置 ⇒ 只剩「還記得的那幾條」=清單 |
| 先產候選主題、把發現掛上去、再砍掉沒支撐的枝 | 邊讀邊寫 ⇒ 輸出順序=讀到的順序 ⇒ 流水帳 |
| 每個節點回貼出處與狀態 | 沒有出處就只能寫感想 ⇒ 散文 |
🔴 判準:你手上有沒有枝葉,跟你交不交得出樹,是兩件事。 2026-08-14 那次,總管已經讀完 134 張票與全部 wiki,交出去的仍然是清單—— 所以「下次記得要提綱挈領」不是解法,照下面的步驟做才是。
三步流程(不准跳步)
步驟 1|先劃範圍與骨架,再讀任何一個字
寫下這三行(寫在回覆或 scratchpad,不准只在腦裡):
- 問題:leo 這次要的是什麼決定/什麼判斷(不是「他問了什麼」,是「他要拿它做什麼」)
- 來源清單:哪些 repo 的票、哪些 wiki 檔、KBDB 的哪幾個查詢、哪些線上端點
- 候選骨架:先猜 3–5 條主線(允許猜錯,後面會被證據推翻)——沒有骨架就會退化成流水帳
步驟 2|分頭讀,每個讀者只准回固定 schema
一個來源一個 subagent(或一批)。原文不進主 context,只回這個 schema:
{
"source": "Leo/Arcrun#87 / system-dev/wiki/mistakes.md:1200-1400 / kbdb_get_map()",
"findings": [
{
"claim": "一句話講完的事實(人話,不是術語)",
"evidence": "票號+留言 id/檔:行/實測輸出的關鍵那行",
"status": "✅通 | ◐半通 | ❌斷 | 📌事實",
"blocked_by": "誰擋著它(票號/人/前置條件),沒有就 null",
"belongs_to": "你認為它掛在哪條主線(用步驟 1 的骨架,覺得都不對就寫 new:<你的命名>)"
}
]
}
- 派給 subagent 時寫目的不寫做法(CLAUDE.md 派工鐵律),但輸出 schema 要寫死—— 格式不是做法,是介面。
- 事實宣稱要自己驗(規則四之一):subagent 回「X 不存在」時,那多半是「我這裡看不到」。
步驟 3|先分群,再下筆
- 把所有
findings按belongs_to攤開,看哪些 new: 出現超過兩次 ⇒ 那是骨架漏掉的主線,補進去 - 砍掉只有一個發現支撐的枝(那是細節,塞回它的父節點當證據)
- 每條主線寫一句 「共通形狀」——如果寫不出來,那條主線是假的,拆掉重分
- 才開始寫輸出
輸出的硬格式
主線 N|<一句話的父項,講「共通形狀」不是講領域>
現況:✅通 / ◐半通 / ❌斷 ——(一句話:卡在哪)
├─ <子節點> [狀態] ← <出處>
├─ <子節點> [狀態] ← <出處>
完工判準:<可以實測的一句話>
下一步:<誰做什麼;要 leo 的標 👤>
每一格都要有 ← 出處。 寫不出出處的節點不准出現——
它不是「我還沒查」,它是「我在編」。
五條禁令
- 不准交沒有父項的清單(票號列表=原始資料,不是回報)
- 不准交沒有出處的散文
- 不准把「我沒查」「查不到」「工具回 401/回 0」講成「不存在」(三者要分開講)
- 不准把「程式碼寫完了」當成狀態——狀態只有 ✅/◐/❌(CLAUDE.md Critical Path 鐵律)
- 不准在同一份輸出裡混「已驗證」與「我推測」而不標
快照要落地(否則下次又要重跑一次)
產出的樹存成 system-dev/wiki/trees/<YYYY-MM-DD>-<主題>.md,開頭三行寫:
問題/來源清單/量測時間。
對帳用法(重裝、遷移、大改之前後必做):動手前拍一次、動完拍一次,
diff 兩棵樹——沒有掉東西才算成功。這是「重裝有沒有弄丟知識」唯一可驗的方法。
這支的終局:它應該被資料層取代
現在這支是 brute force:每次都要把全部重讀一遍,貴且慢。 真正的解是讓那棵樹變成 ingest 的產物——leo 2026-08-14 定的兩條鏈:
上傳:原文 → 萃 wiki → 同步 wiki+三元組+該庫 index → 組成全局圖 → 算出全庫摘要
查詢:圖搜索 → 查到幾個有關庫 → 查該庫 index → 從 index 找 wiki → 從 wiki 找原文
「該庫 index」與「全庫摘要」就是這棵樹的持久化版本。 它們做出來以後, 本 skill 從「每次重算」降級成「驗算與補洞」。在那之前,每次都要跑這支。