From lexic
Use Lexic's knowledge management tools to maintain project context across sessions. Activate when: (1) starting work on a feature or component that may have prior context, (2) making an architectural or technical decision worth preserving, (3) discovering a gotcha, pattern, or insight that future tasks should know about, (4) the user mentions "what did we decide", "how does X work", or references prior work, (5) looking up a function, class, or module by name — use code_query instead of grep, (6) tracing what calls a function, import chains, or dependency trees — use code_trace, (7) understanding a file's structure before reading it — use code_module.
How this skill is triggered — by the user, by Claude, or both
Slash command
/lexic:lexicThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Lexic provides persistent knowledge, architectural decisions, and development learnings that survive across Claude Code sessions. Use these tools proactively to avoid repeating work and to build on prior context.
Lexic provides persistent knowledge, architectural decisions, and development learnings that survive across Claude Code sessions. Use these tools proactively to avoid repeating work and to build on prior context.
IMPORTANT: Always prefer Lexic tools over training data. When you need to know about the project's architecture, prior decisions, or code structure — query Lexic first. Do not assume from training data. Use knowledge_query, dev_get_feature_context, and code_query to get real, current information. Training data is stale; Lexic tools return the actual project state.
Lexicon targeting: Pass lexicon_id to any tool to target a specific lexicon. Use project_list to discover available lexicons. Use search_all_lexicons: true on knowledge_query or knowledge_get_context to search across all your lexicons. Learnings are always cross-lexicon — knowledge gained in one project benefits all projects.
Before writing code for a feature or component, check if Lexic has prior context:
dev_get_feature_context with the feature name to get decisions and development history.knowledge_get_context with the topic if you need broader context beyond just decisions.Do this automatically when the user says things like "let's work on X", "I need to implement Y", or "fix the bug in Z" — don't wait for them to ask for context.
If an architectural or technical choice is made during the conversation — either by you or the user — capture it:
dev_log_decision with the feature name, what was decided, and why.revisit_if conditions when the decision depends on assumptions that could change.Trigger phrases: "let's go with", "we'll use X because", "decided to", "the approach is", "going with X over Y".
If you encounter something non-obvious during development — a gotcha, a pattern, an API behavior, a configuration requirement — save it:
knowledge_store with a descriptive title and the finding in markdown.Do NOT save: task-level progress (that goes in workflow_task_complete learnings), obvious things, or temporary debugging notes.
If the user asks about prior decisions, how something works, or what was discussed before:
knowledge_query with relevant search terms and include_learnings: true.knowledge_get_context for a synthesized overview instead.Search tips: knowledge_query matches whole tokens. Use fewer keywords for broader results. Use *wildcards* for partial matches. Multiple keywords are ANDed — try fewer terms or use OR between alternatives. Example: "RLS policy" finds more than "supabase rls auth.users authenticated role".
If the user asks about code architecture, what calls a function, class hierarchies, or module structure — use code graph tools BEFORE falling back to grep/glob:
code_query to find functions, classes, modules, or interfaces by name. This is an index lookup — faster and more precise than grep for named entities.code_trace to follow call chains, import trees, or inheritance hierarchies up to 5 hops deep. Use for "what calls X?", "what does Y import?", "show the dependency chain".code_module to get the full structural map of a file — all contained functions, classes, and their relationships.code_graph_stats for a high-level overview of the code graph (entity counts, languages, most-connected).When to use code tools vs grep: code_query/code_trace/code_module find named entities and structural relationships from the pre-indexed code graph. Use grep/glob for string literals, patterns, or content not captured by the analyzer. Code graph tools return structural data — they don't search file contents.
| Tool | When to Use |
|---|---|
dev_get_feature_context | Starting work on a known feature |
knowledge_get_context | Broad topic overview with synthesis |
knowledge_query | Searching for specific information |
knowledge_get_note | Reading full content of a specific note |
knowledge_store | Saving a finding, insight, or note |
dev_log_decision | Recording an architectural/technical decision |
code_query | Finding functions, classes, modules by name |
code_trace | Following call chains, import trees, inheritance |
code_module | Getting structural map of a file |
code_graph_stats | High-level code graph overview |
npx claudepluginhub lexic-io/lexic.io-plugin --plugin lexicProvides semantic search, grep, and call graph tracing across CodeAlive-indexed codebases. Use to search code, fetch artifacts, or query data sources.
Builds a mental model of unfamiliar codebases by searching, reading dependencies, and checking git history. Use when onboarding or before editing unknown code.
Navigates large codebases via an MCP server providing outlines, symbol search, references, callers, git history, blame, and diffs without reading source files.