菜单
Use when asked whether the project's lore is healthy or still helping, or when the 30-day heartbeat suggests a re-check — audits coverage, link health, freshness, entry quality, adoption, and language health, read-only, then hands fixes off to lore-maintain, lore-capture, and lore-ul.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when the conversation surfaces knowledge that code, types, tests, or git history can't reveal — the user explains a business rule or a spec, shares a gotcha, gives the why behind a decision, says "that's intentional, not a bug", or you hit a pitfall or dig up a non-obvious root cause while debugging. Record it into docs/lore/ before the session ends and it evaporates.
Use when about to plan a feature, fix a bug, or touch unfamiliar code in a repo that has a docs/lore/ folder, before writing any implementation — surfaces the business rules, pitfalls, glossary terms, and API map relevant to the task, and flags entries that look stale.
Use when about to commit, open a PR, or claim a change is done in a repo that has docs/lore/ — maps the changed files to lore entries through their code: links and reports any business rule, pitfall, or glossary naming rule the change violates. Read-only for both code and lore.
Use when a project has no docs/lore/ yet and implicit knowledge starts coming up in conversation, or when the user asks to initialize, bootstrap, or set up project lore — scaffolds the docs/lore/ knowledge base.
Use when lore looks stale or noisy, when a lore-check report flags problems, or on a periodic sweep — finds stale, duplicate, or wrong entries, checks that code links and the README index still hold, and prunes obsolete content; marking over deleting, with confirmation for destructive actions.
Use when a conversation hits a vague or overloaded term, the same word means different things in different places, the user quietly rewords something you said, the user keeps using a word the glossary doesn't have, or code names disagree with how the user talks — align the term into docs/lore/glossary.md. Also bootstraps a glossary for a project that has none.
| name | lore-check |
| description | Use when asked whether the project's lore is healthy or still helping, or when the 30-day heartbeat suggests a re-check — audits coverage, link health, freshness, entry quality, adoption, and language health, read-only, then hands fixes off to lore-maintain, lore-capture, and lore-ul. |
Read ${CLAUDE_PLUGIN_ROOT}/reference/lore-spec.md first — the entry-meta format, the "What lore is / isn't" boundary test, and the feedback-log format all come from there.
When you want to know whether a project's lore is healthy and actually pulling its weight: on an explicit request ("how healthy is our lore?", "is the lore still useful?"), or as a periodic check. Only meaningful when the repo has a docs/lore/ folder — if there is none, say so briefly and suggest lore-init, rather than reporting an empty audit.
This skill is read-only. It never edits, marks, or deletes anything — it produces a report and hands the fixes off.
Run all seven checks, then produce one report. Use your file tools directly (Read, Grep, checking that paths exist) — there is no script to run.
`code:` reference and check each path still exists on disk. Report the broken-link count and ratio.updated: and status:. Report the age distribution, how many are older than ~180 days, and the active / resolved / obsolete breakdown.code:, updated:, status:), and that the README Areas table matches the folders actually on disk. If lore-consult can't find or link an entry, it can't surface it.docs/lore/.lore-feedback.jsonl if it exists and aggregate per entry: how often each was surfaced, and the heeded / redundant / ignored split. Flag entries surfaced repeatedly but never heeded as review candidates. If the log is absent or empty, report "no data yet" — that is normal for a fresh base, not an error.docs/lore/glossary.md (or any <area>/terms.md) exists: check every term's meta is complete (code:, updated:, status:), and spot-check the codebase for not: names still used in domain positions — a heuristic sample judged in context, not an exhaustive lint. Also spot-check liveness the other way: does the term's code: type still exist, and does the term itself still appear anywhere in the codebase? A term that fails both is a dead word — a document whose language no longer appears in the code has stopped working; flag it as an obsolete candidate for lore-maintain. Fold in each term's adoption from the feedback log (keys glossary.md#<Term>). If there is no glossary, report "no glossary yet — lore-ul can bootstrap one"; that is a note, not a failure.Produce one report. Give each dimension its own line with the raw numbers and a green / yellow status. Do NOT roll the seven into a single score — that hides what to fix. End with concrete next steps that point at the right skill:
lore-maintainlore-capturelore-ulYellow/green thresholds are heuristic: flag yellow when there is any broken link, the boundary-test pass rate is low, there are uncovered domains, or an entry is surfaced repeatedly with zero heeded. Don't chase precise numbers — the point is to steer the next action, not to grade.
After delivering the report, refresh the heartbeat stamp: write today's date to docs/lore/.lore-last-check (one line, YYYY-MM-DD), and make sure docs/lore/.gitignore ignores it. The SessionStart hook reads this stamp to suggest a re-check after ~30 days — it is how the health loop keeps running without anyone remembering to.
Read-only toward the lore itself, always. lore-check never edits, marks, deletes, or refreshes any lore content — every fix is a handoff to lore-maintain, lore-capture, or lore-ul, which carry their own confirmation steps. The one exemption is bookkeeping: the gitignored .lore-last-check stamp (and, per lore-spec, the feedback log) are metadata about the check, not lore.