majiayu000 用于维护 Karpathy 风格的 LLM Wiki：把长期有价值的知识编译进一个可持续更新的 markdown wiki，而不是每次查询都从原始材料重做检索。
这个 skill 只定义共享流程，不绑定具体 Vault、taxonomy、目录名或项目路径。项目现场规则必须继续从 wiki 自身读取。
何时使用
当用户出现以下意图时使用本 skill：
- 明确提到
llm wiki、wiki、knowledge base、知识库 - 要求
ingest/query/lint一个 markdown wiki - 要把文章、推文、笔记、论文吸收到现有 wiki
- 要基于已有 wiki 回答问题，而不是直接临时总结
- 要检查 wiki 的断链、孤儿页、索引遗漏、重复页或证据漂移
若当前环境存在 orbit-os、bird-twitter 等 skill，可与本 skill 协作：
- Obsidian / Vault 结构约束：先读
orbit-os - X/Twitter 来源采集：先用
bird-twitter获取原文或桥接 source，再回到 wiki ingest
会话起步（每次都做）
在 ingest / query / lint 之前，先定位 wiki 根目录，然后做 orientation。
wiki 路径优先级：
- 用户显式给出的路径
- 当前仓库或工作区内明显存在的 wiki 目录
- 若仍不明确，再问用户
orientation 顺序：
- 读
SCHEMA.md - 若存在，读
purpose.md - 读
index.md - 扫描最近
log.md - 若 wiki 根目录有
AGENTS.md或_meta/quickstart-prompts.md，把它们视为项目现场补充规则
只有完成 orientation 后，才能决定是否新建页面、更新页面或回答 query。
核心操作
Ingest
默认采用 analysis -> generation 两步，而不是直接写页面。
analysis 阶段至少要回答：
- 这条 source 的核心信息是什么
- 它与现有 wiki 哪些页面重合
- 应更新哪些已有页面
- 是否值得新建页面；如果值得，页类型是什么
- 是否存在冲突、证据补强或范围外信息
- 是否应使用 source bridge，而不是把外部 canonical 路径直接塞进 frontmatter
如果 wiki 已经定义 _meta/ingest-analysis/ 或等价目录，先把 analysis 落到该目录；如果没有，就先在回复里给出 analysis 摘要，再执行 generation。
generation 阶段要求：
- 遵守本地
SCHEMA.md/purpose.md - 优先更新已有页面，再决定是否新建页面
- 更新
updated字段 - 补上必要的
[[wikilinks]] - 把新页或变更同步进
index.md - 把动作记录进
log.md raw/视为原始层，默认不重写既有 source
除非用户明确要求“跳过 analysis”或本地规则明确允许，否则不要直接一把写入 wiki。
Query
query 不是普通聊天，先判断它是否属于 wiki 的长期主题范围。
步骤：
- 先看
purpose.md是否覆盖当前问题 - 再从
index.md和相关页面定位已有知识 - 优先基于现有 wiki 回答，而不是重新从外部材料发挥
- 如果答案具有长期价值，再决定是否沉淀到
queries/或回写现有页面
当 wiki 规模变大时，可使用轻量 relevance 扩展：
- 标题命中
- wikilink 邻居页
- source overlap
- 最近更新页
但不要在没有本地约束的情况下，擅自发明复杂 graph ranking。
Lint
lint 关注结构健康，而不是重写内容。
至少检查：
index.md是否漏页- 是否存在孤儿页
- 是否存在断开的 wikilink
- frontmatter 是否缺关键字段
- 最近 source 是否已真正消化进知识层
- 是否出现重复页或明显分页失衡
- 冲突结论是否被标记，而不是被静默覆盖
lint 的产出默认是问题清单和建议动作；除非用户要求，不要在 lint 阶段顺手大改内容。
可选模式
Source Bridge
如果 canonical 原文位于 wiki 外部的知识库或归档系统，优先在 wiki 的 raw/ 层写一份桥接 source，再把 frontmatter 指向桥接文件。这样可以避免源路径频繁漂移。
瘦 Frontmatter
如果页面 sources 过长，可采用“瘦头部”策略：
- frontmatter 只保留少量核心来源
- 完整来源列表放入页面内或独立 registry
- 若本地 schema 允许，可增加
source_count
不要在没有本地 schema 支持的情况下强行改写。
不要做的事
- 不要把具体 Vault 路径、项目 taxonomy、目录命名习惯硬编码进共享 skill
- 不要假设所有 wiki 都有
purpose.md、_meta/ingest-analysis/或相同目录结构 - 不要绕过本地
SCHEMA.md自创结构 - 不要把临时聊天结论默认当成长期知识入库
- 不要把 Hermes / Claude / Codex 的运行态 patch 直接当作 wiki 规则
成功标准
一次合格的 wiki 操作，至少满足：
- 先 orientation，再行动
- 写入遵循本地规则，不污染项目现场
- ingest 有 analysis 痕迹
- query 优先复用现有知识
- lint 输出的是结构问题，不是随意重写