メニュー
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.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | lore-consult |
| description | 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. |
Read ${CLAUDE_PLUGIN_ROOT}/reference/lore-spec.md first for the structure and entry-meta format.
Before planning a feature or starting a bug fix — but only when the repo actually has a docs/lore/ folder. If there is no docs/lore/, there is nothing to consult: tell the user briefly and suggest running lore-init to scaffold one, rather than going quiet.
docs/lore/README.md and map the current task to one (or more) area. A task can touch several areas; pick all that apply. If the Areas table marks any of them core (per lore-spec's Core areas), read those first — their rules bear the most weight.docs/lore/ for `code:` references matching those paths (prefix matches count — an entry pointing at src/payments/ covers files under it). This catches entries filed under an area you didn't map in step 1; the code: meta exists precisely to make this lookup cheap.pitfalls.md and business-rules.md. If you are planning a new feature, also read api-map.md when it is present. If docs/lore/glossary.md (or an area's terms.md) exists, also grep its ## headings for the concepts this task touches and read the matching term entries — the brief's own wording should follow the glossary. When one of these core files has grown long, don't read it wall-to-wall: grep its ## headings and meta lines first, then read only the entries that look relevant.code: links — plus at most 1-2 glossary terms when their definitions bear on the task — aim for at most ~5 bullets or ~300 words unless the user explicitly asks for more. Do not paste the whole area. Skip non-active entries (resolved, obsolete) unless one is directly relevant to what you are doing.code: path still exists. If a path is missing or has moved, flag that entry as possibly stale.When step 5 turns up a stale entry — or one that plainly contradicts the current code — offer to fix it on the spot: refresh its updated: date, rewrite it, or mark it obsolete. You are already in context, so this is cheap. Keep it a side-offer the user can decline; never force it, and never let it block the main task.
Following lore-spec's feedback log: when your brief surfaces an entry, append a surfaced event for it to docs/lore/.lore-feedback.jsonl. Glossary terms are keyed glossary.md#<Term> (or <area>/terms.md#<Term> after a split). At the end of the task, reconcile each surfaced entry to its real outcome — heeded (the work followed it), redundant (it only confirmed what was already planned), or ignored (skipped, or it turned out wrong). This signal is what lore-check aggregates into its adoption report.
This is strictly best-effort and must never block or delay the task. If the log can't be written, skip it. A session that ends before reconciliation simply leaves the entry as surfaced. If docs/lore/.gitignore doesn't already ignore .lore-feedback.jsonl, add it.
Relevance over completeness — a tight brief beats a full dump. Maintenance is an offer here, not an interruption. Feedback logging is best-effort and never blocks the task.
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 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.