菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | lore-maintain |
| description | 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. |
Read ${CLAUDE_PLUGIN_ROOT}/reference/lore-spec.md first — follow its Maintenance & deletion policy.
On an explicit request ("tidy up lore", "clean out stale entries") or as a scheduled sweep that catches the long tail nobody is reading. Also the natural follow-up to a lore-check report: its flagged broken links, stale entries, suspected noise, and low-adoption entries (surfaced repeatedly but never heeded) are your work list.
glossary.md and any <area>/terms.md — and verify each code: path still exists on disk.updated: date is long ago, read the current code and decide: is it still true, is it wrong, or is it merely outdated? Treat an updated: date older than ~180 days as "long ago" (unless the user sets a different threshold) — but the date only decides what to re-read, never whether the entry is stale. That call is always made by reading the code, not by guessing. For a glossary term, stale means the concept (or its code: type) no longer exists or was renamed — follow the spec's term-evolution rule: mark the old term obsolete and point it at the new one, rather than deleting.docs/lore/README.md against the folders actually on disk, and note anything that no longer lines up.updated:, rewrite, mark resolved, mark obsolete, merge, or flag as a delete-candidate. For low-adoption entries (surfaced repeatedly, never heeded), read their note fields in the feedback log before judging — an entry that keeps getting ignored may be true but badly written, and then the right action is a rewrite, not a mark or a delete.accepted (the user approved it) or declined (the user refused it) event to lore-spec's feedback log — best-effort, never blocking.Group step 5's recommendations under clear action headings so the user can confirm or decline each line. This is a suggested shape, not a rigid contract:
## Lore maintenance report
- keep: <entry heading> (`code: ...`)
- refresh-updated: <entry heading>
- rewrite: <entry heading> — reason: surfaced 3x, never heeded; body buries the rule
- mark-resolved: <entry heading>
- mark-obsolete: <entry heading>
- merge-candidates: <heading A> + <heading B>
- delete-candidates: <heading> — reason: never true
Never delete on your own — report first, then act only on confirmation. Decide "still true?" and "wrong vs. merely outdated?" by reading the code, not by guessing.
When you refresh an updated: value, follow lore-spec's date rule: use a real, known current date or ask the user — never invent or backdate one.
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 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.
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 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.