菜单
First-look workflow for an unfamiliar codebase via the code-nexus MCP server. The right tool order to orient yourself in 30 seconds. Use when you've just landed in a new project and need to know its shape before answering anything specific.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
ElixirNexus release checklist — pre-push checks, version bump, git tag, Docker Hub build and push. Use when cutting a new release (e.g. v1.3.4), shipping Docker images, or verifying a release is production-ready.
ElixirNexus polyglot parser/extractor architecture — Sourceror for Elixir, Tree-sitter (via Rust NIF) for JS/TS/Python/Go/Rust/Java/Ruby/Kotlin/Swift. Use when adding support for a new language, debugging missing entities/calls in extracted output, or understanding the chunking pipeline.
Elixir code style, naming conventions, and idiomatic patterns. Use when writing any Elixir code, reviewing style, choosing between approaches, or when asked about naming, pipe operators, pattern matching, error tuples, or functional design principles.
GenServer patterns for stateful processes in OTP. Use when implementing a GenServer, designing stateful process behavior, choosing between call/cast/info, handling process lifecycle, or debugging a GenServer. Also covers handle_continue, terminate, and client API wrapping.
Task and Task.Supervisor patterns for concurrent work in Elixir. Use when running work concurrently, processing collections in parallel with Task.async_stream, firing background jobs without awaiting, or handling task timeouts and failures.
ExUnit testing patterns for Elixir, including async strategy, Mox for behaviour mocking, test tags, database sandbox isolation, and performance benchmarking. Use when writing tests, setting up Mox mocks, choosing async: true or false, or structuring test modules.
| name | nexus-client-onboarding |
| description | First-look workflow for an unfamiliar codebase via the code-nexus MCP server. The right tool order to orient yourself in 30 seconds. Use when you've just landed in a new project and need to know its shape before answering anything specific. |
When you're dropped into an unfamiliar repo, don't grep blindly. Use the indexed graph in this order.
1. reindex(<project-name>) # if not already indexed
2. get_graph_stats() # shape: counts, top-connected modules, languages
3. load_resources(uri: "nexus://project/architecture") # key modules + dependency structure
4. load_resources(uri: "nexus://project/hotspots") # high fan-in/fan-out + dead code count
Now you know:
If the user asks "how does feature X work?", you don't have a function name yet. Use:
search_code("X", limit: 5)
Pick the highest-scoring result that matches the intent of X (not just keyword overlap). If the top result is a module, drill in:
find_module_hierarchy(entity_name: "TheModule") # behaviours/uses + children
If the top result is a function, get its surroundings:
find_all_callees("the_func") # what does it do?
find_all_callers("the_func") # who depends on it?
get_community_context(file_path: "path/to/file.ex") # structurally coupled files
reindex is required before anything else when:
Auto-reindex on queries handles incremental file changes (SHA256-tracked dirty files), but only if the file watcher is set up after a reindex ran at least once.
nexus://project/overview tells you that you'd otherwise have to computeload_resources(uri: "nexus://project/overview") gives you:
This is not in get_graph_stats — overview is more readable, get_graph_stats is more granular (top-connected lists, edge counts).
Each project lives in its own Qdrant collection (nexus_<name>). When you reindex(other-project), the active collection switches. Subsequent queries hit other-project only. To switch back, reindex(<original>) (data is preserved per collection — just switching which one is active).
If you need both at once, that's not supported — restart the workflow per project.