| name | source-to-knowledge |
| description | 当用户提供源文档（如 ChatGPT 导出内容、文章、产品需求文档、会议转录等），并请求从中提取关键知识点并将其整合至 Obsidian 知识库时（例如将这份文档涉及的知识点, 写入工程知识库, 集成到vault, 知识提取），请使用此skill。 |
source-to-knowledge
目标
将外部源文档（ChatGPT 导出、技术文章、PRD、会议纪要等）中的知识，通过系统化提取、冲突检测和结构写入，集成到 Obsidian 知识库中。
工作流（四个阶段）
阶段一：知识点提取
- 完整阅读源文档。
- 逐一梳理所有知识点，不遗漏。
- 对每个知识点编号（格式
KP-N），标注所在文档章节。
- 使用
references/knowledge-point-template.md 输出「知识点清单表」。
阶段二：映射到知识库
- 读取
references/vault-structure-overview.md，了解知识库的 44 分支结构和文件命名规范。
- 将每个知识点与已有 vault 内容逐一交叉对比（读取对应分支的现有 .md 文件）。
- 为每个知识点标记映射状态：已覆盖 / 空白填补 / 新增 / 潜在冲突。
阶段三：冲突检测与处理
- 识别源文档声明与 vault 已有事实的差异。
- 按
references/conflict-detection-guide.md 分类：无冲突 / 追加 / 命名差异 / 实质性冲突。
- vault 已有事实为权威源。源文档的冲突主张修正后再写入。
- 发现实质性冲突 → 标记「待确认」→ 通知用户，不写入。
阶段四：写入知识库
- 对空白填补和新增知识点，写入对应分支的 .md 文件。
- 遵循概念笔记模板格式：
- frontmatter：
type: concept、status: done、tags: AI-Agent面试 + 主题标签
- 六个标准节：一句话定义 / 解决什么问题 / 如何实现 / 项目映射 / 高频追问 / 我的回答要点
- 如新增子节点文件，更新对应目录的
_index.md。
- 对已覆盖的知识点，不重复写入（可补充此前的遗漏细节，追加而非覆盖）。
阶段五：标记变更文件与目录
每次写入完成后必须执行以下标记操作：
-
文件打 ✅ 标记：对本次所有填充或编辑过的文件（status: done），在文件名加 ✅ 后缀。
- 例：
13.1 Durable Execution.md → 13.1 Durable Execution✅.md
- 不改动已有
status: todo 的空模板文件。
-
目录打 ✅ 标记：若本次填充使某个目录从"空模板为主"变为"有实质内容"（≥3 个文件 status: done），将目录名加 ✅ 后缀。
- 例：
13-Agent Runtime深水区/ → 13-Agent Runtime深水区✅/
-
修复所有交叉引用：文件/目录重命名后，必须同步更新：
- 对应目录的
_index.md 中所有 wiki-link
- 本次写入/编辑文件中所有内部 wiki-link（
所属分支、相关笔记、深度内容索引 等行）
- 不要遗漏任何链接，确保 Obsidian 双向链接不中断
-
使用 mv 重命名（macOS），git 会自行检测 rename。
约束
- 不删除文件。
- 不覆盖已有内容（仅追加或补充空模板）。
- 不编造项目指标。
- 不将大段源码复制到笔记中。
- 区分"已确认实现"和"表达方向"（后者标注「可作为表达方向，待补充事实依据」）。
输出格式
任务完成后返回：
- 知识点清单：总数、各状态分布
- 变更摘要：修改了哪些文件、新增了多少知识点
- 冲突报告：发现多少冲突、如何处理、待确认项
参考文件
references/vault-structure-overview.md — 知识库 44 分支地图和文件命名规范references/knowledge-point-template.md — 知识点提取表格模板和映射状态定义references/conflict-detection-guide.md — 冲突分类与处理规则
