llm-wiki-maintainer

LLM Wiki 维护者

概述

将此技能用于以编译后的 Obsidian 兼容 wiki 工件形式维护的持久化 Markdown 知识库。

优先顺序：

1. 对于新的设置、部署或初始化请求，默认部署 Ar9av/obsidian-wiki。
2. 如果已有 Ar9av/obsidian-wiki 框架，优先使用该框架。
3. 如果已有旧版 raw/ + wiki/ LLM Wiki，在不破坏现有结构的前提下继续使用，并建议迁移到 obsidian-wiki。
4. 仅在用户明确要求使用旧版标准 LLM Wiki 格式时，才创建或扩展旧版布局。

将 wiki 视为需要维护的系统，而不是一堆笔记。

默认部署行为

当用户因设置、部署、初始化或创建新 wiki 而调用此技能，且无需保留现有 wiki 约定时，默认部署 Ar9av/obsidian-wiki 作为实现方案。

默认部署意味着：

1. 从 https://github.com/Ar9av/obsidian-wiki 创建或填充目标目录，将其设为 obsidian-wiki 仓库。
2. 保留目标目录中已有的用户文件。
3. 创建 .env，并将 OBSIDIAN_VAULT_PATH 设置为目标知识库的路径。
4. 初始化知识库文件和目录：
   • index.md
   • log.md
   • hot.md
   • .manifest.json
   • .obsidian/
   • _meta/
   • _raw/
   • _archives/
   • concepts/、entities/、skills/、references/、synthesis/、journal/、projects/
5. 在确保安全的情况下，让 ~/.obsidian-wiki/config 指向选定的知识库或仓库。
6. 除非用户要求运行完整的上游 setup.sh，否则仅将所需的 Codex 技能符号链接安装到 ~/.codex/skills。
7. 如果仓库将 Ar9av/obsidian-wiki 用作 origin，应排除本地知识库工件，避免意外提交到上游，并保持上游框架的 git 状态干净。

如果用户只是提出“设置我的 wiki”“разверни wiki”“создай Obsidian wiki”或类似请求，不要询问用户是否想使用旧版布局。除非用户明确指定旧版布局，否则使用 obsidian-wiki。

旧版 LLM Wiki 兼容性

旧版模式适用于已存在的标准 LLM Wiki 布局，例如：

• WIKI-SCHEMA.md
• raw/
• wiki/index.md
• wiki/log.md
• wiki/sources/
• wiki/concepts/、wiki/entities/、wiki/analyses/

检测到旧版模式时：

1. 安全地使用现有布局。
2. 未经明确批准，不要移动、重命名或重写旧版 wiki。
3. 告知用户当前的 wiki 属于旧版／标准 LLM Wiki。
4. 除非有明确理由保留旧结构，否则建议未来迁移到 Ar9av/obsidian-wiki。
5. 提供迁移方案：
   • 将 raw/ 保留为源材料，或映射到 _raw/
   • 将 wiki/sources/ 映射到 references/
   • 将 wiki/concepts/ 映射到 concepts/
   • 将 wiki/entities/ 映射到 entities/
   • 将 wiki/analyses/ 映射到 synthesis/
   • 将 wiki/index.md 和 wiki/log.md 转换为根目录下的 index.md 和 log.md
   • 创建 .manifest.json、hot.md、_meta/ 和 .obsidian/

只有在用户提出要求或明确授权后，才能执行迁移。

Obsidian-Wiki 优先级

如果存在以下任一情况，则默认使用 obsidian-wiki 模式：

• .skills/llm-wiki/SKILL.md
• .skills/wiki-ingest/SKILL.md、.skills/wiki-query/SKILL.md 或相关 wiki 技能
• 以 Obsidian Wiki Agent 上下文开头的 AGENTS.md
• 包含 OBSIDIAN_VAULT_PATH 的 .env
• ~/.obsidian-wiki/config
• 保险库文件，例如 .manifest.json、hot.md、_meta/taxonomy.md、_raw/

在此模式下，先遵循框架约定，再遵循本地习惯：

1. 解析配置。
   • 从 CWD 开始向上查找包含 OBSIDIAN_VAULT_PATH 的 .env。
   • 如果未找到，则读取 ~/.obsidian-wiki/config。
   • 解析出的 OBSIDIAN_VAULT_PATH 即为保险库根目录。
   • 存在时，解析出的 OBSIDIAN_WIKI_REPO 即为框架仓库。
2. 读取控制文件。
   • 存在时，读取仓库的 AGENTS.md。
   • 然后读取 $OBSIDIAN_VAULT_PATH/AGENTS.md（如果存在）；它会覆盖框架默认设置，采用所有者专属约定。
   • 对于特定操作，开始前先读取仓库中匹配的 .skills/<skill-name>/SKILL.md。
3. 使用 obsidian-wiki 保险库结构。
   • 根目录特殊文件：index.md、log.md、hot.md、.manifest.json。
   • 元数据：_meta/、_raw/、_archives/、.obsidian/。
   • 分类：concepts/、entities/、skills/、references/、 synthesis/、journal/ 和 projects/。
4. 将编译后的内容放在保险库根目录的分类中，而不是 wiki/ 中，除非检测到的约定明确使用旧版路径。

此环境中的本地默认设置：

• $HOME/TG-NEWS-151 是 obsidian-wiki 仓库和保险库。
• $HOME/.obsidian-wiki/config 指向该保险库。

快速开始

1. 查找约定。
   • 首先根据上述规则检测 obsidian-wiki 模式。
   • 在 obsidian-wiki 模式下，解析 .env 或 ~/.obsidian-wiki/config，读取 AGENTS.md，然后读取保险库中的 index.md、log.md 和 hot.md。
   • 在旧版模式下，如果保险库中有 WIKI-SCHEMA.md，则先读取它。
   • 然后读取本地 AGENTS.md（如果存在）。
   • 接着读取旧版 wiki/index.md 和 wiki/log.md。
   • 如果不存在约定，且任务是设置、初始化或部署，则默认创建 obsidian-wiki 设置。
   • 对于整个工作区的保险库，如果存在语料库策略页面，则在摄取前先阅读。
2. 遵守来源边界。
   • 将 _raw/、raw/ 和外部语料库文件视为只读，除非明确要求编辑。
   • 在 obsidian-wiki 模式下，只将编译后的知识写入保险库分类目录，例如 references/、concepts/、entities/、synthesis/、journal/ 和 projects/。
   • 在旧版模式下，只将编译后的知识写入 wiki/。
3. 选择操作。
   • ingest
   • query
   • lint

适用场景

• 用户提到 LLM Wiki、Obsidian、vault、raw/、wiki/、 wiki/index.md、wiki/log.md、WIKI-SCHEMA.md 或 AGENTS.md。
• 用户提到 obsidian-wiki、Ar9av/obsidian-wiki、.manifest.json、 .skills/wiki-*、_raw/、hot.md、wiki-status、wiki-ingest 或 wiki-query。
• 任务涉及在摄取前将源文件转换为 Markdown，或者用户提到 MarkItDown、markitdown、文档转 Markdown、PDF/DOCX/PPTX/HTML 导入，或要求为 wiki 准备原始资料。
• 用户希望摄取来源、从 wiki 中获取答案、调和矛盾或维护持久化知识库。
• 用户使用俄语提示词，例如：
  • добавь в вики
  • сделай ingest
  • обнови index/log
  • lint wiki
  • разложи по вики

工作流

Obsidian-Wiki 操作路由

处于 obsidian-wiki 模式时，优先遵循匹配的框架技能说明：

• 设置或修复：读取 .skills/wiki-setup/SKILL.md。
• 导入：读取 .skills/wiki-ingest/SKILL.md；对于原始文本/导出数据，则读取 .skills/data-ingest/SKILL.md。
• 查询：读取 .skills/wiki-query/SKILL.md。
• 状态/增量：读取 .skills/wiki-status/SKILL.md。
• lint：读取 .skills/wiki-lint/SKILL.md。
• 重建/归档：读取 .skills/wiki-rebuild/SKILL.md。
• 交叉链接：读取 .skills/cross-linker/SKILL.md。
• 标签：读取 .skills/tag-taxonomy/SKILL.md。
• 项目同步：读取 .skills/wiki-update/SKILL.md。

如果请求的工作流已由已安装的 obsidian-wiki 技能覆盖，请遵循该技能的约定，而不是根据此通用技能重新解读任务。

导入

当需要将新的来源、文件夹、笔记或工作区片段转化为可持久保留的知识时使用。

在 obsidian-wiki 模式下：

1. 解析配置并读取控制文件。
2. 仔细阅读来源，不要对其进行修改。
3. 除非特定操作技能指出其他类别更合适，否则在 references/ 中创建或更新来源/参考页面。
4. 根据需要更新 concepts/、entities/、skills/、synthesis/、journal/ 或 projects/ 中的持久页面。
5. 更新 index.md、log.md、hot.md 和 .manifest.json。
6. 遵循框架模板时，在 frontmatter 字段（如 sources、summary、provenance、base_confidence、lifecycle、created 和 updated）中保留来源信息。

旧版模式：

步骤：

1. 仔细阅读来源。
2. 在 wiki/sources/ 中创建或更新一个来源页面。
3. 更新受影响的持久页面，位于 wiki/entities/、wiki/concepts/ 或 wiki/analyses/ 中。
4. 更新 wiki/index.md。
5. 在 wiki/log.md 中追加一条记录。

规则：

• 实际可行时，优先为每个来源条目创建一个来源页面。
• 对于紧密相关的文档，使用一个合集来源页面，并在 sources 中列出每个成员。
• 保留来源信息。不要原地改写来源材料。

借助 MarkItDown 导入

当来源材料为非 Markdown 格式，且需要在不虚构内容的前提下，为导入知识库做好准备时使用。

常见情况：

• PDF
• DOCX
• PPTX
• HTML
• 复制的导出文件或下载的来源文件包，转换为 Markdown 后更便于导入

规则：

• 除非明确收到其他指示，否则将原始文件视为只读。
• 在 obsidian-wiki 模式下，优先将转换后的文件写入 _raw/ 或其他明确指定的暂存区域，而不是编译后的分类文件夹。
• 在旧版模式下，优先将转换后的文件写入 raw/ 或其他明确指定的导入暂存区域，而不是 wiki/。
• 不要用转换后的 Markdown 覆盖原始来源文件。
• 转换后，将转换文件作为来源导入，并保留指向原始路径的来源信息。
• 如果转换质量较差，请明确说明，而不要假装 Markdown 内容可靠。

本地工具说明：

• 本地 MarkItDown 环境位于： $HOME/LLM Wiki MarkItDown/MarkItDown/venv/bin/markitdown
• 本地观察到的已安装版本：markitdown 0.1.5

实用工作流：

1. 确定原始来源文件。
2. 使用本地 markitdown 将其转换为暂存 Markdown 文件。
3. 保持原始文件不变。
4. 批判性地审阅转换后的 Markdown。
5. 在 obsidian-wiki 模式下，根据转换后的来源创建/更新一个 references/ 页面，然后更新持久页面、index.md、log.md、hot.md 和 .manifest.json。
6. 在旧版模式下，根据转换后的来源创建/更新一个 wiki/sources/ 页面，然后更新持久页面、wiki/index.md 和 wiki/log.md。

查询

当用户提出 wiki 应该能够回答的问题时使用。

在 obsidian-wiki 模式下：

1. 解析配置，并优先读取 index.md、hot.md 和相关的 frontmatter 摘要。
2. 仅在需要时阅读相关的持久页面。
3. 优先依据 wiki 作答，并使用 [[wikilink]] 引用。
4. 如果 wiki 信息不足，明确说明缺少的来源或页面。

旧版模式：

步骤：

1. 优先阅读 wiki/index.md，了解整体情况。
2. 阅读相关的持久页面。
3. 优先依据 wiki 作答。
4. 使用 [[wikilinks]] 引用相关页面。
5. 如果答案具有持久价值，保存或建议新建一个分析页面。

规则：

• 不要不加说明地混合来源事实与推断。
• 如果 wiki 信息不足，说明缺少什么。

检查

当用户希望对 wiki 进行质量控制时使用。

检查以下内容：

• 失效链接
• 孤立页面
• 关联较弱的页面
• 重复或内容重叠的页面
• 矛盾之处
• 反复提及却没有专属页面的概念或实体
• 过时的说法或已被取代的页面

在安全的情况下直接修复：

• 失效链接
• 索引偏差
• 明确应补充的反向链接
• 明显的页面归类或标题问题
• 在 obsidian-wiki 模式下，有来源依据且可机械修正的过时 hot.md 或 .manifest.json 元数据

需要判断时，报告问题而不是猜测。

页面规范

• 优先更新持久页面，而非创建零散片段。
• 保持来源页面客观持久，持久页面综合提炼信息。
• 确保 YAML frontmatter 有效。
• 保持 wikilink 有意义。
• 在 obsidian-wiki 模式下，保持 index.md、log.md、hot.md 和 .manifest.json 为最新状态。
• 在旧版模式下，保持 wiki/index.md 和 wiki/log.md 为最新状态。
• 如果某项说法缺少可信依据，请明确说明。

真实性规则

• 不要编造事实。
• 区分有来源支持的事实与综合提炼的内容。
• 明确保留不确定性。
• 绝不伪造来源信息、引用、来源数量或页面链接。

架构说明

• 如果 wiki 描述软件，请将架构页面与实现页面分开。
• 如果要比较系统或产品，请先导入双方的资料，再撰写综合页面。
• 如果用户直接在聊天中提供文本，请将其视为来源笔记，并在来源页面正文中记录其出处。
• 如果导入的来源材料先经过 MarkItDown 处理，在生成的来源页面或出处说明中，适当保留原始文件路径和转换后的 markdown 路径。

本地示例

如需查看此环境中可实际使用的 vault，请阅读 references/artigram-example.md。

在此环境中配置本地转换流程时，请注意：

• wiki 骨架： $HOME/LLM Wiki MarkItDown/LLM Wiki
• MarkItDown venv： $HOME/LLM Wiki MarkItDown/MarkItDown/venv