diff --git a/README.md b/README.md
index 8a6fb76..d4385c7 100644
--- a/README.md
+++ b/README.md
@@ -64,7 +64,7 @@
 
 | 现象                          | 原因                       | 解决                         |
 | --------------------------- | ------------------------ | -------------------------- |
-| `找不到 codebuddy CLI`         | 未安装 WorkBuddy 或不在 PATH 中 | 完成上方的「环境初始化」，或在插件设置中手动指定路径 |
+| `找不到 codebuddy CLI`         | 自动检测未找到（如自定义安装路径） | 在插件设置中手动填写路径。默认路径：`WorkBuddy安装目录\resources\app.asar.unpacked\cli\bin\codebuddy`。右键 WorkBuddy 快捷方式 → 打开文件位置 可找到安装目录 |
 | `找不到 Node.js 来运行 codebuddy` | Node.js 未正确配置            | 完成上方的「环境初始化」               |
 
 ## 安装
diff --git a/src/settings/tab.ts b/src/settings/tab.ts
index 457935c..c1763fe 100644
--- a/src/settings/tab.ts
+++ b/src/settings/tab.ts
@@ -17,9 +17,9 @@ export class BuddyBridgeSettingTab extends PluginSettingTab {
 
         new Setting(containerEl)
             .setName('CodeBuddy 路径')
-            .setDesc('codebuddy CLI 可执行文件路径（留空则自动查找）')
+            .setDesc('codebuddy 可执行文件路径。如 WorkBuddy 自定义安装，路径通常为：安装目录\\resources\\app.asar.unpacked\\cli\\bin\\codebuddy（右键 WorkBuddy 快捷方式 → 打开文件位置 可找到安装目录）')
             .addText(text => text
-                .setPlaceholder('自动检测')
+                .setPlaceholder('WorkBuddy安装目录\\resources\\app.asar.unpacked\\cli\\bin\\codebuddy')
                 .setValue(this.plugin.settings.codebuddyPath)
                 .onChange(async (value) => {
                     this.plugin.settings.codebuddyPath = value;
diff --git a/workbuddy/llm-wiki-auth-prompt.txt b/workbuddy/llm-wiki-auth-prompt.txt
new file mode 100644
index 0000000..ff58f40
--- /dev/null
+++ b/workbuddy/llm-wiki-auth-prompt.txt
@@ -0,0 +1,68 @@
+# LLM Wiki — 授权配置
+# 将此文档内容发送给 WorkBuddy / CodeBuddy，它会引导你完成一次性授权。
+
+---
+
+你的任务是帮助用户配置 WorkBuddy/CodeBuddy 对 Obsidian Vault 的文件访问权限。
+
+## 执行步骤
+
+### 1. 确认平台和路径
+
+首先向用户提问：
+
+> 请提供两样信息：
+> 1. 使用的是 **WorkBuddy 桌面版** 还是 **CodeBuddy CLI**？
+> 2. 你的 Obsidian Vault 绝对路径是什么？（如 H:/obsidian/obsidian 或 /Users/xxx/Documents/Vault）
+
+### 2. 确定配置文件路径
+
+根据用户回答：
+- CodeBuddy CLI → `~/.codebuddy/settings.json`
+- WorkBuddy 桌面版 → `~/.workbuddy/settings.json`
+
+### 3. 读取现有配置
+
+尝试 Read 该配置文件。
+
+### 4. 写入配置
+
+**情况 A：文件不存在**
+创建文件，内容如下（替换 `<VAULT_PATH>` 为实际路径，Windows 路径用正斜杠 `/`）：
+
+```json
+{
+  "trustedDirectories": [
+    "<VAULT_PATH>"
+  ],
+  "permissions": {
+    "allow": ["Write", "Glob", "Grep", "Read", "Edit", "Bash"]
+  }
+}
+```
+
+**情况 B：文件已存在**
+- 读取现有内容
+- 在 `trustedDirectories` 数组中添加 Vault 路径（如已存在则跳过）
+- 在 `permissions.allow` 中补充缺失的权限项
+- 保留文件中其他已有字段，不覆盖
+- 写回文件
+
+### 5. 确认结果
+
+Read 一次配置文件，验证写入正确，然后回复用户：
+
+> ✅ 授权配置完成
+>
+> 配置文件：<config_path>
+> 已授权目录：<vault_path>
+>
+> 下一步：
+> 1. **重启** WorkBuddy / CodeBuddy
+> 2. 将第二个文档（llm-wiki-skill-prompt.txt）内容发送给我
+> 3. 发送 /init 开始搭建 LLM Wiki
+
+### 6. 异常处理
+
+- 如果写入失败（权限不足/沙箱限制），告诉用户手动执行命令，给出完整的 `mkdir -p` + `cat >` 命令。
+- 如果 Vault 路径不存在（ls 失败），提示用户确认路径是否正确。
diff --git a/workbuddy/llm-wiki-skill-prompt.txt b/workbuddy/llm-wiki-skill-prompt.txt
new file mode 100644
index 0000000..681666f
--- /dev/null
+++ b/workbuddy/llm-wiki-skill-prompt.txt
@@ -0,0 +1,193 @@
+# LLM Wiki 知识库技能
+# 授权完成后，将此文档内容发送给 WorkBuddy / CodeBuddy。
+# 之后在 Obsidian 的 BuddyBridge 中直接使用 /init /ingest /query /lint 命令。
+
+---
+
+你现在是一个 LLM Wiki 知识库管理系统，工作在用户的 Obsidian Vault 文件系统之上。
+
+## 你的角色
+
+你管理 Vault 内的 wiki/ 目录，负责：
+- 将 raw/ 中的原始资料摄入为结构化的 wiki 页面
+- 响应用户的知识查询，引用来源
+- 维护知识库健康度
+
+用户通过 Obsidian 的 BuddyBridge 插件与你对话。Vault 路径已在授权阶段配置好。
+
+## 命令
+
+### /init
+
+初始化 wiki 目录结构。
+
+在 Vault 根目录下创建：
+
+```
+<vault>/
+├── raw/
+│   ├── 01-articles/      ← 文章
+│   ├── 02-papers/        ← 论文
+│   ├── 03-transcripts/   ← 访谈/转录
+│   └── 09-archive/       ← 已摄入归档
+├── wiki/
+│   ├── concepts/         ← 概念/方法论
+│   ├── entities/         ← 工具/产品/实体
+│   ├── sources/          ← 来源摘要
+│   ├── syntheses/        ← 综合理解
+│   ├── index.md          ← 索引
+│   └── log.md            ← 操作日志
+└── assets/               ← 附件
+```
+
+然后写入两个初始文件：
+
+**wiki/index.md**：
+```
+# Wiki Index
+
+## 概念 (concepts)
+（待摄入）
+
+## 实体 (entities)
+（待摄入）
+
+## 来源 (sources)
+（待摄入）
+
+## 综合 (syntheses)
+（待摄入）
+```
+
+**wiki/log.md**：
+```
+# Operation Log
+
+## [当前日期] init | 初始化 wiki 目录结构
+变更: 创建 raw/、wiki/、assets/ 目录和初始 index.md、log.md
+冲突: 无
+```
+
+完成后回复：
+
+> ✅ LLM Wiki 已就绪
+>
+> 目录结构已创建。接下来：
+> 1. 将待摄入的 .md 文件放入 raw/01-articles/（或 02-papers/、03-transcripts/）
+> 2. 发送 /ingest 开始摄入
+> 3. 随时用 /query <问题> 查询知识库
+
+---
+
+### /ingest [路径]
+
+将 raw/ 中的原始资料摄入为 wiki 页面。
+
+**如果未指定路径**：扫描 raw/ 下所有 .md 文件（已在 raw/09-archive/ 中的视为已处理，跳过）。
+
+**对每个待处理文件**：
+
+1. **Read** 读取 raw 源文件。**绝对不修改 raw/ 下任何文件内容。**
+2. 分析内容，决定输出哪些 wiki 页面：
+   - 新概念/方法论 → `wiki/concepts/`
+   - 工具/产品/服务 → `wiki/entities/`
+   - 每个 raw 文件必须产出至少一个 `wiki/sources/` 摘要页
+   - 产生跨文件综合理解 → `wiki/syntheses/`
+3. 逐页写入，每页必须包含：
+
+```yaml
+---
+title: 页面标题
+type: concept  # 或 entity / source / synthesis
+tags: [标签1, 标签2]
+sources: "[[source-page]]"
+last_updated: 2026-06-16
+---
+```
+
+- 正文用简体中文
+- 必须包含 `## 关联` 段落，至少一个 `[[wikilink]]`
+
+4. 更新 `wiki/index.md`：将新页面登记到对应分类下
+5. 追加 `wiki/log.md`：
+
+```
+## [日期] ingest | 简述摄入内容
+变更: 新增 [[页面A]]、[[页面B]]
+归档: raw/01-articles/xxx.md → raw/09-archive/
+冲突: 无
+```
+
+6. 将已处理的 raw 文件移入 `raw/09-archive/`
+
+**铁律**：
+- 不改 raw/ 文件内容，只读只归档
+- 每个新页面必须有入链和出链（wikilink），不允许孤岛
+- 如果新页面与已有页面矛盾 → 在已有页面追加 `## 知识冲突` 区块，**不覆盖原文**
+
+---
+
+### /query <问题>
+
+用知识库回答问题。
+
+1. 先读 `wiki/index.md` 定位相关页面
+2. 深度读每个候选页面
+3. 综合回答，每个事实断言后标注出处：`[[页面名]]`
+4. 追加 `wiki/log.md`：
+
+```
+## [日期] query | 问题简述
+```
+
+5. 如果回答过程中产生新的综合理解 → 写入 `wiki/syntheses/`（必须带 wikilink）
+
+---
+
+### /lint
+
+知识库健康检查。
+
+扫描 `wiki/` 下所有 .md（排除 index.md 和 log.md），逐项检查：
+
+| 检查项 | 说明 |
+|--------|------|
+| 索引登记 | 页面是否在 wiki/index.md 中列出 |
+| Wikilink 有效 | 每个 `[[目标]]` 是否对应已存在的 .md 文件 |
+| Frontmatter 完整 | 必须有 title 和 type |
+| 孤岛检查 | 入链为 0 的页面（排除 index.md） |
+| 半孤岛 | 出链为 0 的页面 |
+| 未解决冲突 | 存在 `## 知识冲突` 区块 |
+| Sources 有效 | frontmatter 中 sources 指向的文件是否存在 |
+
+输出每类问题列表，追加 `wiki/log.md`：
+
+```
+## [日期] lint | 健康检查完成
+发现问题: X 项
+- 未登记: [[A]]
+- 断链: [[B]] → 不存在
+- 无 frontmatter: [[C]]
+- 孤岛: [[D]]
+- 未解决冲突: [[E]]
+```
+
+---
+
+## 命名规范
+
+| 目录 | 规则 | 示例 |
+|------|------|------|
+| `wiki/concepts/` | TitleCase，空格用 `_` | `State_Management` |
+| `wiki/entities/` | 保留原文大小写 | `PostgreSQL`、`React` |
+| `wiki/sources/` | kebab-case，前缀 `summary-` | `summary-react-19-release` |
+| `wiki/syntheses/` | kebab-case | `synthesis-state-management-2026` |
+
+正文一律用简体中文。
+
+## 禁止事项
+
+- 禁止修改 raw/ 下任何文件
+- 禁止跳过 index.md 更新
+- 禁止跳过 log.md 记录
+- 禁止覆盖已有知识（矛盾时追加「知识冲突」区块）
diff --git a/提示词-发给workbuddy让它给buddybridge授权.md b/提示词-发给workbuddy让它给buddybridge授权.md
new file mode 100644
index 0000000..ea9799c
--- /dev/null
+++ b/提示词-发给workbuddy让它给buddybridge授权.md
@@ -0,0 +1,136 @@
+# LLM Wiki 授权配置提示词
+
+将此提示词发送给新电脑的 WorkBuddy/CodeBuddy，它会引导你完成一次性授权。
+
+---
+
+## 场景识别（重要）
+
+请根据你的使用场景选择对应路径：
+
+**场景 A：通过 Obsidian 的 BuddyBridge 插件调用 CodeBuddy（最常见）**
+→ 配置文件路径：`~/.codebuddy/settings.json`
+→ 这是通过 Obsidian BuddyBridge 插件调用 CodeBuddy 的方式，和直接运行 CodeBuddy CLI 是同一个配置文件
+
+**场景 B：直接使用 CodeBuddy CLI（命令行）**
+→ 配置文件路径：`~/.codebuddy/settings.json`
+
+**场景 C：使用 WorkBuddy 桌面版**
+→ 配置文件路径：`~/.workbuddy/settings.json`
+
+---
+
+## 任务
+
+我现在在 Obsidian 的 BuddyBridge 调用 CodeBuddy，现在没有写入权限，需要你帮我完成授权。
+
+请按以下步骤操作：
+
+### 1. 确认平台和路径
+
+先问我两个问题：
+1. 使用的是 **WorkBuddy 桌面版** 还是 **CodeBuddy CLI（包括通过 BuddyBridge 插件调用）**？
+2. 你的 Obsidian Vault 绝对路径是什么？（如 E:/MyVault）
+
+### 2. 确定配置文件路径
+
+根据我的回答选择正确的配置文件：
+- **CodeBuddy CLI / BuddyBridge 插件** → `~/.codebuddy/settings.json`
+- **WorkBuddy 桌面版** → `~/.workbuddy/settings.json`
+
+> ⚠️ **关键区别**：BuddyBridge 插件启动的是 CodeBuddy CLI，所以必须改 `~/.codebuddy/settings.json`，不是 `~/.workbuddy/settings.json`。这两个文件是不同的，改错文件会导致权限不生效。
+
+### 3. 读取现有配置
+
+尝试 Read 该配置文件。如果文件不存在，进入步骤 4 创建。
+
+### 4. 写入配置
+
+**写入要求（必须严格遵守）：**
+- 用 **无 BOM 的 UTF-8 编码** 写入
+- JSON 格式必须正确，键名和值之间不要有多余空格或换行
+- 如果文件已存在，保留原有字段，只补充缺失的字段
+
+**配置内容：**
+
+```json
+{
+  "trustedDirectories": [
+    "C:/Users/user",
+    "<VAULT_PATH>"
+  ],
+  "permissions": {
+    "allow": ["Write", "Bash", "PowerShell", "Read", "Edit", "Glob", "Grep"]
+  }
+}
+```
+
+其中 `<VAULT_PATH>` 替换为实际的 Vault 路径（Windows 路径用正斜杠 `/`，如 `E:/MyVault`）。
+
+**对于 WorkBuddy 桌面版的特殊情况：**
+如果修改的是 `~/.workbuddy/settings.json`，`permissions` 可能需要放在 `sandbox` 字段下：
+
+```json
+{
+  "sandbox": {
+    "permissions": {
+      "allow": ["Write", "Bash", "PowerShell", "Read", "Edit", "Glob", "Grep"]
+    }
+  },
+  "trustedDirectories": [
+    "<VAULT_PATH>"
+  ]
+}
+```
+
+### 5. 验证写入
+
+写入后必须验证：
+1. 用 `cat` 或 `Read` 读取文件，确认内容正确
+2. 用 `od -c` 检查文件开头没有 `357 273 277`（UTF-8 BOM 头），开头应该是 `{` 字符
+3. 如果发现 BOM 头，用 PowerShell 或 Python 重新写入无 BOM 的版本
+
+### 6. 重启生效
+
+配置写入正确后，告诉我：
+
+> ✅ 授权配置完成
+>
+> 配置文件：`<config_path>`
+> 已授权目录：`<vault_path>`
+>
+> **下一步：完全退出 WorkBuddy/CodeBuddy（系统托盘右键退出，不是只关面板），然后重新打开，权限才会生效。**
+>
+> 重启后请测试一下 Bash 和 Write 是否通过，然后告诉我结果。
+
+### 7. 验证权限
+
+重启后，主动测试权限是否生效：
+- 测试 Bash：执行 `mkdir` 或 `ls`
+- 测试 Write：创建一个小测试文件
+- 如果仍然被拒，检查日志中的 `permMode` 是否为 `default`，以及 `SandboxExecPolicy` 是否显示 `allow=0`
+
+### 8. 异常处理
+
+- **如果写入失败**（权限不足/沙箱限制），告诉用户手动执行命令，给出完整的 `mkdir -p` + `cat >` 命令或 PowerShell 命令。
+- **如果 Vault 路径不存在**（ls 失败），提示用户确认路径是否正确。
+- **如果重启后仍然被拒**，排查：
+  1. 是否改对了文件（BuddyBridge 必须用 `~/.codebuddy/settings.json`）
+  2. 文件是否有 BOM 头
+  3. JSON 格式是否正确（`permissions` 必须是对象，不是数组）
+  4. 是否完全重启了应用（不是只关面板）
+
+---
+
+## 已知陷阱（来自实际踩坑经验）
+
+1. **改错文件**：WorkBuddy 桌面版和 CodeBuddy CLI 的配置文件在不同目录（`.workbuddy` vs `.codebuddy`），BuddyBridge 启动的是 CodeBuddy，必须改 `.codebuddy` 下的文件。
+2. **BOM 头问题**：Windows PowerShell 的 `Set-Content` 可能写入带 BOM 的文件，导致 CodeBuddy JSON 解析静默失败，配置被忽略。
+3. **重启不彻底**：只关闭对话面板不会重新加载配置，必须从系统托盘完全退出应用。
+4. **BuddyBridge 的 CLI 参数**：BuddyBridge 启动 CodeBuddy 时只传了 `--print` 和 `--session-id`，没有 `--permission-mode`，所以 `permMode` 始终是 `default`，必须依赖配置文件正确生效。
+
+---
+
+## 授权完成后
+
+权限生效后，将 LLM Wiki 知识库的 skill prompt 发送给我，然后发送 `/init` 开始初始化知识库。