| name | wiki-orchestrate |
| description | 用于整理 Obsidian LLM Wiki 的统一编排入口——定位 vault → 两方只读体检 → 汇总行动计划 → 用户确认 → 按「结构→策展」编排 wiki-struct / wiki-curate 完成整理（下一步跑哪个 skill / 命令 / 参数由模型依据体检结果判断，建议性非规则）。触发语：/wiki-orchestrate（scan / set-vault）、「整理笔记库」、「跑一次编排」、「统一整理 vault」。入口自身不改内容笔记，写操作全委托子 skill 并继承其红线。 |
wiki-orchestrate
整理笔记库的统一入口。把"逐步手动判断该调哪个 skill"换成一个
模型驱动的编排 playbook：先做只读体检，再让模型依据结果决定调用
wiki-struct / wiki-curate 的哪个命令、什么参数，
按序完成整理。本入口为后期"定时启动器"铺路（定时器不在本 skill 范围）。
spec-distill（知识沉淀阶段）已于 v2.0.0 剥离并迁移到 specode 的
/specode:distill；本编排不再含「沉淀」阶段。
完整设计见 DESIGN.md。
这是一篇 playbook，不是斜杠命令调度器
两个子 skill 当前未注册为可 / 调用的命令，它们由"确定性 Python 脚本 +
LLM 驱动的 SKILL.md 流程"两部分组成。本入口因此这样执行：
- 确定性部分：直接
python3 运行子脚本（struct_gen.py、lint.py）。
- LLM 流程部分：内联读取对应子 SKILL.md，按其步骤执行（拆知识点、写文档、
问用户等）；子 skill 自身的确认关卡与红线照常生效。
- 编排部分：本文件 +
references/ 告诉你——现在该读哪个子 SKILL.md、跑哪个
脚本、传什么参数、依据什么体检信号判断下一步。
命令
| 命令 | 行为 |
|---|
/wiki-orchestrate（= run） | 定位 vault → 两方只读体检 → 写 orchestrate-report → 呈现行动计划 → 用户批准后逐阶段执行 |
/wiki-orchestrate scan | 只定位 + 两方只读体检 + 写 orchestrate-report，不执行任何写阶段 |
/wiki-orchestrate set-vault [<路径>|<名>] | 重设/切换 active 库：已注册库用 registry.py set-active --name <名>，新库用 register --activate（见第 0 步）；不传则询问用户 |
/wiki-orchestrate help | 显示本命令表与两个子 skill 概览 |
未给子命令时按 run 处理。
第 0 步：定位 vault（每个命令都先做）
本套件作为插件安装、代码不在 vault 内；vault 路径与各库结构配置都登记在家目录注册表 ~/.config/obsidian-wiki/（vaults.json 存各库 path + active，configs/<名>.json 存各库结构）。既不写插件目录（cache，更新即丢）、也不再写进 vault。注册表读写统一走 registry.py。
脚本定位：本编排入口自身无脚本，它要跑的都是别处的脚本——通用库 registry.py 在插件根 lib/，子 skill 脚本在各自 scripts/ 下。用本 skill 的 base directory 把相对路径拼成绝对路径来跑（不解析环境变量、不 find 缓存）：registry.py = ../../lib/registry.py、config.example.json = ../../config.example.json、struct 脚本 = ../wiki-struct/scripts/struct_gen.py、curate 脚本 = ../wiki-curate/scripts/lint.py。
- 解析 active 库：
python3 ../../lib/registry.py resolve。
- 成功 → 输出 JSON
{name, path, config, config_exists}；取 path 作 <vault>。
- 退出码 3（未配置）→ 走第 4 步注册。
- 校验：
path 存在、命中标志物 <index_dir>/（默认 00-Index/，即"该库的 index 目录"）、且 config_exists=true。
- 命中 → 静默复用，不打扰用户，直接进入后续步骤。
- 未配置 / 失效 → AskUserQuestion 询问 vault 路径，注册并播种配置：
python3 ../../lib/registry.py register --name <短名> --path "<vault>" --activate --config-from ../../config.example.json
然后提示用户按自己库的目录名编辑 ~/.config/obsidian-wiki/configs/<短名>.json（模板即 config.example.json）。改完再次校验通过才继续。
- vault 路径含
/Volumes/ → 额外确认外置盘已挂载（如 ls "<path>" 可访问）；未挂载报错停止，不静默写到别处。
config_exists=false（已注册但缺配置）→ 报错并提示：把插件根 config.example.json（本 skill 相对路径 ../../config.example.json）抄到 ~/.config/obsidian-wiki/configs/<名>.json 并按库改，再跑。
注册表结构（registry.py 维护；机器相关，不入库）：
{
"active": "notes",
"vaults": { "notes": { "path": "/Volumes/External HD/Obsidian/Notes" } }
}
多库：vaults 可有多个条目，active 决定默认操作哪个；registry.py list 查看、set-active --name <名> 切换。
跨终端 / 移动目录导致 active 库路径不命中时，走第 4 步重问并 register --activate 覆盖。
第 1 步：只读体检（不写任何笔记）
子 skill 脚本在各自 scripts/ 下（本 skill 相对路径见「脚本定位」）。
依次运行（<vault> = 第 0 步 registry.py resolve 得到的 path），两者皆只读（只写各自 _system/ 报告）：
python3 ../wiki-struct/scripts/struct_gen.py check --vault "<vault>"
python3 ../wiki-curate/scripts/lint.py lint --vault "<vault>"
- struct check 写
00-Index/_system/struct-report.md：结构漂移 / 缺 marker / 缺文件 / 坏链 计数。
- lint 写
00-Index/_system/lint-report.md：缺「用途」段 / 重复 basename / 孤儿无反链 / frontmatter 缺字段 计数（确定性内容体检，比读旧 curate-report 可靠）。
- 收件箱积压：另用 glob 数
99-Inbox/、Clippings/ 下待整理文件（只读）。坏链/结构归 struct check，不在此处。
读两方报告，提取关键数字。脚本若不存在或报错 → 在汇总里标注该子 skill 不可用、其阶段
将跳过，并提示用户。
第 2 步：汇总行动计划 → 写 orchestrate-report
把两方体检结果合并写到 00-Index/_system/orchestrate-report.md，至少包含：
- 概览：结构（漂移/坏链/缺marker）、策展（孤儿/缺用途/收件箱）两组数字。
- 建议行动计划：模型依据
references/decision-guide.md 的建议，列出本次建议执行的
阶段、每阶段建议命令 + 参数、是否需用户确认、可跳过的空阶段。
- 建议执行顺序：默认「结构 → 策展」，模型可据体检调整或跳过。
- 本次已执行（run 结束时回填；scan 时留空）。
模型判断点（参 decision-guide.md，全部建议性）：哪些阶段跳过 / 执行、项目落哪个系统、
敏感内容是否纳入、坏链是改名导致还是真悬空。
第 3 步：呈现计划，等待批准
向用户用简短摘要呈现 orchestrate-report 的「建议行动计划」，等待批准。
scan 命令到此为止：报告已写，不进入任何写阶段。run 命令：用户批准后进入第 4 步。
第 4 步：逐阶段执行（run）
按默认序「结构 → 策展」执行，模型可据体检跳过空阶段。每个阶段：
- 阶段检查点：进入前给一行摘要（"接下来做 X，将调用 Y"），等用户确认。
- 内联执行子 SKILL.md：读对应子 skill 的 SKILL.md，按其步骤执行；子 skill 自身的
AskUserQuestion 关卡、备份、红线照常生效。
- 阶段小结：给一行结果（"已 apply N 个结构文件 / 补 N 处用途"）。
各阶段对应（命令与边界详见 references/sub-skills.md，均为建议，模型按需调整）：
- 结构层 →
wiki-struct：通常 struct_gen.py check 后，按需 apply [--scope ...]；
缺 marker 先按其 SKILL.md 走 init。
- 策展收尾 →
wiki-curate：内容向策展——ingest（收件箱归类）、curate（补「用途」、
英文标签改中文、在正文补双链修复孤儿）、lint（跑 lint.py lint + LLM 判断过时/矛盾）。
注意：坏链与结构漂移归 wiki-struct，不归 wiki-curate lint。 命令对你开放，是否调用由你按需判断，不写死。
第 5 步：收尾
- 回填 orchestrate-report 的「本次已执行」段（哪些阶段跑了、各自结果）。
- 向
00-Index/_system/wiki-log.md 追加一行：
- YYYY-MM-DD HH:MM wiki-orchestrate run (结构: <动作>, 策展: <动作>)
红线与约束
| 红线 | 说明 |
|---|
| 入口不直接改内容笔记 | 所有写操作委托给子 skill，并继承子 skill 红线：SpecIn 只读；10-Work/ 只读（原 知识库/ 写口袋属已剥离的 spec-distill）；敏感目录只路径级；wiki-struct 只改受管块 |
| 双层确认 | 阶段间检查点（本入口）+ 子 skill 内置 AskUserQuestion 关卡，二者都保留 |
| 改前必读 | 编辑任何 .md 前先 Read |
| 写后写日志 | 任何写动作所在回合 append 00-Index/_system/wiki-log.md |
| 破坏性/批量前备份 | 由被调用的子 skill 各自负责（tar 到各自 backup 目录） |
| 外置盘检查 | vault 含 /Volumes/ 时先确认挂载；失败报错停止 |
| 不联网 | 全程不外发 vault 内容 |
跨平台
- 代码（本插件）/ 配置（家目录）/ 数据（vault）三者解耦：代码随插件安装（脚本用本 skill base directory 相对路径定位），各库结构配置在家目录注册表
~/.config/obsidian-wiki/configs/<名>.json，vault 根由 registry.py resolve 给。零位置、零结构硬编码，库内不再有 .wiki/。
- 子脚本
struct_gen.py / lint.py 用 Python 标准库、UTF-8、不依赖外部包；调用一律传 --vault "<vault>"（必填），脚本经 load_config 按 vault 路径在注册表里取该库配置（未注册则回退库内 <vault>/.wiki/config.json）。
- 别人安装 =
/plugin 装 obsidian-wiki → registry.py register --name <名> --path <vault> --config-from config.example.json → 按库改 configs/<名>.json → 跑，无需改代码。
与其它 skill 的关系
- 编排入口，与
wiki-struct /
wiki-curate 同属本插件 skills/，通过调用它们（用本 skill base directory 相对路径 ../<name>/scripts/… 跑其脚本 + 内联读子 SKILL.md）完成整理，自身不重复实现其功能。
- 两个子 skill 的能力、命令、红线、触发信号详见
references/sub-skills.md。
- 下一步该调用谁的判断建议详见
references/decision-guide.md（建议性，最终由模型裁量）。
References
references/sub-skills.md —— 两个子 skill 能力说明（权威：能干什么、怎么调、读写边界、红线、触发信号）references/decision-guide.md —— 启发式建议（体检信号 → 倾向调用哪个 skill/命令/参数；非规则）
