菜单
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.
用 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 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 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-guard |
| description | 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. |
Read ${CLAUDE_PLUGIN_ROOT}/reference/lore-spec.md first — the entry-meta format and the feedback-log format come from there.
lore-consult reads lore before work starts. This skill is the other bookend: it re-checks the result of the work, because rules that were surfaced can still get lost during implementation, and rules nobody thought to surface can turn out to apply. Without this pass, nothing stands between a diff that quietly breaks a recorded business rule and the commit that ships it.
After implementing a change and before committing or opening a PR, in a repo that has docs/lore/. Also on an explicit ask like "does this change break any of our rules?". If there is no docs/lore/, say so briefly and move on — there is nothing to guard against.
git diff --name-only HEAD, plus untracked files that belong to the change). If the user points at a specific diff or branch, use that instead.code: link. Grep every `code:` reference across docs/lore/ and keep the entries whose path intersects the changed files. Match by prefix too — an entry pointing at src/payments/ covers any changed file under it, and an entry pointing at a file covers that file's changes.docs/lore/README.md index, and scan those areas' pitfalls.md / business-rules.md headings for entries that clearly bear on the change even though their code: link points elsewhere. The code: match is precise but incomplete; this step catches the rest. Skip non-active entries unless one is directly relevant.lore-maintain.docs/lore/glossary.md (or an area's terms.md) exists, scan the diff's added lines for identifiers and user-facing strings that hit a term's not: list. Judge semantics before flagging: client naming an HTTP client is fine; client naming the paying party when the glossary says Customer is a violation. Read the hunk, not just the match. Report a hit like any other violation — the term's heading, the not: name the diff introduced, and the canonical name to use instead.code: link, what in the diff conflicts, and the direction a fix would take. You never edit code yourself — fixing is the caller's job. When nothing matches, still say so in one line ("lore-guard: N entries checked, no conflicts"), so the user knows the pass actually ran.surfaced event for each entry you judged (glossary terms keyed glossary.md#<Term>), then reconcile — heeded when a violation was flagged and the user fixed it, redundant when the change already respected the entry, ignored when the user dismissed the flag. Never let logging block or delay the report.Read-only, both directions: never edit the code under review, and never edit lore. A violation is a report, not an auto-fix. Relevance over completeness — judging five entries that actually touch the diff beats listing fifty that don't.