为什么单独一个根可以，而且不需要动宿主配置

技能目录是一层提供者（@deepseek-ai/dsh-skill 的 SkillRegistry）的合并结果：每个提供者按 rank 从小到大参与合并，同名取 rank 小的。所以只要有人覆盖这个根就行。

“有人”很容易搞砸。最自然的做法是往 profile 的 cordis.patch.yml 里给宿主那个 skill-filesystem loader 条目加一条 customSkillDirs——这条路是死的，而且死得没有声音：


## 配置

`normalizeConfig()` 会解析相对路径（相对 ``，绝对路径原样保留）并夹紧每个值。

| 键 | 默认 | 含义 |
|---|---|---|
| `enabled` | `true` | 关掉后 `apply` 直接返回，一个工具都不注册 |
| `skillsRoot` | `/skills` | 技能根的**父**目录；真实的根是它下面的 `learned/`（`skills.learnedDir`） |
| `legacySkillsRoot` | `/skills` | 共享根：专用根被宿主确认可见之前的落点，也是 `organize` 的迁移源 |
| `dataDir` | `/learn/data` | 状态、账本、候选、归档 |
| `capture.maxSessions` | `8` | 内存里同时保留几个会话的窗口（LRU） |
| `capture.maxItemsPerSession` | `120` | 单会话观测上限 |
| `capture.maxItemChars` | `400` | 单条观测压缩后的字符上限 |
| `capture.ignoreTools` | `[]` | 不记工具结果的工具名（默认空：一刀切的黑名单会连真恢复一起藏掉） |
| `capture.recordSuccesses` | `false` | 是否把成功的工具调用也记进窗口 |
| `review.minWeight` | `2` | 低于此权重的观测不进候选 |
| `review.maxProposals` | `8` | 一次审查最多提几个候选 |
| `review.triggerObservations` | `3` | 窗口里有多少条观测才值得跑审查 |
| `review.ruleBudget` | `24` | 一把伞的规则软上限，到了会提示先 `consolidate` |
| `review.similarity` | `0.6` | 去重/强化的相似度阈值 |
| `curator.staleAfterDays` | `14` | 超过多少天没被加载 → `stale` |
| `curator.archiveAfterDays` | `30` | 超过多少天没被加载 → 归档（移动，不是删） |
| `curator.minIdleHours` | `2` | 空闲门槛：会话活跃时不整理 |
| `curator.intervalHours` | `24` | 两次维护的最小间隔 |
| `curator.pinned` | `[]` | 被 pin 的技能跳过一切自动流转 |

`dshHome` 的解析顺序：`config.dshHome` → `config.dsh_home` → 环境变量 `DSH_HOME` → `~/.dsh`。

---

dsh-learn

インストール

ドキュメント

为什么单独一个根可以，而且不需要动宿主配置