wiki

Wiki 编排

将已安装的产品视为代码，将所选用户 vault 视为数据。绝不要将插件／产品根目录用作 vault，即使当前目录恰好是产品检出目录也不例外。

从此技能的安装位置解析可移植核心，并通过绝对路径调用：

CORE=/absolute/product/root/scripts/claude-obsidian.py
python3 "$CORE" --help

按以下顺序解析 vault：显式指定的 --vault、CLAUDE_OBSIDIAN_VAULT、最近的 .claude-obsidian.json，然后是当前目录及其上级目录中明确无歧义且已初始化的 vault。如果缺少选择或存在歧义，则安全失败。

基线设置无需访问网络。除非用户另行批准目标位置和预算，否则不要获取模板、插件或远程内容。

设置 vault

使用确定性设置命令。两条命令默认都以试运行方式执行。

要创建一个新的独立 vault：

python3 "$CORE" init /absolute/path/to/vault \
  --generated-at <ISO-UTC> --operation-id init-reviewed
python3 "$CORE" init /absolute/path/to/vault \
  --generated-at <ISO-UTC> --operation-id init-reviewed \
  --approved-plan-sha256 <reviewed-sha256> --apply

要使用现有的 Obsidian vault：

python3 "$CORE" adopt /absolute/path/to/vault \
  --generated-at <ISO-UTC> --operation-id adopt-reviewed
python3 "$CORE" adopt /absolute/path/to/vault \
  --generated-at <ISO-UTC> --operation-id adopt-reviewed \
  --approved-plan-sha256 <reviewed-sha256> --apply

执行 --apply 之前，先显示所选路径和变更路径预览，然后原样传入输出的 approved_plan_sha256。除非用户已查看冲突并明确批准替换，否则不要使用 --force。设置默认不会破坏数据，也不会创建上游 Git 远程仓库。

如果用户要求搭建特定领域的脚手架，先建立基线，然后阅读 modes.md。将附加页面和配置作为一次操作级事务起草。绝不要使用宿主的 Write/Edit 工具或 Obsidian 传输来修改 vault 文件。

路由操作

按用户意图进行路由，不要擅自扩大范围：

意图	技能
摄取提供的来源	wiki-ingest
根据现有 vault 知识作答	wiki-query
保存特定对话的结果	save
在预算内研究公开网络	autoresearch
检查 vault 健康状况	wiki-lint
起草带引用的术语表或整合重叠笔记	wiki-ingest，并明确审核范围
汇总日志条目	wiki-fold
使用画布	canvas

查询为只读操作。查询产生的持久化内容必须通过明确且单独界定范围的 Save 操作完成。绝不要仅因为会话结束，就捕获对话记录或更新热缓存。

变更约定

在执行任何自定义脚手架搭建或变更之前，阅读 operation-transactions.md。一个逻辑操作必须生成一个经过检查且可恢复的 claude-obsidian.transaction.v1 捆绑包。并行 Agent 只能返回草稿和证据；由编排器合并后一次性应用。每次创建或移除规范页面，都必须在该捆绑包中更新活动索引或 MOC；仅当稳定的高层概况发生变化时才更新概览。原始来源载荷只能新建。不会自动提交。

初始化或更改来源台账和声明台账时，使用 provenance.md。不受支持的证据仍应标记为不受支持；绝不要捏造来源、引文、日期、定位信息或置信度。

成功应用后，报告操作 ID 和确切的变更路径。如果用户明确要求 Git 检查点，请单独执行：

python3 "$CORE" checkpoint OPERATION_ID --vault /absolute/path/to/vault

发生冲突时，重新读取并重建。操作中断时，使用 transaction recover。只有在捆绑包完全相同的情况下才能重用操作 ID。

安装环境

当安装或宿主行为相关时，阅读 install-modes.md。Hook 是可选适配器；可移植行为由核心和技能提供。

条件引用

仅在当前请求需要时阅读相应引用：

• 定义或采用属性架构时，阅读 frontmatter.md；
• 按请求进行 Obsidian 视觉自定义时，阅读 css-snippets.md；
• 明确要求设置本地 Git 或检查点时，阅读 git-setup.md；
• 评估可选的 Obsidian 集成时，阅读 plugins.md；
• 用户要求评估外部读取传输方式时，阅读 mcp-setup.md；
• 用户明确使用或请求 Local REST API 适配器时，才阅读 rest-api.md；
• 已有可选的 Dataview 设置时，阅读 dataview.md；
• 进行有引用依据的词汇表或整合工作时，阅读 knowledge-recipes.md；
• 涉及外部编辑器或多台设备时，阅读 coordination.md；
• 需要带版本的原生验收证据时，阅读 native-conformance.md；
• 需要了解容量限制或可恢复的旧版压缩时，阅读 capacity-and-recovery.md；
• 需要协调固定版本的外部语法或设计参考时，阅读 upstream-references.md。
• 评估模型、更换生成适配器或验证特定宿主的提示词时，阅读 model-guidance.md。

思考、验证、迭代

执行前，先暂停一次：观察现有状态，验证库的选择和证据，然后选择能满足请求的最小可逆操作。完成后，说明不确定之处和下一项有用的改进，但不要自动执行该改进。