メニュー
Recipe for safely changing a function — `analyze_impact` → `find_all_callers` → review each caller. Covers the `depth` parameter, when to widen it, and how to read the impact tree. Use before any non-trivial rename or signature change.
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-refactoring-workflow |
| description | Recipe for safely changing a function — `analyze_impact` → `find_all_callers` → review each caller. Covers the `depth` parameter, when to widen it, and how to read the impact tree. Use before any non-trivial rename or signature change. |
Before touching a function with non-trivial reach, walk the call graph instead of trusting grep. AST-parsed call edges have no false positives from comments or strings.
1. analyze_impact(entity_name: "the_function", depth: 3)
→ see the blast radius — total_affected, affected_files, impact_tree
2. find_all_callers(entity_name: "the_function", limit: 50)
→ flat list of direct callers
3. For each caller, decide: passthrough rename, signature update, or compatibility shim
depth parameter — what it actually meansanalyze_impact(depth: N) walks transitive callers up to N levels:
depth: 1 — direct callers only (same as find_all_callers)depth: 2 — callers + callers-of-callersdepth: 3 (default) — usually enough for "is this safe?"depth: 5+ — for entry-point or framework-internal functions where the blast radius is wideIf total_affected keeps growing every time you bump depth, the function has wide reach — break the change into smaller pieces.
impact_treeimpact_tree is a nested map. Each level is a hop further from the changed function. A node with no children means "this caller has no callers itself in the index" (a leaf — likely an entry point, test, or external surface).
If a leaf is a test file, that's a good signal — the change is well-covered. If many leaves are public exported functions, you have an external API change.
find_all_callers returns the wrong granularityThe current implementation resolves to the enclosing module-level entity if no tighter function chunk matches. So you may see MyModule instead of MyModule.func. The file_path and start_line are accurate either way — open the file at that line to see the actual caller.
Renaming Indexer.busy?/0 → Indexer.indexing?/0:
analyze_impact("busy?", depth: 3)
→ total_affected: 4, files: [mcp_server.ex, indexer.ex, mcp_server_test.exs]
find_all_callers("busy?")
→ [MCPServer.handle_tool_call/3 (mcp_server.ex:318), ...]
→ 4 sites, all in 3 files. Safe. Rename and update each call site. Re-run find_all_callers("indexing?") after to verify nothing was missed.
If you've changed code and haven't run reindex since, the call graph is stale. Auto-reindex on queries handles dirty files (SHA256-tracked), but only if the file watcher is set up. After a clone or container rebuild, run reindex once.