openfeel 1.0.0 → 1.0.2

package/dist/core/update.js

@@ -230,107 +230,107 @@ description: 标准化 Bug 验收流程，供测试 Agent 或代码 Agent（自
 
 验收通过后，核心结论写入 \`.openfeel/bugs/{module}.md\`，并在公共日志简要记录。
 `,
-    'check-kb': `---
-name: check-kb
-description: 渐进式查阅 .openfeel/kb/ 项目知识库，按当前任务需求返回最相关的参考信息。精确匹配无结果时自动触发语义检索回退，避免一次加载全量内容。
----
-
-# 查阅知识库
-
-## 输入
-
-无（自动按当前任务上下文推断阅读范围）
-
-## 执行步骤
-
-### 1. 读取总索引
-
-读取 \`.openfeel/kb/index.md\`，获取所有分类文件的摘要和最近更新时间。
-
-### 2. 匹配相关分类
-
-根据当前任务特征，确定需要查阅的分类：
-
-| 任务特征 | 优先查阅 |
-|----------|----------|
-| 新功能开发、架构变更 | \`architecture.md\` |
-| 代码编写、重构 | \`patterns.md\` |
-| 编译/运行报错 | \`troubleshooting.md\` |
-| 环境搭建、依赖变更 | \`setup.md\` |
-| 跨领域任务或不熟悉模块 | 全部 \`index.md\` 摘要 |
-
-### 3. 提取相关条目
-
-读取匹配的分类文件，提取与当前任务相关的 \`[+]\` 条目。不加载标记为 \`[-]\` 的已禁用条目。
-
-### 4. 输出摘要
-
-按以下格式输出：
-
-\`\`\`
-📁 知识库查阅结果（{分类}）
-
-[index.md 中的分类摘要]
-
-相关条目：
-- [architecture] "登录流程使用 OAuth2..." — 与当前任务相关：是
-- [troubleshooting] "Module not found 时运行 npm ci" — 与当前任务相关：否
-\`\`\`
-
-若无相关条目，输出：\`知识库中暂无与当前任务相关的记录。\`
-
-### 5. 语义检索回退（自动）
-
-当精确匹配未找到任何相关条目（无 \`[+]\` 条目或所有条目与当前任务无关）时，**本技能自行执行语义检索**，无需调用方另行加载 \`search-kb\`：
-
-1. **索引就绪检查**：检查 \`.openfeel/tmp/vectors/index.json\` 是否存在
-2. **索引缺失时**：输出以下提示后结束，不再继续回退：
-   \`\`\`
-   💡 精确匹配未找到相关条目，语义检索的向量索引尚未构建。
-
-      运行以下命令构建索引后再重试：
-      pip install sentence-transformers
-      python scripts/build_kb_index.py
-   \`\`\`
-3. **索引就绪时**：从当前任务上下文中提取关键词和需求描述，构造查询文本，执行：
-   \`\`\`
-   python scripts/search_kb.py "<查询文本>" --top-k 10 --verbose
-   \`\`\`
-4. **解析并输出**：将检索结果格式化输出：
-
-   \`\`\`
-   💡 精确匹配未找到相关条目，已自动回退到语义检索。
-
-   🔍 语义检索结果（共 {N} 条）
-
-     #{1} [{分类}] {条目标题}
-       文件: {分类}.md | 得分: {score}
-       内容: {摘要}
-
-     #{2} ...
-   \`\`\`
-
-5. **低分提示**：若所有结果得分均低于 0.3，追加提示：
-   \`\`\`
-   ⚠️ 所有语义检索结果得分均低于 0.3，建议优化查询词或确认知识库覆盖范围。
-   \`\`\`
-
-6. **索引过期提示**：检索完成后追加：
-   \`\`\`
-   💡 如需确保索引为最新，可运行: python scripts/build_kb_index.py --dry-run
-   \`\`\`
-
-> 注：语义检索是 \`check-kb\` 的内置回退能力。调用方只需 \`skill("check-kb")\` 一次，无需再手动调用 \`search-kb\`。
-
-### 6. 强制检索标记
-
-Skill 加载后，根据步骤 3 的匹配结果决定是否追加提示：
-
-- **若步骤 3 找到 ≥1 条相关条目**：在返回内容末尾追加以下提示：
-  > ⚠️ 执行任务前，若知识库中有相关条目，务必参考。重复踩过的坑不可再犯。
-  此提示确保 Agent 不会跳过知识库查询直接编码。
-
-- **若步骤 3 无相关条目**：不追加强制提示，静默返回（已在步骤 4 输出"知识库中暂无相关记录，可继续执行"）。
+    'check-kb': `---
+name: check-kb
+description: 渐进式查阅 .openfeel/kb/ 项目知识库，按当前任务需求返回最相关的参考信息。精确匹配无结果时自动触发语义检索回退，避免一次加载全量内容。
+---
+
+# 查阅知识库
+
+## 输入
+
+无（自动按当前任务上下文推断阅读范围）
+
+## 执行步骤
+
+### 1. 读取总索引
+
+读取 \`.openfeel/kb/index.md\`，获取所有分类文件的摘要和最近更新时间。
+
+### 2. 匹配相关分类
+
+根据当前任务特征，确定需要查阅的分类：
+
+| 任务特征 | 优先查阅 |
+|----------|----------|
+| 新功能开发、架构变更 | \`architecture.md\` |
+| 代码编写、重构 | \`patterns.md\` |
+| 编译/运行报错 | \`troubleshooting.md\` |
+| 环境搭建、依赖变更 | \`setup.md\` |
+| 跨领域任务或不熟悉模块 | 全部 \`index.md\` 摘要 |
+
+### 3. 提取相关条目
+
+读取匹配的分类文件，提取与当前任务相关的 \`[+]\` 条目。不加载标记为 \`[-]\` 的已禁用条目。
+
+### 4. 输出摘要
+
+按以下格式输出：
+
+\`\`\`
+📁 知识库查阅结果（{分类}）
+
+[index.md 中的分类摘要]
+
+相关条目：
+- [architecture] "登录流程使用 OAuth2..." — 与当前任务相关：是
+- [troubleshooting] "Module not found 时运行 npm ci" — 与当前任务相关：否
+\`\`\`
+
+若无相关条目，输出：\`知识库中暂无与当前任务相关的记录。\`
+
+### 5. 语义检索回退（自动）
+
+当精确匹配未找到任何相关条目（无 \`[+]\` 条目或所有条目与当前任务无关）时，**本技能自行执行语义检索**，无需调用方另行加载 \`search-kb\`：
+
+1. **索引就绪检查**：检查 \`.openfeel/tmp/vectors/index.json\` 是否存在
+2. **索引缺失时**：输出以下提示后结束，不再继续回退：
+   \`\`\`
+   💡 精确匹配未找到相关条目，语义检索的向量索引尚未构建。
+
+      运行以下命令构建索引后再重试：
+      pip install sentence-transformers
+      python scripts/build_kb_index.py
+   \`\`\`
+3. **索引就绪时**：从当前任务上下文中提取关键词和需求描述，构造查询文本，执行：
+   \`\`\`
+   python scripts/search_kb.py "<查询文本>" --top-k 10 --verbose
+   \`\`\`
+4. **解析并输出**：将检索结果格式化输出：
+
+   \`\`\`
+   💡 精确匹配未找到相关条目，已自动回退到语义检索。
+
+   🔍 语义检索结果（共 {N} 条）
+
+     #{1} [{分类}] {条目标题}
+       文件: {分类}.md | 得分: {score}
+       内容: {摘要}
+
+     #{2} ...
+   \`\`\`
+
+5. **低分提示**：若所有结果得分均低于 0.3，追加提示：
+   \`\`\`
+   ⚠️ 所有语义检索结果得分均低于 0.3，建议优化查询词或确认知识库覆盖范围。
+   \`\`\`
+
+6. **索引过期提示**：检索完成后追加：
+   \`\`\`
+   💡 如需确保索引为最新，可运行: python scripts/build_kb_index.py --dry-run
+   \`\`\`
+
+> 注：语义检索是 \`check-kb\` 的内置回退能力。调用方只需 \`skill("check-kb")\` 一次，无需再手动调用 \`search-kb\`。
+
+### 6. 强制检索标记
+
+Skill 加载后，根据步骤 3 的匹配结果决定是否追加提示：
+
+- **若步骤 3 找到 ≥1 条相关条目**：在返回内容末尾追加以下提示：
+  > ⚠️ 执行任务前，若知识库中有相关条目，务必参考。重复踩过的坑不可再犯。
+  此提示确保 Agent 不会跳过知识库查询直接编码。
+
+- **若步骤 3 无相关条目**：不追加强制提示，静默返回（已在步骤 4 输出"知识库中暂无相关记录，可继续执行"）。
 `,
     'get-bugs': `---
 name: get-bugs
@@ -369,132 +369,132 @@ description: 获取当前模块下状态为 open 或 fixing 的 Bug 列表，供
 
 输出：\`模块 [模块名] 当前无待处理 Bug。\`
 `,
-    'get-stage-status': `---
-name: get-stage-status
-description: 读取 .openfeel/plan/{stage}/status.md，判断当前子计划状态、责任 Agent、是否允许自动推进以及下一步建议。用于 Reviewer/Executor/Feel Tester 在处理阶段任务前确认流程状态。
----
-
-# 获取子计划状态
-
-## 输入
-
-- 计划阶段名 \`{stage}\`（如 \`stage01\`、\`auth-login\`）
-- 若用户未提供阶段名，先读取 \`.openfeel/plan/index.md\` 查找当前活跃阶段；仍不明确时询问用户
-
-## 执行步骤
-
-### 0. 读取全局配置
-
-读取 \`.openfeel/config.yaml\`，解析 \`defaults\` 中的 \`execution_mode\`、\`auto_advance\`、\`test_enabled\`、\`merge_mode\`。
-
-### 1. 定位状态文件
-
-读取 \`.openfeel/plan/{stage}/status.md\`。
-
-若文件不存在：
-- 不要自行进入自动流程。
-- 返回 \`missing_status\`，提示需要 Architect 先创建状态文件。
-
-### 2. 提取字段
-
-解析以下字段：
-
-- \`执行模式\`
-- \`自动推进\`
-- \`状态\`
-- \`当前责任 Agent\`
-- \`上一责任 Agent\`
-- \`更新时间\`
-- \`当前任务\`
-- \`阻塞 / 暂停原因\`
-- \`前置依赖\`
-- \`依赖状态\`
-
-### 3. 依赖就绪检查
-
-若 \`status.md\` 中存在 \`前置依赖\` 字段且不为 \`无\`：
-
-1. 读取 \`.openfeel/plan/deps.yaml\`，查找当前阶段的 \`depends_on\` 列表。
-2. 对每条依赖检查其阶段状态：
-   - \`type: hard\` 且依赖阶段状态为 \`done\` → 已满足
-   - \`type: hard\` 且依赖阶段状态非 \`done\` → 未满足，阻塞
-   - \`type: soft\` 且依赖阶段状态为 \`done\` → 已满足
-   - \`type: soft\` 且依赖阶段状态非 \`done\` → 弱阻塞（警告但可启动）
-   - \`type: mutual_exclusion\` 且依赖阶段状态为 \`done\` → 已满足
-   - \`type: mutual_exclusion\` 且依赖阶段状态非 \`done\` → 阻塞，必须等待
-3. 综合判断 \`deps_satisfied\`：
-   - 所有 \`hard\` 和 \`mutual_exclusion\` 依赖满足 → \`true\`
-   - 任一 \`hard\` 或 \`mutual_exclusion\` 依赖未满足 → \`false\`
-4. 若 \`deps.yaml\` 不存在，视为无依赖声明，\`deps_satisfied = true\`。
-
-### 4. 并行候选检测
-
-当 \`deps_satisfied = true\` 时：
-
-1. 读取所有阶段的 \`status.md\`，筛选满足以下条件的阶段：
-   - \`deps_satisfied = true\`（本 Skill 递归判断）
-   - \`状态\` 为 \`ready_for_code\` 或 \`auto_running\`
-   - \`自动推进\` 为 \`enabled\`（若 status.md 未填则回退到 config.yaml \`auto_advance\`）
-2. 收集为 \`parallel_candidates\` 列表，供 Feel 批量调度执行。
-
-### 5. 判断自动推进资格
-
-**字段回退**：若 \`status.md\` 未填写 \`执行模式\` 或 \`自动推进\`，从 \`.openfeel/config.yaml\` \`defaults\` 中读取对应值。
-
-**测试状态排除**：若 \`.openfeel/config.yaml\` 中 \`test_enabled=false\`，则以下测试链路状态视为已禁用，不参与自动推进：
-  - \`ready_for_test\`、\`test_writing\`、\`testing\`、\`bug_found\`、\`bug_fixing\`
-  - 当前处于上述任一状态时，建议直接切换至 \`done\`（跳过测试链路）
-  - \`review_passed\` 在 \`test_enabled=false\` 时等价于 \`done\`
-
-只有同时满足以下条件才返回 \`can_auto_continue = true\`：
-
-- \`执行模式\` 为 \`auto\`
-- \`自动推进\` 为 \`enabled\`
-- \`状态\` 不是 \`done\` 或 \`paused\`
-- \`当前责任 Agent\` 不是 \`user\`
-- \`依赖状态\` 不为 \`blocked\`（所有 hard 依赖必须满足）
-
-否则返回 \`can_auto_continue = false\`，并说明原因。
-
-### 6. 输出格式
-
-\`\`\`markdown
-## 子计划状态
-
-- 阶段：{stage}
-- 执行模式：manual | auto
-- 自动推进：disabled | enabled
-- 状态：{status}
-- 当前责任 Agent：{agent}
-- 前置依赖：{依赖列表 或 无}
-- 依赖就绪：true | false
-- 可自动推进：true | false
-- 阻塞原因：{reason 或 无}
-
-## 并行候选
-{若依赖就绪且可自动推进，列出同批次可并行启动的其他阶段}
-
-## 下一步建议
-{根据状态给出下一步，例如：启动 Code、等待用户、启动 Tester、停止流程；若存在并行候选则建议批量启动}
-\`\`\`
-
-## 状态到下一步映射
-
-| 状态 | 下一步建议 |
-|------|------------|
-| \`planned\` | 等待用户确认或 Planner 细化计划 |
-| \`ready_for_code\` | Planner 可启动 Executor |
-| \`coding\` | Executor 正在开发 |
-| \`ready_for_review\` | Executor 可启动 Reviewer 审查，或等待用户触发 |
-| \`review_failed\` | Reviewer 可启动 Executor 修复审查问题 |
-| \`review_passed\` | Feel 可推进到 ready_for_test |
-| \`ready_for_test\` | Feel 可启动 Feel Tester |
-| \`test_writing\` | Feel Tester 正在写测试 |
-| \`testing\` | Feel Tester 正在测试 |
-| \`bug_found\` | Feel Tester 可启动 Executor 修复 Bug |
-| \`bug_fixing\` | Executor 正在修复 Bug |
-| \`done\` | 流程完成，停止 |
-| \`paused\` | 等待用户处理暂停原因 |
+    'get-stage-status': `---
+name: get-stage-status
+description: 读取 .openfeel/plan/{stage}/status.md，判断当前子计划状态、责任 Agent、是否允许自动推进以及下一步建议。用于 Reviewer/Executor/Feel Tester 在处理阶段任务前确认流程状态。
+---
+
+# 获取子计划状态
+
+## 输入
+
+- 计划阶段名 \`{stage}\`（如 \`stage01\`、\`auth-login\`）
+- 若用户未提供阶段名，先读取 \`.openfeel/plan/index.md\` 查找当前活跃阶段；仍不明确时询问用户
+
+## 执行步骤
+
+### 0. 读取全局配置
+
+读取 \`.openfeel/config.yaml\`，解析 \`defaults\` 中的 \`execution_mode\`、\`auto_advance\`、\`test_enabled\`、\`merge_mode\`。
+
+### 1. 定位状态文件
+
+读取 \`.openfeel/plan/{stage}/status.md\`。
+
+若文件不存在：
+- 不要自行进入自动流程。
+- 返回 \`missing_status\`，提示需要 Architect 先创建状态文件。
+
+### 2. 提取字段
+
+解析以下字段：
+
+- \`执行模式\`
+- \`自动推进\`
+- \`状态\`
+- \`当前责任 Agent\`
+- \`上一责任 Agent\`
+- \`更新时间\`
+- \`当前任务\`
+- \`阻塞 / 暂停原因\`
+- \`前置依赖\`
+- \`依赖状态\`
+
+### 3. 依赖就绪检查
+
+若 \`status.md\` 中存在 \`前置依赖\` 字段且不为 \`无\`：
+
+1. 读取 \`.openfeel/plan/deps.yaml\`，查找当前阶段的 \`depends_on\` 列表。
+2. 对每条依赖检查其阶段状态：
+   - \`type: hard\` 且依赖阶段状态为 \`done\` → 已满足
+   - \`type: hard\` 且依赖阶段状态非 \`done\` → 未满足，阻塞
+   - \`type: soft\` 且依赖阶段状态为 \`done\` → 已满足
+   - \`type: soft\` 且依赖阶段状态非 \`done\` → 弱阻塞（警告但可启动）
+   - \`type: mutual_exclusion\` 且依赖阶段状态为 \`done\` → 已满足
+   - \`type: mutual_exclusion\` 且依赖阶段状态非 \`done\` → 阻塞，必须等待
+3. 综合判断 \`deps_satisfied\`：
+   - 所有 \`hard\` 和 \`mutual_exclusion\` 依赖满足 → \`true\`
+   - 任一 \`hard\` 或 \`mutual_exclusion\` 依赖未满足 → \`false\`
+4. 若 \`deps.yaml\` 不存在，视为无依赖声明，\`deps_satisfied = true\`。
+
+### 4. 并行候选检测
+
+当 \`deps_satisfied = true\` 时：
+
+1. 读取所有阶段的 \`status.md\`，筛选满足以下条件的阶段：
+   - \`deps_satisfied = true\`（本 Skill 递归判断）
+   - \`状态\` 为 \`ready_for_code\` 或 \`auto_running\`
+   - \`自动推进\` 为 \`enabled\`（若 status.md 未填则回退到 config.yaml \`auto_advance\`）
+2. 收集为 \`parallel_candidates\` 列表，供 Feel 批量调度执行。
+
+### 5. 判断自动推进资格
+
+**字段回退**：若 \`status.md\` 未填写 \`执行模式\` 或 \`自动推进\`，从 \`.openfeel/config.yaml\` \`defaults\` 中读取对应值。
+
+**测试状态排除**：若 \`.openfeel/config.yaml\` 中 \`test_enabled=false\`，则以下测试链路状态视为已禁用，不参与自动推进：
+  - \`ready_for_test\`、\`test_writing\`、\`testing\`、\`bug_found\`、\`bug_fixing\`
+  - 当前处于上述任一状态时，建议直接切换至 \`done\`（跳过测试链路）
+  - \`review_passed\` 在 \`test_enabled=false\` 时等价于 \`done\`
+
+只有同时满足以下条件才返回 \`can_auto_continue = true\`：
+
+- \`执行模式\` 为 \`auto\`
+- \`自动推进\` 为 \`enabled\`
+- \`状态\` 不是 \`done\` 或 \`paused\`
+- \`当前责任 Agent\` 不是 \`user\`
+- \`依赖状态\` 不为 \`blocked\`（所有 hard 依赖必须满足）
+
+否则返回 \`can_auto_continue = false\`，并说明原因。
+
+### 6. 输出格式
+
+\`\`\`markdown
+## 子计划状态
+
+- 阶段：{stage}
+- 执行模式：manual | auto
+- 自动推进：disabled | enabled
+- 状态：{status}
+- 当前责任 Agent：{agent}
+- 前置依赖：{依赖列表 或 无}
+- 依赖就绪：true | false
+- 可自动推进：true | false
+- 阻塞原因：{reason 或 无}
+
+## 并行候选
+{若依赖就绪且可自动推进，列出同批次可并行启动的其他阶段}
+
+## 下一步建议
+{根据状态给出下一步，例如：启动 Code、等待用户、启动 Tester、停止流程；若存在并行候选则建议批量启动}
+\`\`\`
+
+## 状态到下一步映射
+
+| 状态 | 下一步建议 |
+|------|------------|
+| \`planned\` | 等待用户确认或 Planner 细化计划 |
+| \`ready_for_code\` | Planner 可启动 Executor |
+| \`coding\` | Executor 正在开发 |
+| \`ready_for_review\` | Executor 可启动 Reviewer 审查，或等待用户触发 |
+| \`review_failed\` | Reviewer 可启动 Executor 修复审查问题 |
+| \`review_passed\` | Feel 可推进到 ready_for_test |
+| \`ready_for_test\` | Feel 可启动 Feel Tester |
+| \`test_writing\` | Feel Tester 正在写测试 |
+| \`testing\` | Feel Tester 正在测试 |
+| \`bug_found\` | Feel Tester 可启动 Executor 修复 Bug |
+| \`bug_fixing\` | Executor 正在修复 Bug |
+| \`done\` | 流程完成，停止 |
+| \`paused\` | 等待用户处理暂停原因 |
 `,
     'health': `---
 name: health
@@ -827,129 +827,129 @@ description: 加载项目路线图，供 Agent 查看版本规划和里程碑。
 
 格式化路线图摘要：版本清单 + 各版本阶段进度
 `,
-    'search-kb': `---
-name: search-kb
-description: 语义检索 .openfeel/kb/ 项目知识库。当精确匹配无结果或任务描述模糊时，通过向量相似度搜索语义相关的知识条目。支持图谱遍历返回关联条目。
----
-
-# 语义检索知识库
-
-## 输入
-
-- \`query\`（必需）：查询文本，描述当前任务需求、遇到的问题或想要查找的知识点。
-- \`top_k\`（可选）：返回结果数量，默认 10。
-- \`min_score\`（可选）：最低分数阈值，默认 0.1。分数低于此值的结果将被过滤。
-
-## 前置条件
-
-- 向量索引已构建（运行 \`python scripts/build_kb_index.py\`）
-- 已安装 \`sentence-transformers\`（\`pip install sentence-transformers\`）
-- 索引文件 \`.openfeel/tmp/vectors/index.json\` 存在
-- （可选）图谱已构建（运行 \`python scripts/build_kb_index.py --graph\`），用于返回关联条目
-
-## 执行步骤
-
-### 1. 检查索引就绪
-
-确认 \`.openfeel/tmp/vectors/index.json\` 文件存在。若不存在，拒绝执行并提示先运行 \`build_kb_index.py\`。
-
-### 2. 执行语义检索
-
-执行 \`python scripts/search_kb.py "<query>" --top-k <top_k> --min-score <min_score> --verbose\`。
-
-### 3. 解析结果
-
-输出格式化的检索结果摘要：
-
-\`\`\`
-🔍 语义检索结果（共 {N} 条）
-
-  #{1} [architecture] OAuth2 登录流程设计
-    文件: architecture.md | 得分: 0.87
-    内容: 采用 Authorization Code Grant 流程...
-
-  #{2} [patterns] 状态机模式使用约定
-    文件: patterns.md | 得分: 0.72
-    内容: 项目中所有状态流转统一使用 Switch + Enum...
-\`\`\`
-
-### 4. 图谱遍历（关联条目发现）
-
-当查询命中条目后，若 \`.openfeel/tmp/graph.json\` 存在且命中条目在其中，按以下步骤执行图谱遍历：
-
-#### 4.1 一度关联（直接关联）
-
-读取 \`graph.json\`，查找命中条目的所有**直接引用**和**被直接引用**的条目：
-
-\`\`\`
-🔗 一度关联条目（直接关联）
-
-  引用 → {N} 个条目：[[条目A]]、[[条目B]]
-  被引用 ← {M} 个条目：[[条目C]]
-\`\`\`
-
-#### 4.2 二度关联（间接关联）
-
-在一度关联的基础上，再展开一层，返回间接关联的条目：
-
-\`\`\`
-🔗🔗 二度关联条目（间接关联）
-
-  引用 → [[条目D]]（经由 [[条目A]]）
-  被引用 ← [[条目E]]（经由 [[条目C]]）
-\`\`\`
-
-二度关联按"经由哪个一度节点"分组展示，便于理解关联路径。
-
-#### 4.3 遍历实现
-
-执行 \`python scripts/kb_graph.py --from "<命中条目标题>" --depth 2\`，解析子图输出提取关联节点和边。
-
-### 5. 智能解读
-
-结合当前任务上下文解读检索结果：
-- 标注与当前任务高度相关的条目
-- 标注可能需要进一步查阅的条目
-- 若所有结果得分均低于 0.3，建议用户优化查询词或确认知识库覆盖范围
-- 若图谱返回的关联条目与检索结果重叠，合并去重并标注来源（语义匹配 / 图谱关联）
-
-## 输出格式
-
-\`\`\`
-## 语义检索结果
-
-查询: "{query}"
-结果数: {N}
-
-{格式化结果列表}
-
-## 关联条目（图遍历）
-
-{一度关联条目列表}
-
-{二度关联条目列表}
-
-### 解读
-- 相关条目（得分 ≥ 0.5）: {count} 条，可直接参考
-- 弱相关条目（0.3 ≤ 得分 < 0.5）: {count} 条，建议进一步确认
-- 低相关条目（得分 < 0.3）: {count} 条，可能不适用
-- 图关联条目（未被语义检索命中）: {count} 条
-\`\`\`
-
-## 参数扩展
-
-新增可选参数：
-
-- \`--with-graph\`：启用图谱遍历返回关联条目（默认启用，若 graph.json 不可用则静默跳过）
-- \`--graph-depth\`：图谱遍历深度，1=一度关联，2=二度关联（默认: 2）
-
-## 注意事项
-
-- 向量索引是缓存层，文件系统始终是 single source of truth。若检索结果与预期不符，检查索引是否过期（运行 \`--dry-run\` 查看变更文件）
-- 图谱链接亦是缓存层，Markdown 文件中 \`[[wikilink]]\` 是真实数据源；图谱可随时通过 \`python scripts/build_kb_index.py --graph\` 重建
-- 语义检索适合模糊查询和探索性搜索，精确关键词匹配优先使用 \`check-kb\`
-- 此技能是 \`check-kb\` 的回退方案——当 \`check-kb\` 精确匹配无结果时可自动调用
-- 图遍历返回的关联条目仅基于已建立的 wikilink 链接，若条目未引用或被引用其他条目，图谱中不会出现对应关联
+    'search-kb': `---
+name: search-kb
+description: 语义检索 .openfeel/kb/ 项目知识库。当精确匹配无结果或任务描述模糊时，通过向量相似度搜索语义相关的知识条目。支持图谱遍历返回关联条目。
+---
+
+# 语义检索知识库
+
+## 输入
+
+- \`query\`（必需）：查询文本，描述当前任务需求、遇到的问题或想要查找的知识点。
+- \`top_k\`（可选）：返回结果数量，默认 10。
+- \`min_score\`（可选）：最低分数阈值，默认 0.1。分数低于此值的结果将被过滤。
+
+## 前置条件
+
+- 向量索引已构建（运行 \`python scripts/build_kb_index.py\`）
+- 已安装 \`sentence-transformers\`（\`pip install sentence-transformers\`）
+- 索引文件 \`.openfeel/tmp/vectors/index.json\` 存在
+- （可选）图谱已构建（运行 \`python scripts/build_kb_index.py --graph\`），用于返回关联条目
+
+## 执行步骤
+
+### 1. 检查索引就绪
+
+确认 \`.openfeel/tmp/vectors/index.json\` 文件存在。若不存在，拒绝执行并提示先运行 \`build_kb_index.py\`。
+
+### 2. 执行语义检索
+
+执行 \`python scripts/search_kb.py "<query>" --top-k <top_k> --min-score <min_score> --verbose\`。
+
+### 3. 解析结果
+
+输出格式化的检索结果摘要：
+
+\`\`\`
+🔍 语义检索结果（共 {N} 条）
+
+  #{1} [architecture] OAuth2 登录流程设计
+    文件: architecture.md | 得分: 0.87
+    内容: 采用 Authorization Code Grant 流程...
+
+  #{2} [patterns] 状态机模式使用约定
+    文件: patterns.md | 得分: 0.72
+    内容: 项目中所有状态流转统一使用 Switch + Enum...
+\`\`\`
+
+### 4. 图谱遍历（关联条目发现）
+
+当查询命中条目后，若 \`.openfeel/tmp/graph.json\` 存在且命中条目在其中，按以下步骤执行图谱遍历：
+
+#### 4.1 一度关联（直接关联）
+
+读取 \`graph.json\`，查找命中条目的所有**直接引用**和**被直接引用**的条目：
+
+\`\`\`
+🔗 一度关联条目（直接关联）
+
+  引用 → {N} 个条目：[[条目A]]、[[条目B]]
+  被引用 ← {M} 个条目：[[条目C]]
+\`\`\`
+
+#### 4.2 二度关联（间接关联）
+
+在一度关联的基础上，再展开一层，返回间接关联的条目：
+
+\`\`\`
+🔗🔗 二度关联条目（间接关联）
+
+  引用 → [[条目D]]（经由 [[条目A]]）
+  被引用 ← [[条目E]]（经由 [[条目C]]）
+\`\`\`
+
+二度关联按"经由哪个一度节点"分组展示，便于理解关联路径。
+
+#### 4.3 遍历实现
+
+执行 \`python scripts/kb_graph.py --from "<命中条目标题>" --depth 2\`，解析子图输出提取关联节点和边。
+
+### 5. 智能解读
+
+结合当前任务上下文解读检索结果：
+- 标注与当前任务高度相关的条目
+- 标注可能需要进一步查阅的条目
+- 若所有结果得分均低于 0.3，建议用户优化查询词或确认知识库覆盖范围
+- 若图谱返回的关联条目与检索结果重叠，合并去重并标注来源（语义匹配 / 图谱关联）
+
+## 输出格式
+
+\`\`\`
+## 语义检索结果
+
+查询: "{query}"
+结果数: {N}
+
+{格式化结果列表}
+
+## 关联条目（图遍历）
+
+{一度关联条目列表}
+
+{二度关联条目列表}
+
+### 解读
+- 相关条目（得分 ≥ 0.5）: {count} 条，可直接参考
+- 弱相关条目（0.3 ≤ 得分 < 0.5）: {count} 条，建议进一步确认
+- 低相关条目（得分 < 0.3）: {count} 条，可能不适用
+- 图关联条目（未被语义检索命中）: {count} 条
+\`\`\`
+
+## 参数扩展
+
+新增可选参数：
+
+- \`--with-graph\`：启用图谱遍历返回关联条目（默认启用，若 graph.json 不可用则静默跳过）
+- \`--graph-depth\`：图谱遍历深度，1=一度关联，2=二度关联（默认: 2）
+
+## 注意事项
+
+- 向量索引是缓存层，文件系统始终是 single source of truth。若检索结果与预期不符，检查索引是否过期（运行 \`--dry-run\` 查看变更文件）
+- 图谱链接亦是缓存层，Markdown 文件中 \`[[wikilink]]\` 是真实数据源；图谱可随时通过 \`python scripts/build_kb_index.py --graph\` 重建
+- 语义检索适合模糊查询和探索性搜索，精确关键词匹配优先使用 \`check-kb\`
+- 此技能是 \`check-kb\` 的回退方案——当 \`check-kb\` 精确匹配无结果时可自动调用
+- 图遍历返回的关联条目仅基于已建立的 wikilink 链接，若条目未引用或被引用其他条目，图谱中不会出现对应关联
 `,
     'sync-status': `---
 name: sync-status
@@ -1021,124 +1021,124 @@ description: 聚合所有成员的任务进度视图，供任意 Agent 快速了
 
 Base directory for this skill: file:///C:/Code/AI/AI_Prompt/.kilo/skills/sync-status
 `,
-    'update-stage-status': `---
-name: update-stage-status
-description: 标准化更新 .openfeel/plan/{stage}/status.md 的子计划状态、责任 Agent 和状态记录，避免各 Agent 随意改写状态文件。适用于自动闭环和人工流程中的阶段状态变更。
----
-
-# 更新子计划状态
-
-## 输入
-
-- 计划阶段名 \`{stage}\`
-- 新状态 \`{status}\`
-- 当前责任 Agent \`{current_agent}\`
-- 上一责任 Agent \`{previous_agent}\`
-- 说明 \`{note}\`
-- 是否保持自动推进 \`{keep_auto}\`（默认保持原值）
-
-### 可选输入（Worktree / 并行 管理）
-
-当阶段以 worktree 模式运行时，可额外传入以下字段：
-
-- \`worktree_branch\`：worktree 分支名（如 \`auto-stage-02\`）
-- \`parallel_batch\`：并行批次标识（如 \`batch-2026-05-15-001\`），同一批次并行启动的 worktree 共享此标识
-- \`parallel_stages\`：同批次并行阶段列表（如 \`[stage-04]\`）
-- \`merge_status\`：合并状态（\`not_started\` / \`pending_merge\` / \`merged\` / \`cleanup_ready\` / \`cleaned\`）
-- \`depends_status\`：依赖状态（\`pending\` / \`satisfied\` / \`blocked\`），当依赖阶段完成时更新
-
-## 执行步骤
-
-### 0. 读取全局配置
-
-读取 \`.openfeel/config.yaml\`，获取 \`defaults\` 中的 \`execution_mode\`、\`auto_advance\`、\`merge_mode\`。
-
-### 1. 读取状态文件
-
-读取 \`.openfeel/plan/{stage}/status.md\`。
-
-若文件不存在且当前 Agent 为 Architect：
-  1. 从 \`.openfeel/config.yaml\` \`defaults\` 读取 \`execution_mode\`、\`auto_advance\` 作为初始值
-  2. 按模板创建 \`status.md\`，将 config 默认值写入对应字段
-其他 Agent 不得自行创建，必须提示用户或 Architect 先初始化阶段状态。
-
-### 2. 校验状态变更
-
-允许的状态值：
-
-\`\`\`text
-planned | ready_for_code | coding | ready_for_review | review_failed | review_passed | ready_for_test | test_writing | testing | bug_found | bug_fixing | done | paused
-\`\`\`
-
-若新状态不在列表中，停止并说明错误。
-
-### 3. 更新字段
-
-**常规更新**（每次状态变更必须更新）：
-
-- \`状态\`
-- \`当前责任 Agent\`
-- \`上一责任 Agent\`
-- \`更新时间\`
-
-**Worktree / 并行 更新**（仅在可选输入传入时更新，位于 \`## Worktree / Session\` 块）：
-
-- \`分支名\` → \`worktree_branch\`（如 \`auto-stage-02\`）
-- \`并行批次\` → \`parallel_batch\`
-- \`并行阶段\` → \`parallel_stages\`
-- \`合并状态\` → \`merge_status\`
-
-**依赖状态更新**（位于文件顶部字段）：
-
-- \`依赖状态\` → \`depends_status\`（当 Architect 检测到依赖阶段完成时更新，典型值：\`pending → satisfied\`）
-
-除非用户明确要求，否则不得改变：
-
-- \`执行模式\`
-- \`自动推进\`
-- \`前置依赖\`（由 Architect 在 Phase 3.5 中声明，运行时不应修改）
-
-### 4. 追加状态记录
-
-在 \`## 状态记录\` 表格末尾追加：
-
-\`\`\`markdown
-| yyyy-mm-dd HH:MM | {agent} | {旧状态} → {新状态} | {note} |
-\`\`\`
-
-### 5. 安全暂停规则
-
-遇到以下情况必须将状态改为 \`paused\`，当前责任 Agent 改为 \`user\`：
-
-- 计划外架构变更
-- 需要修改范围超过原计划
-- 权限不明确
-- 测试环境缺失
-- 连续两次验收失败
-- 自动推进链路无法判断下一步
-
-### 6. 合并状态处理
-
-当子计划状态变为 \`done\` 或 \`review_passed\`（且 Reviewer 验收完毕）时，根据 \`.openfeel/config.yaml\` 中的 \`merge_mode\` 决定合并行为：
-
-- **\`merge_mode=auto\`**：
-  1. 将 \`合并状态\` 更新为 \`merged\`（实际合并由 Executor 执行 git 操作，Skill 仅更新状态字段）
-  2. 将 \`合并状态\` 更新为 \`cleaned\`
-  3. 在状态记录中注明"自动合并"
-- **\`merge_mode=manual\`**：
-  1. 将 \`合并状态\` 设为 \`pending_merge\`
-  2. 输出提示：合并与清理需手动完成
-
-### 7. 输出结果
-
-输出更新摘要：
-
-\`\`\`markdown
-已更新 {stage}/status.md：
-- 状态：{旧状态} → {新状态}
-- 当前责任 Agent：{current_agent}
-- 自动推进：保持 {enabled/disabled}
-\`\`\`
+    'update-stage-status': `---
+name: update-stage-status
+description: 标准化更新 .openfeel/plan/{stage}/status.md 的子计划状态、责任 Agent 和状态记录，避免各 Agent 随意改写状态文件。适用于自动闭环和人工流程中的阶段状态变更。
+---
+
+# 更新子计划状态
+
+## 输入
+
+- 计划阶段名 \`{stage}\`
+- 新状态 \`{status}\`
+- 当前责任 Agent \`{current_agent}\`
+- 上一责任 Agent \`{previous_agent}\`
+- 说明 \`{note}\`
+- 是否保持自动推进 \`{keep_auto}\`（默认保持原值）
+
+### 可选输入（Worktree / 并行 管理）
+
+当阶段以 worktree 模式运行时，可额外传入以下字段：
+
+- \`worktree_branch\`：worktree 分支名（如 \`auto-stage-02\`）
+- \`parallel_batch\`：并行批次标识（如 \`batch-2026-05-15-001\`），同一批次并行启动的 worktree 共享此标识
+- \`parallel_stages\`：同批次并行阶段列表（如 \`[stage-04]\`）
+- \`merge_status\`：合并状态（\`not_started\` / \`pending_merge\` / \`merged\` / \`cleanup_ready\` / \`cleaned\`）
+- \`depends_status\`：依赖状态（\`pending\` / \`satisfied\` / \`blocked\`），当依赖阶段完成时更新
+
+## 执行步骤
+
+### 0. 读取全局配置
+
+读取 \`.openfeel/config.yaml\`，获取 \`defaults\` 中的 \`execution_mode\`、\`auto_advance\`、\`merge_mode\`。
+
+### 1. 读取状态文件
+
+读取 \`.openfeel/plan/{stage}/status.md\`。
+
+若文件不存在且当前 Agent 为 Architect：
+  1. 从 \`.openfeel/config.yaml\` \`defaults\` 读取 \`execution_mode\`、\`auto_advance\` 作为初始值
+  2. 按模板创建 \`status.md\`，将 config 默认值写入对应字段
+其他 Agent 不得自行创建，必须提示用户或 Architect 先初始化阶段状态。
+
+### 2. 校验状态变更
+
+允许的状态值：
+
+\`\`\`text
+planned | ready_for_code | coding | ready_for_review | review_failed | review_passed | ready_for_test | test_writing | testing | bug_found | bug_fixing | done | paused
+\`\`\`
+
+若新状态不在列表中，停止并说明错误。
+
+### 3. 更新字段
+
+**常规更新**（每次状态变更必须更新）：
+
+- \`状态\`
+- \`当前责任 Agent\`
+- \`上一责任 Agent\`
+- \`更新时间\`
+
+**Worktree / 并行 更新**（仅在可选输入传入时更新，位于 \`## Worktree / Session\` 块）：
+
+- \`分支名\` → \`worktree_branch\`（如 \`auto-stage-02\`）
+- \`并行批次\` → \`parallel_batch\`
+- \`并行阶段\` → \`parallel_stages\`
+- \`合并状态\` → \`merge_status\`
+
+**依赖状态更新**（位于文件顶部字段）：
+
+- \`依赖状态\` → \`depends_status\`（当 Architect 检测到依赖阶段完成时更新，典型值：\`pending → satisfied\`）
+
+除非用户明确要求，否则不得改变：
+
+- \`执行模式\`
+- \`自动推进\`
+- \`前置依赖\`（由 Architect 在 Phase 3.5 中声明，运行时不应修改）
+
+### 4. 追加状态记录
+
+在 \`## 状态记录\` 表格末尾追加：
+
+\`\`\`markdown
+| yyyy-mm-dd HH:MM | {agent} | {旧状态} → {新状态} | {note} |
+\`\`\`
+
+### 5. 安全暂停规则
+
+遇到以下情况必须将状态改为 \`paused\`，当前责任 Agent 改为 \`user\`：
+
+- 计划外架构变更
+- 需要修改范围超过原计划
+- 权限不明确
+- 测试环境缺失
+- 连续两次验收失败
+- 自动推进链路无法判断下一步
+
+### 6. 合并状态处理
+
+当子计划状态变为 \`done\` 或 \`review_passed\`（且 Reviewer 验收完毕）时，根据 \`.openfeel/config.yaml\` 中的 \`merge_mode\` 决定合并行为：
+
+- **\`merge_mode=auto\`**：
+  1. 将 \`合并状态\` 更新为 \`merged\`（实际合并由 Executor 执行 git 操作，Skill 仅更新状态字段）
+  2. 将 \`合并状态\` 更新为 \`cleaned\`
+  3. 在状态记录中注明"自动合并"
+- **\`merge_mode=manual\`**：
+  1. 将 \`合并状态\` 设为 \`pending_merge\`
+  2. 输出提示：合并与清理需手动完成
+
+### 7. 输出结果
+
+输出更新摘要：
+
+\`\`\`markdown
+已更新 {stage}/status.md：
+- 状态：{旧状态} → {新状态}
+- 当前责任 Agent：{current_agent}
+- 自动推进：保持 {enabled/disabled}
+\`\`\`
 `,
     'wizard': `---
 name: wizard