用途：在规划功能、修复缺陷或接触不熟悉代码之前，查阅仓库中的 docs/lore/ 知识库，把与当前任务相关的规则、陷阱和术语提炼成简短简报。仅当仓库确实存在 docs/lore/ 时适用；若没有，应简短告知用户并建议运行 lore-init 搭建，而不是沉默。
主要能力：先读 docs/lore/README.md，把任务映射到一个或多个 area，core 区域优先；已知要改动的文件时，用 grep 在 docs/lore/ 中按 code: 引用做反向查找（前缀匹配也算）；对每个匹配区域读取 pitfalls.md 与 business-rules.md，规划新功能时再读 api-map.md；按 lore-spec 解析术语表（根 CONTEXT.md 或 docs/lore/glossary.md / 区域的 terms.md），并检索相关术语条目。文件过长时先 grep ## 标题与 meta 行，再只读相关条目。
使用方式：产出简短简报，只覆盖与任务相关的规则和陷阱及其 code: 链接，必要时附 1-2 个术语，默认约 5 条要点或 300 词以内，除非用户明确要求更多；不要粘贴整个区域，跳过已解决或过时条目。随后核对每个条目的 code: 路径是否仍存在，缺失或移动则标记为可能过时。发现过时或与代码矛盾的条目时，可顺带提议刷新 updated: 日期、重写或标记 obsolete，但仅作为可拒绝的附带建议，不得阻塞主任务。按 lore-spec 的反馈日志，把浮现的条目追加到 docs/lore/.lore-feedback.jsonl，任务结束时将其归为 heeded、redundant 或 ignored；该记录为尽力而为，写不了就跳过，且需确保 .gitignore 忽略该文件。
适用场景与限制：适合有 docs/lore/ 知识库的仓库在动手前做上下文对齐。没有该目录时无内容可查；反馈日志与清理均为可选、非阻塞操作；资料未提供具体安装命令、收费或平台信息。