source-to-knowledge

name	source-to-knowledge
description	当用户提供源文档（如 ChatGPT 导出内容、文章、产品需求文档、会议转录等），并请求从中提取关键知识点并将其整合至 Obsidian 知识库时（例如将这份文档涉及的知识点, 写入工程知识库, 集成到vault, 知识提取），请使用此skill。

source-to-knowledge

目标

将外部源文档（ChatGPT 导出、技术文章、PRD、会议纪要等）中的知识，通过系统化提取、冲突检测和结构写入，集成到 Obsidian 知识库中。

工作流（四个阶段）

阶段一：知识点提取

1. 完整阅读源文档。
2. 逐一梳理所有知识点，不遗漏。
3. 对每个知识点编号（格式 KP-N），标注所在文档章节。
4. 使用 references/knowledge-point-template.md 输出「知识点清单表」。

阶段二：映射到知识库

1. 读取 references/vault-structure-overview.md，了解知识库的 44 分支结构和文件命名规范。
2. 将每个知识点与已有 vault 内容逐一交叉对比（读取对应分支的现有 .md 文件）。
3. 为每个知识点标记映射状态：已覆盖 / 空白填补 / 新增 / 潜在冲突。

阶段三：冲突检测与处理

1. 识别源文档声明与 vault 已有事实的差异。
2. 按 references/conflict-detection-guide.md 分类：无冲突 / 追加 / 命名差异 / 实质性冲突。
3. vault 已有事实为权威源。源文档的冲突主张修正后再写入。
4. 发现实质性冲突 → 标记「待确认」→ 通知用户，不写入。

阶段四：写入知识库

1. 对空白填补和新增知识点，写入对应分支的 .md 文件。
2. 遵循概念笔记模板格式：
   • frontmatter：type: concept、status: done、tags: AI-Agent面试 + 主题标签
   • 六个标准节：一句话定义 / 解决什么问题 / 如何实现 / 项目映射 / 高频追问 / 我的回答要点
3. 如新增子节点文件，更新对应目录的 _index.md。
4. 对已覆盖的知识点，不重复写入（可补充此前的遗漏细节，追加而非覆盖）。

阶段五：标记变更文件与目录

每次写入完成后必须执行以下标记操作：

1. 文件打 ✅ 标记：对本次所有填充或编辑过的文件（status: done），在文件名加 ✅ 后缀。

   • 例：13.1 Durable Execution.md → 13.1 Durable Execution✅.md
   • 不改动已有 status: todo 的空模板文件。

2. 目录打 ✅ 标记：若本次填充使某个目录从"空模板为主"变为"有实质内容"（≥3 个文件 status: done），将目录名加 ✅ 后缀。

   • 例：13-Agent Runtime深水区/ → 13-Agent Runtime深水区✅/

3. 修复所有交叉引用：文件/目录重命名后，必须同步更新：

   • 对应目录的 _index.md 中所有 wiki-link
   • 本次写入/编辑文件中所有内部 wiki-link（所属分支、相关笔记、深度内容索引 等行）
   • 不要遗漏任何链接，确保 Obsidian 双向链接不中断

4. 使用 mv 重命名（macOS），git 会自行检测 rename。

约束

• 不删除文件。
• 不覆盖已有内容（仅追加或补充空模板）。
• 不编造项目指标。
• 不将大段源码复制到笔记中。
• 区分"已确认实现"和"表达方向"（后者标注「可作为表达方向，待补充事实依据」）。

输出格式

任务完成后返回：

• 知识点清单：总数、各状态分布
• 变更摘要：修改了哪些文件、新增了多少知识点
• 冲突报告：发现多少冲突、如何处理、待确认项

参考文件

• references/vault-structure-overview.md — 知识库 44 分支地图和文件命名规范
• references/knowledge-point-template.md — 知识点提取表格模板和映射状态定义
• references/conflict-detection-guide.md — 冲突分类与处理规则