메뉴
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 직업 분류 기준
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.
| 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.