
When you need to understand who calls a Rust function or what it calls, this skill uses LSP to build visual call hierarchies. You can trace callers (impact analysis), callees (implementation flow), or both, with configurable depth. It's especially handy when refactoring or trying to understand execution paths in unfamiliar code. The ASCII tree diagrams are clear and the bidirectional view gives you the full picture of a function's role in your codebase. One nice touch: it provides analysis like hot paths and complexity metrics after showing the graph, so you get context beyond just the visualization.
$ npx -y skills add zhanghandong/rust-skills --skill rust-call-graph --agent claude-codeInstalls into .claude/skills of the current project.
Visualize function call relationships using LSP call hierarchy.
/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), bothExamples:
/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 analysisGet the call hierarchy item for a function.
LSP(
operation: "prepareCallHierarchy",
filePath: "src/handler.rs",
line: 45,
character: 8
)
LSP(
operation: "incomingCalls",
filePath: "src/handler.rs",
line: 45,
character: 8
)
LSP(
operation: "outgoingCalls",
filePath: "src/handler.rs",
line: 45,
character: 8
)
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
## Callers of `process_request`
main
└── run_server
└── handle_connection
└── process_request ◄── YOU ARE HERE
## 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
## Call Graph for `process_request`
┌─────────────────┐
│ main │
└────────┬────────┘
│
┌────────▼────────┐
│ run_server │
└────────┬────────┘
│
┌────────▼────────┐
│handle_connection│
└────────┬────────┘
│
┌────────────────────┼────────────────────┐
│ │ │
┌───────▼───────┐ ┌───────▼───────┐ ┌───────▼───────┐
│ parse_headers │ │ authenticate │ │send_response │
└───────────────┘ └───────┬───────┘ └───────────────┘
│
┌───────┴───────┐
│ │
┌──────▼──────┐ ┌──────▼──────┐
│ check_token │ │ load_user │
└─────────────┘ └─────────────┘
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)
| User Says | Direction | Use Case |
|---|---|---|
| "Who calls X?" | incoming | Impact analysis |
| "What does X call?" | outgoing | Understanding implementation |
| "Show call graph" | both | Full picture |
| "Trace from main to X" | outgoing | Execution path |
| Style | Best For |
|---|---|
| Tree (default) | Simple hierarchies |
| Box diagram | Complex relationships |
| Flat list | Many connections |
| Mermaid | Export to docs |
graph TD
main --> run_server
run_server --> handle_connection
handle_connection --> process_request
process_request --> parse_headers
process_request --> authenticate
process_request --> send_response
| When | See |
|---|---|
| Find definition | rust-code-navigator |
| Project structure | rust-symbol-analyzer |
| Trait implementations | rust-trait-explorer |
| Safe refactoring | rust-refactor-helper |
Sponsors