Imported from lov-b/Skills (skills/auto-know/SKILL.md). Install upstream with npx skills add lov-b/Skills --skill auto-know. Copyright stays with the author.

Auto Know — 八股知识管理

把网站和 AI 对话里的技术面试知识整理成可检索、可修订、可追溯的 Markdown 知识库；并支持基于该知识库进行面试出题与练习归档。

核心原则：

• 先查已有知识，再决定新增、合并、修订、冲突保留或跳过；禁止机械 append。
• 问题标题保留真实面试问法，答案能够脱离原对话独立理解。
• 收集问题时必须保留来源中的栏目、父子、前置和递进关系，用标题层级表达结构，禁止把所有问题平铺为同级标题。
• 网站内容必须记录来源；技术结论优先由官方文档、规范或源码校验。
• 来源条目只保留资料标题和可直接访问的文章 URL，不写来源类型、访问日期、固定快照或逐题修订记录。
• 不在每个问题正文记录修订历史；修订依据归入来源或版本边界，历史交由 Git 追踪。
• 只做摘要、改写和少量必要引用，不批量搬运受版权保护的原文。
• 知识库正文整理写入后，再单独询问是否执行 Git commit / push。
• 面试出题模式在评分完成后自动写入练习记录并 commit + push，无需再确认。

触发条件

以下任一情况启用：

• 用户要求检索、整理、收录某个网站中的八股或面试题
• 用户要求从当前对话、历史对话或指定 transcript 提炼八股
• 用户要求补充、纠错、去重、分类或重构已有八股知识库
• 用户要求把若干技术问答归档成面试复习资料
• 用户要求出八股题、八股面试提问、八股练习、作答点评（进入面试出题模式）
• 用户显式选择 auto-know

仅要求即时回答一道题、且未要求整理/归档/出题练习时，正常回答，不自动落库。

工作模式

1. 网站检索模式：按主题或指定网站检索候选问题与答案。
2. 对话提炼模式：从用户问题和 Agent 回答中提取可复用的面试知识。
3. 知识库维护模式：对已有条目去重、补全、纠错、拆分、合并或迁移分类。
4. 组合模式：先从网站或对话提取，再与已有知识库交叉校验后落库。
5. 面试出题模式：从已保存知识库抽题，以面试口吻提问，评分后归档练习记录并自动 Git 提交推送。

识别规则：用户说「出一道八股」「八股面试」「面试提问」「八股练习」「抽题」「quiz」等 → 面试出题模式。
说「整理 / 收录 / 维护知识库」→ 原归档类模式，不出题。

工作流程（归档类模式）

Auto Know Progress:
- [ ] Phase 1: 确定范围与知识库位置
- [ ] Phase 2: 检索网站和/或对话
- [ ] Phase 3: 提取、归一化与技术校验
- [ ] Phase 4: 检索已有知识并形成归档决策
- [ ] Phase 5: 展示覆盖矩阵与补丁预览
- [ ] Phase 6: 写入并验证知识库
- [ ] Phase 7: 询问并执行可选 Git 操作

Phase 1：确定范围与知识库位置

先识别：

• 来源：指定网站、开放网络、当前对话、历史对话、指定文件，或其组合
• 主题：如 Java 基础、集合、并发、JVM、Spring、MySQL、Redis、网络、操作系统、分布式
• 目标：新增题目、补全答案、纠错、专题整理、全库去重或目录重构
• 深度：速记版、标准面试回答、原理与追问版；未指定时使用“标准面试回答 + 递进追问”
• 时间范围：用户指定；未指定时优先使用当前可访问的最新资料

知识库根目录按以下优先级解析：

1. 用户本轮指定的目录或文件
2. 用户级配置 defaultSaveDir
3. 当前工作区中已存在的 interview-knowledge/ 或 knowledge/interview/
4. 系统下载目录下的 interview-knowledge/

用户级配置位置：

• macOS / Linux：$HOME/.config/auto-know/config.json
• Windows：%APPDATA%\auto-know\config.json

可选字段：

• quizExcludeDays：面试出题冷却天数，默认 14

机器相关绝对路径只写用户级配置，不写进 skill 仓库。存在多个可用知识库且选择会改变写入目标时才询问用户；否则按上述优先级继续。

Phase 2：检索网站和/或对话

网站检索

用户要求网站检索时必须实际浏览，不凭模型记忆冒充检索结果。

来源优先级：

1. 用户点名的网站或页面
2. 官方文档、语言/框架规范、JEP/RFC、项目源码与维护者文档
3. 成熟的面试知识库，例如 JavaGuide
4. 可信技术出版物或工程团队文档
5. 个人博客只作为补充线索，不作为争议结论的唯一证据

用户点名 JavaGuide 时：

• 优先检索 javaguide.cn 与 interview.javaguide.cn
• 按 Java 基础、集合、并发、JVM、Spring、数据库、缓存、计算机基础、分布式和系统设计等栏目定位
• JavaGuide 用于发现高频问题和已有解释；容易变化或存在版本差异的结论，再用官方资料校验
• 记录具体文章 URL，不只记录站点首页；不追加固定 commit 快照链接

每个候选至少记录：

• 原始问题或页面标题
• 来源 URL
• 页面/资料名称
• 能支持该结论的要点
• 与相邻问题的关系：独立、并列、父问题、子问题或前置问题，以及原始顺序

检索不到正文、页面受限或只有搜索摘要时，明确标注证据限制，不补写成“已核实”。

对话提炼

同时扫描用户消息和 Agent 回答，不只摘录用户问题。候选包括：

• 用户直接提出的概念、原理、对比、场景与排障问题
• 回答中可独立成立的原因、实现机制、适用边界、风险和常见误区
• 回答中出现的面试追问、方案比较和版本差异
• 后续对前面答案的纠正或补充

排除：

• 只对当前项目成立的业务规则
• 纯操作指令、闲聊和任务进度
• 没有足够上下文、无法独立表述的片段
• 仅为措辞重复、没有新增知识的信息

历史对话工具不可用时，只处理当前可见对话，并在结果中说明范围，不声称已扫描全部历史。

提取时保留问题在网站或对话中的出现顺序和上下文链。对于“为什么”“那……呢”“如果……会怎样”等依赖前文的问法，可以补全指代，但必须记录它依赖的父问题，不能先打散再按关键词排序。

Phase 3：提取、归一化与技术校验

将候选整理为独立问题单元：

1. 保留问题意图：优先保留用户原始问法，只去除口头赘词并补全指代。
2. 统一别名：记录同义问法，例如“HashMap 为什么线程不安全”和“HashMap 并发 put 有什么问题”。
3. 判定问题关系与标题层级：
   • 先区分独立主问题、并列问题、父问题、子问题和前置依赖，再决定标题层级。
   • 网站模式先提取页面 h1～h6 的标题树和原始顺序，以原文的“栏目 → 问题 → 子问题”结构作为排版骨架；不能只抓取问句后全部改成 ##。
   • 原文中的页面栏目可以使用 ##，栏目下的主问题顺延为 ###，其子问题顺延为 ####；没有栏目层时，独立主问题或父问题使用 ##。
   • 原网页标题字号仅提供结构线索；如果页面因展示样式造成标题级别不规范，仍以实际语义关系修正父子层级，并保留原始顺序。
   • 依赖父问题语境才能成立、但原文没有单独标题树的子问题，放入父问题的“递进追问”分组，使用比父问题低一级或两级的标题。
   • 保留来源或对话中的提问顺序，让“概念 → 原理 → 实现 → 场景 → 边界”之类的递进链可见；不得为按关键词或字母排序而打乱顺序。
   • 子问题即使高频，也不能仅因此提升为与父问题同级；只有确认它不依赖父问题语境、与相邻问题属于并列关系时，才可使用 ##。
   • 更深层追问放在最近的子问题下，用有序列表或加粗问句表达，避免标题越级或无限加深。
   • 主问题和子问题都保留稳定 ID、直接答案和来源，使子问题可定位，同时保持父子结构。
   • 当问题本身已使用 ### 或更深标题时，“简答”“原理展开”“来源”等答案区块改用加粗标签，不与问题标题争用同一层级。
4. 控制粒度：
   • 能独立提问、独立回答的内容拆开。
   • 拆开会丢失必要上下文的内容放在同一题的追问中。
   • 不把多个无关问题压成一个宽泛专题。
5. 形成答案层次：
   • 简答：先给出 30～90 秒可表达的直接答案。
   • 原理展开：解释关键机制、因果链与必要术语。
   • 递进追问：按父子层级和原始顺序保留能继续深挖的问题。
   • 易错点与边界：注明版本、前提、例外和常见误解。
6. 技术校验：
   • 区分事实、经验判断和推断。
   • 对版本敏感内容注明适用版本。
   • 来源冲突时不强行融合，列出差异和采用结论的依据。
   • AI 对话只能作为候选来源；关键技术结论应尽量由可信资料复核。

写入或修改知识条目前，读取 references/knowledge-format.md，遵循其中的目录、条目和索引格式。

Phase 4：检索已有知识并形成归档决策

写入前必须递归检索知识库中的 Markdown 文件和总索引：

1. 使用问题关键词、别名、核心类名/API、机制名和标签搜索候选条目。
2. 命中后阅读全文或完整条目，不能只看文件名或标题。
3. 比较问题意图、父子/前置关系、原始顺序、结论、适用版本、回答深度和来源。
4. 对每个候选作出一种决策：

禁止：

• 仅因标题不同就重复新建
• 把属于同一提问链的父问题和子问题都写成同级 ##
• 为了按关键词、字母或来源排序而打乱原有逻辑递进
• 只在文件末尾追加，而不寻找语义上合适的位置
• 用较弱来源覆盖已有的官方结论
• 删除仍然有效的解释、来源或版本边界
• 为了版式统一而无意义地重写整个知识库

Phase 5：展示覆盖矩阵与补丁预览

写盘前展示：

同时列出：

• 新增、合并、修订、冲突保留、迁移和跳过的数量
• 将创建或修改的文件
• 每个文件的具体章节级补丁预览
• 每个问题的目标标题层级、父问题和相邻递进顺序
• 网站模式中补充的原文栏目标题、原文页面顺序和对应页面 URL
• 无法验证或仍需用户决定的冲突

若冲突会实质改变技术结论或归档位置，先询问用户；其余情况展示预览后直接写入。

Phase 6：写入并验证知识库

1. 只修改覆盖矩阵中确认需要变更的文件。
2. 新专题按参考格式创建；已有专题在语义最相关的位置更新。
3. 同步维护根索引和必要的分类索引，避免孤立文档。
4. 写入后检查：
   • 稳定 ID 是否唯一
   • 同义问题是否重复
   • 同级问题是否确为并列关系，子问题是否位于正确父问题下
   • 网站模式是否保留原网页的栏目树和页面内顺序，是否存在把所有问题重新压平成同级的情况
   • 是否存在孤立子问题、标题越级或逻辑递进顺序被打乱
   • 内部链接和目录索引是否有效
   • 新增/修订条目是否有来源或明确标注“来源：对话”
   • 来源条目是否只包含资料标题和 URL，没有附加来源类型
   • 版本敏感结论是否注明边界
   • 未记录固定 commit、源码快照或原文快照链接
   • 不存在逐题修订记录，历史变更由 Git 追踪
   • Git diff 是否只包含本次知识库变更
5. 回显完整文件路径、处理结果和未解决事项。

Phase 7：询问并执行可选 Git 操作

适用于归档类模式（网站检索 / 对话提炼 / 知识库维护 / 组合）。面试出题模式不走本询问流程，见下文「评分后自动 Git」。

文件写入和验证完成后，检测 Git 仓库：

1. 优先读取用户级配置中的 knowledgeGitRepo
2. 配置无效或文件不在该仓库内时，从知识库目录向上执行 git rev-parse --show-toplevel
3. 未检测到仓库时，明确说明并结束，不询问无效的 push

检测到仓库后，单独询问：

1. commit + push：只暂存本轮修改的知识库文件，提交并推送当前分支
2. 仅 commit：只创建本地提交
3. 仅落盘：不执行 Git 操作

用户原话已经明确要求 commit 或 push 时，按动作粒度视为已授权；push 包含必要的本地 commit。未明确授权时不得自行提交或推送。

执行前：

• 展示完整 commit message
• 检查工作树，只暂存本轮修改文件
• 有无法安全隔离的重叠改动时停止 Git 操作，但保留已写入内容
• 不 force push，不自动 merge/rebase

推荐 commit message：

docs(interview): 整理 {主题} 八股知识

新增/补充：{主要问题}
修订/去重：{主要调整}
来源：{网站、官方资料或对话}

push 失败时保留本地文件和已完成的 commit，明确报告网络、认证、上游或 non-fast-forward 等原因。

面试出题模式

独立模式。题目只来自当前知识库已保存文档，不临时检索外网凑题。

读取格式：

• 知识条目：references/knowledge-format.md
• 练习记录：references/practice-format.md

流程

Quiz Progress:
- [ ] Q1: 解析知识库根目录与 quizExcludeDays（默认 14）
- [ ] Q2: 读取 practice/know-record.md 出题索引
- [ ] Q3: 扫描知识库可出题单元并选题
- [ ] Q4: 更新索引最近出题时间；以面试口吻只提问、不给答案
- [ ] Q5: 等待用户作答
- [ ] Q6: 提炼口述要点 → 评分与差距
- [ ] Q7: 追加练习明细并更新作答次数（自动，无需确认）
- [ ] Q8: 仅暂存练习记录文件 → commit + push（自动，无需确认）

Q3 选题

1. 收集带稳定 ID、有问题标题、有简答（或等价直接答案）的条目。
2. 硬排除最近 N 天内出过的题（N = quizExcludeDays，默认 14）。
3. 优先：从未出过 → 最久未出过；同档可随机。
4. 用户指定专题/文件时只在范围内抽。
5. 冷却后无候选：放宽为全局最久未出，并说明已放宽。
6. 默认每次 1 题。

Q4 提问口径

• 使用面试官口吻直接提问，例如：「HashMap 为什么线程不安全？」
• 禁止附加「那我问一下：」「你就当现场面试，说重点就行」之类口头垫话或提示语。
• 本轮只出题，不泄露答案、不给解题提示。

Q6 评分口径

1. 从该题「简答」（不足则压缩「原理展开」）提炼 口述要点：只讲清能答对题的重点，不复制文档长文、大表、源码细枝与扩展追问。
2. 对照用户作答给出：
   • 评分（建议：优秀 / 良好 / 及格 / 不足，或 1～5 分）
   • 答对的点
   • 与口述要点的差距
   • 一句改进建议
3. 对话中可简要展示口述要点作对照；归档同样只写压缩版。

Q7 / Q8 自动归档与 Git

评分完成后 立即 执行，不询问：

1. 写入或更新 <knowledge-root>/practice/know-record.md（索引 + 明细）。
2. 检测 Git 仓库（同 Phase 7）。
3. 只 git add 本轮练习记录文件（含新建的 practice/ 路径）。
4. commit，推荐 message：

docs(interview-practice): 归档八股练习 — {问题标题}

出题时间：{YYYY-MM-DD HH:mm}
评分：{结果}

5. git push 当前分支上游。
6. 回显：评分摘要、文件绝对路径、commit hash、push 结果或失败原因。

约束：

• 不修改专题正文，除非用户另走归档类模式。
• 工作树有无法隔离的冲突时：仍保留已写入的练习记录，跳过 Git 并报告原因。
• 不 force push；push 失败不回滚本地 commit 与文件。

输出要求（本模式）

• 本轮题目标题、稳定 ID、来源文件
• 是否处于冷却放宽
• 评分与差距摘要
• 练习记录路径
• commit / push 是否成功及结果

AskQuestion 不可用时

需要用户选择归档冲突或 Git 操作，但当前环境无法呼起 AskQuestion 时：

1. 必须提示：“当前模型无法呼出 AskQuestion，需要纯文本确认。”
2. 随后列出编号选项，等待用户回复。
3. 用户回复前，不执行尚未授权的冲突覆盖、commit、push 或全局同步。
4. 文件落盘与 Git 操作是独立阶段；知识库已安全写入时，不因等待 Git 选择而回滚。
5. 例外：面试出题模式在评分后的练习归档与 commit+push 不经 AskQuestion，按本 skill 已授权规则直接执行。

输出要求（归档类模式）

最终结果至少包含：

• 检索或对话扫描范围
• 候选数与新增/合并/修订/冲突/跳过统计
• 修改后的绝对文件路径
• 主要问题标题与来源概览
• 校验结果和未解决限制
• Git commit / push 是否执行及结果

不要声称“已检索”“已去重”“已推送”，除非对应步骤实际完成。