ltm-setuplisted
Install: claude install-skill PsychQuant/claude-code-ltm
# 讓 claude-code-ltm 可用
**分清楚兩件事**，因為它們的成本差三個數量級：
| | 誰做 | 成本 |
|---|---|---|
| 下載 `ltm` binary | **自動**（wrapper 在 MCP server 第一次啟動時做）| 幾秒，3 MB |
| 建索引 `ltm build` | **要人同意才跑** | 首次很久（見下方成本說明），之後自動增量 |
所以「plugin 裝好了卻查不到東西」幾乎一定是第二件事沒做。
## 先診斷，不要直接跑 build
```bash
command -v ltm || ls ~/bin/ltm # ① binary 在嗎
ltm query "test" 2>&1 | head -5 # ② 索引在嗎（錯誤訊息會直說）
```
| 症狀 | 意思 | 做什麼 |
|---|---|---|
| `ltm` 找不到 | wrapper 還沒跑過，或下載失敗 | 見下方〈binary 沒下載成功〉 |
| `索引不存在（…）` | 只差建索引 | 往下走 |
| `embedding revision 不同代` / `結構版本不符` / `定址規則不同` | 索引是舊的 | `ltm build --full`，成本同首次 |
| 有結果 | 已經可用 | 不用做任何事 |
## 建索引之前先告訴使用者代價
**不要在沒說清楚的情況下啟動它。** 首次全量建索引**可能很久**——久到使用者會
以為它壞了。
> **這裡刻意不給任何數字。** 前後改過三次，三次都被驗證推翻：先是「數十分鐘」
> （被實測推翻），再是「實測 2 小時 6 分」（引用的紀錄不含它），再是「觀察到約
> 兩小時」（改引的紀錄同樣不含它，而且那份紀錄自己寫明不支持任何耗時預測）。
>
> 本 repo 的誠實邊界要求宣稱要有一份**涵蓋它**的可指名紀錄，而建置耗時目前沒有
> 那樣一份。**與其再猜一個，不如讓使用者自己量**——下面第 1 點就是那個做法。
先讓使用者知道這三件事，再問要不要現在跑：
1. **要跑多久**取決於他的語料大小——先報數字，別讓他自己猜：
```bash
find ~/.claude/projects -name '*.jsonl' | wc -l
du -sh ~/.claude/projects
```
2. **全程在本機**，不連外。
3. **只有第一次要等**：之後每次查詢會自動併入新內容（`refreshIncrementally`），
不必再手動跑。
## 跑
```bash
ltm build
```
跑得久，**放背景**，不要讓它把整個 session 卡住：
```bash
ltm build 2> ~/.claude-ltm/build.log &
```
`ltm build` 把進度寫 **stderr**（stdout 留給最終報告），所以導到檔案再定期
`tail` 它就有真的進度可以回報——不要從外面用 `ps` 或檔案大小去猜。**四**種行
（先前這裡寫「三種」而實際有四種——一份宣稱自己完整的列舉，#44 R2 verify，
devil's advocate）：
| 何時 | `BuildProgress` case | 長相 |
|---|---|---|
| 掃描一結束（嵌入還沒開始）| `scanComplete