| name | distill-and-archive |
| description | 从网址提取知识点并归档到笔记系统的工作流。当用户说"distill"、"把这个归档到笔记"、"整理到 maps"、"保存到知识库"或类似请求时触发。支持从 URL distill 知识点、调研笔记系统结构、制定归档计划、等待用户确认后执行归档和提交。 |
| argument-hint | <URL or content to distill> |
当前 SKILL 服务且仅服务于 ~/Github/Lionad-Morotar/blog 博客项目，所有改动都应以该项目为基础。
上下文
目标
将网络文章或内容提炼为精炼知识点，并归档到用户的笔记系统中。没有用户输入时，从会话上下文（如用户询问问题，LLM 做出的回复）提取原始内容。
工作流程包含：内容提取与 distill、笔记系统调研、归档计划制定、用户确认、执行归档和提交。尤其要注意知识点的存放位置。
归档模式
- 简单归档：当用户明确要求"简单归档"时，适合简单的链接列表、索引等输入内容。输出严格使用
* [标题](地址)：说明 模板；知识点标题应指向具体内容（如"V8 引擎实现参考"），禁止命名为"学习资源"、"参考链接"等宽泛索引标题。
- 默认归档：当用户未指定归档模式时，采用默认归档模式，适合单个或多个知识点，一整篇博客等输入内容
可以归档的内容
- 链接：简单归档模式下可以归档链接及简单的介绍
- 知识（Knowledge）：事实性、客观、可验证的内容
- 观点（Opinion）：作者的主观经验、实践偏好、流派主张
- 高层次洞见（Insight、元思考、元认知）：部分高难度网站或信息特殊的网站，可提炼高层次洞见——捕获思维模式而非操作细节。这种洞见关注作者如何理解问题、建立概念关联、形成独特的认知框架，而非具体的技术步骤或实现方法。
Workflow
- 获取内容：从用户输入获取内容，当输入为空时回退到从上下文提炼内容
- 主代理（你）直接使用工具执行以下任务
2.1 内容验证：区分事实和观点，展开简单的补充搜索，验证一手优质来源、区分不同角度、避免流畅性偏见
2.1.1 如果在会话上下文中，step 1 的内容已经得到充分验证，可跳过 2.1 步骤
2.2 将内容整理为精炼知识点
- 默认归档：正文使用自然叙述，不出现 L1/L2/L3 等验证标签
- 简单归档：严格使用
* [标题](地址)：说明 模板，知识点标题指向具体内容，不展开长篇描述，禁止宽泛索引标题
- 保留通用性，移除特定项目描述：归档的是通用知识，应保留足够的技术细节（如具体 API、配置项、阈值、工具组合），但移除当前项目/会话的特有名称、临时变量、业务术语或“当前项目 xxx”式表述。把触发条件泛化为可复用的技术条件，让 future self 看笔记时不需要回忆本次会话；同时避免过度抽象到只剩口号。
2.3 定位每个知识点的存放位置
- 按直接父话题定位（如 linter →
_workflow/linter），不归入泛化上位概念（如软件工程）
- 列出同一 Subdomain 下所有候选 Topic 文件，用
extract-markdown-meta.js 读取每个文件的 title、description、toc
- 优先选择内容主题与知识点最匹配的 Topic 文件，禁止把知识点放进入口/索引文件（如
prompt.md、ai.md 等仅做导航的文件）
- 给出精确插入锚点（前序/后序四级标题），并避开引用边界
2.4 为每个知识点撰写归档计划（包含所有知识点的四层定位表格、内容草稿和文件变更清单）
- 输出完整归档计划
3.1 快速读取目标文件片段，校验插入锚点是否真实存在、是否切断引用边界、是否把知识点错误放入入口/索引文件
3.2 必须输出完整归档计划（包含四层定位表格、每个知识点的正文草稿、文件变更清单、引用来源说明）后，再向用户请求确认
3.3 若锚点缺失、定位不合理（如把知识点塞进索引文件）、或可能切断引用边界，返回上一步修正
- 得到用户肯定后，根据计划写入并提交，提交信息“gists: 补充/更新/删除 [主题/文件] [简要描述]”，无需推送
- 索引维护（简单归档模式可跳过此步骤）
- 新文件必须索引：新建 Topic 文件须登记到其 Subdomain 入口文件（无导航区则新增，如
## Topics），避免“有文件无入口”；禁止把 Topic 平铺进只列 Subdomain 条目的 Domain 索引
- 若新增了 Domain 目录，更新
content/6.maps/Agents.md
- 简单报告结果
关键细节
- 读取
content/6.maps/Agents.md 可参考现有结构（置信度低）
- 每个知识点都应使用基于四层认知结构（Domain → Subdomain → Topic → “#### <标题>”）的定位技术；一个
#### 四级标题对应一个原子化知识点
- 禁止使用笼统的标题（如"## 学习资源"、"## 参考链接"）创建标题以及归档到这些位置
- 优先使用 JS 脚本读取文件元数据（包含标题、目录等）以确定文档内容，而不是直接读取整个文档。脚本位于 skill 私有工具链目录：
node ~/.claude/skills/distill-and-archive/scripts/extract-markdown-meta.js <文档绝对路径> [--depth=3]
- 避免过拟合陷阱：不要仅因为文章提到了某领域术语，就将其归入该领域
- 简单知识保持单一核心观点，不强行拆分
- 禁止使用
--- 分隔线
- 引用格式统一为“见：”链接：归档正文不使用
[^n] 或 [^label] 脚注；每个 #### 知识点正文结束后空一行，跟唯一一行 见：[标题](url)。若把多个 get-secrets 要点合并到同一个 #### 标题下，也只保留一个 见：
- 内容验证阶段工具调用限制：内容验证阶段只能使用
open-websearch / fetchWebContent / Read 等只读搜索工具，每个知识点验证最多 2-3 次工具调用，超限时自动终止并返回当前结果
- 使用三层事实模型验证内容（仅用于内部验证阶段）：
L1 经验事实，可量化、可证伪，如“「已核实」式陈述，精确数字/日期”
L2 解释性框架，因果解释、意义赋予如“有分析认为/证据指向」式陈述，呈现多元框架”
L3 价值判断，应然陈述、主观评估，如“「作者主张/建议」式陈述，标注为观点”
强制说明：L1/L2/L3 仅用于内部验证阶段，禁止出现在返回给用户的归档计划正文中。验证完成后，应将 L1/L2/L3 的区分内化到语气里——L1 用直接陈述、L2 用“这反映了/其机制在于”、L3 用“工程上应/建议”——并在验证摘要中用自然语言描述（如“经验事实，已得到 OpenAI 官方文档验证”），而不是保留 L1/L2/L3 标签。
-
简单归档模式专用约束
- 严格使用
* [标题](地址)：说明 列表项格式
- 知识点标题应指向具体内容（如“V8 引擎实现参考”），禁止“学习资源”、“参考链接”等宽泛索引标题
- 链接本身即为引用来源，无需再额外添加“见：”行
- 简单归档作为已有 Topic 下的一个具体知识点存在，不应单独创建只含链接列表的索引文件
-
通用性校验：归档前检查知识点是否仍能被 future self 看懂，且保留了足够的技术细节。若正文依赖当前项目的具体信息，应泛化为通用技术条件或补全上下文；禁止出现“当前项目 xxx”“本次会话中的 xxx”等指代。
-
正文行长度控制：归档正文每行不超过 120 个字符；超过时在句读或短语边界 soft wrap。写入后必须运行 node /Users/lionad/Github/Lionad-Morotar/blog/scripts/lint-md.mjs 检查修改的文件。
-
计划调整只返回变更部分：当用户对已给出的归档计划提出调整（如增减知识点、修改位置、合并条目）时，仅输出需要变更的项（位置、内容或文件清单），不要重复返回完整的四层定位表格和所有知识点正文。
简单归档模版
#### 具体的技术点标题
* [标题](地址)：简短的链接说明
示例：
#### V8 引擎实现参考
* [V8 Resources](https://mrale.ph/v8/resources.html)：V8 引擎演讲、文章与视频资源索引，涵盖性能优化、编译管线、GC 与 inline caching 等实现细节
默认归档模版
归档计划确认模版
在归档前使用此模板向用户确认：
基本知识
四层认知结构详情参考
| 层级 | 定义 | 物理形式 | 判断标准 |
|---|
| 领域 (Domain) | 最高层级的知识边界 | _domain/ 目录 | 存在于 0.index.md 的导航结构中，目录以 _ 开头 |
| 子领域 (Subdomain) | 领域内的专业分支 | subdomain/ 子目录或文件 | 构成独立学习单元，有明确知识边界 |
| 主题 (Topic) | 具体的技术点或概念 | .md 文件 | 超过 150 行或有扩展潜力的内容拆分为独立文件 |
| 知识点 (Knowledge Point) | 原子化的思考性内容 | #### 四级标题 | 观点、案例、洞见，不拆分为独立文件 |
L 层级表述规则参考
- L1 经验事实 — 直接陈述，精确数字/日期，如：「2025 年 OpenAI 报告亏损 50 亿美元，较 2024 年增长 180%。」
- L2 解释性框架 — 「有分析认为」「证据指向」，可呈现 2 个框架，如：「有分析将 OpenAI 比作 AI 界的 WeWork，但这一类比存在争议——OpenAI 拥有 200 亿美元收入，而 WeWork 主要是亏损。」
- L3 价值判断 — 标注为「作者主张」「文章建议」如：「作者主张，投资者应对高估值 AI 公司保持谨慎，优先考虑现金流而非增长率。」
