Rust Call Graph
Map who calls and what a Rust function calls before refactors, reviews, or incident triage using LSP call hierarchy.
Overview
rust-call-graph is an agent skill for the Build phase that builds Rust function call graphs from LSP call hierarchy (callers, callees, or both).
Install
npx skills add https://github.com/zhanghandong/rust-skills --skill rust-call-graphWhat is this skill?
- Slash command `/rust-call-graph <function> [--depth N] [--direction in|out|both]`
- LSP prepareCallHierarchy, incomingCalls, and outgoingCalls against precise file/line/character
- Default depth 3 with configurable traversal and caller-only or callee-only modes
- Workflow: workspaceSymbol or Grep to locate symbol, then hierarchy expansion
- allowed-tools: LSP, Read, Glob for Rust crate navigation
- Default traversal depth 3 (override with --depth N)
Adoption & trust: 661 installs on skills.sh; 1.2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need to see Rust caller and callee chains around a symbol but manual search misses indirect paths and macro-expanded noise.
Who is it for?
Solo developers on Rust backends who already use LSP-enabled agents and want structured call tracing on a named function.
Skip if: Non-Rust codebases, environments without LSP call hierarchy support, or teams wanting static binary-level graphs without source LSP.
When should I use this skill?
Triggers on /call-graph, call hierarchy, who calls, what calls, 调用图, 调用关系, 谁调用了, 调用了谁.
What do I get? / Deliverables
You get a leveled call hierarchy report for the target function so you can refactor or debug with explicit in/out relationships.
- Call graph summary for target function (callers, callees, or both)
- Depth-limited hierarchy traversal per CLI flags
Recommended Skills
Journey fit
Canonical shelf is Build because the skill navigates Rust source structure and dependencies during active backend development, not production monitoring. Backend fits Rust services, handlers, and crates where call-graph clarity prevents risky edits across modules.
How it compares
Prefer this LSP-backed hierarchy over plain grep when you need semantic call edges, not just textual name matches.
Common Questions / FAQ
Who is rust-call-graph for?
Indie and small-team Rust builders using Claude Code, Cursor, or similar agents with LSP access who need fast call-relationship maps.
When should I use rust-call-graph?
During Build backend work before refactors, when reviewing entrypoints like main or handlers, or when tracing error paths with --direction in or out.
Is rust-call-graph safe to install?
It uses read-oriented LSP and file tools; confirm scope in the Security Audits panel on this page and avoid pointing it at secrets in untrusted repos.
SKILL.md
READMESKILL.md - Rust Call Graph
# Rust Call Graph Visualize function call relationships using LSP call hierarchy. ## Usage ``` /rust-call-graph <function_name> [--depth N] [--direction in|out|both] ``` **Options:** - `--depth N`: How many levels to traverse (default: 3) - `--direction`: `in` (callers), `out` (callees), `both` **Examples:** - `/rust-call-graph process_request` - Show both callers and callees - `/rust-call-graph handle_error --direction in` - Show only callers - `/rust-call-graph main --direction out --depth 5` - Deep callee analysis ## LSP Operations ### 1. Prepare Call Hierarchy Get the call hierarchy item for a function. ``` LSP( operation: "prepareCallHierarchy", filePath: "src/handler.rs", line: 45, character: 8 ) ``` ### 2. Incoming Calls (Who calls this?) ``` LSP( operation: "incomingCalls", filePath: "src/handler.rs", line: 45, character: 8 ) ``` ### 3. Outgoing Calls (What does this call?) ``` LSP( operation: "outgoingCalls", filePath: "src/handler.rs", line: 45, character: 8 ) ``` ## Workflow ``` User: "Show call graph for process_request" │ ▼ [1] Find function location LSP(workspaceSymbol) or Grep │ ▼ [2] Prepare call hierarchy LSP(prepareCallHierarchy) │ ▼ [3] Get incoming calls (callers) LSP(incomingCalls) │ ▼ [4] Get outgoing calls (callees) LSP(outgoingCalls) │ ▼ [5] Recursively expand to depth N │ ▼ [6] Generate ASCII visualization ``` ## Output Format ### Incoming Calls (Who calls this?) ``` ## Callers of `process_request` main └── run_server └── handle_connection └── process_request ◄── YOU ARE HERE ``` ### Outgoing Calls (What does this call?) ``` ## Callees of `process_request` process_request ◄── YOU ARE HERE ├── parse_headers │ └── validate_header ├── authenticate │ ├── check_token │ └── load_user ├── execute_handler │ └── [dynamic dispatch] └── send_response └── serialize_body ``` ### Bidirectional (Both) ``` ## Call Graph for `process_request` ┌─────────────────┐ │ main │ └────────┬────────┘ │ ┌────────▼────────┐ │ run_server │ └────────┬────────┘ │ ┌────────▼────────┐ │handle_connection│ └────────┬────────┘ │ ┌────────────────────┼────────────────────┐ │ │ │ ┌───────▼───────┐ ┌───────▼───────┐ ┌───────▼───────┐ │ parse_headers │ │ authenticate │ │send_response │ └───────────────┘ └───────┬───────┘ └───────────────┘ │ ┌───────┴───────┐ │ │ ┌──────▼──────┐ ┌──────▼──────┐ │ check_token │ │ load_user │ └─────────────┘ └─────────────┘ ``` ## Analysis Insights After generating the call graph, provide insights: ``` ## Analysis **Entry Points:** main, test_process_request **Leaf Functions:** validate_header, serialize_body **Hot Path:** main → run_server → handle_connection → process_request **Complexity:** 12 functions, 3 levels deep **Potential Issues:** - `authenticate` has high fan-out (4 callees) - `process_request` is called from 3 places (consider if this is intentional) ``` ## Common Patterns | User Says | Direction | Use Case | |-----------|-----------|----------| | "Who calls X?" | incoming | Impact analysis | | "What does X call?" | outgoing | Understanding implementation | | "Show call graph" | both | Full picture | | "Tr